T09 · Insecure Skill Coding Practices
Error
- Location
- references/cli-examples.md:8
- Finding
- Secret Disclosure Through Unsafe 1Password CLI Examples<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-examples.md`, lines 8–20 **Vulnerability Type**: Secret exposure through terminal output and insecure file persistence **Risk Level**: High ### Vulnerable Code ```bash - `op read op://app-prod/db/password` - `op read "op://app-prod/db/one-time password?attribute=otp"` - `op read "op://app-prod/ssh key/private key?ssh-format=openssh"` - `op read --out-file ./key.pem op://app-prod/server/ssh/key.pem` ## Run - `export DB_PASSWORD="op://app-prod/db/password"` - `op run --no-masking -- printenv DB_PASSWORD` - `op run --env-file="./.env" -- printenv DB_PASSWORD` ## Inject - `echo "db_password: {{ op://app-prod/db/password }}" | op inject` ``` ### Technical Analysis The examples encourage operations that disclose highly sensitive 1Password values or persist them without adequate file-system protections: - `op read` writes passwords, one-time passwords, and private keys directly to standard output. - `op run --no-masking -- printenv DB_PASSWORD` explicitly disables 1Password's output masking and prints the resolved password. - `op read --out-file ./key.pem` writes an SSH private key to a normal working-directory file without establishing a restrictive `umask`, verifying permissions, or arranging cleanup. - `op inject` can emit resolved secrets to standard output or generate plaintext configuration files. This behavior conflicts with the guardrail in `SKILL.md` that prohibits placing secrets in logs, chat, or code. It is especially hazardous because the documented workflow captures tmux pane output. Terminal output containing secrets may consequently be retained in pane history, shell transcripts, agent tool results, conversation context, or centralized execution logs. Files generated in the working directory may also inherit permissive default permissions. On a multi-user host, another local account or process could read a private key or generated configuration file. ### Attack Path 1. A ...[truncated 1562 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove examples that print resolved secrets directly: - Do not demonstrate `op read` for passwords, OTPs, or private keys without a non-output consumer. - Remove `op run --no-masking -- printenv DB_PASSWORD`. - Do not pipe resolved `op inject` output to a terminal or captured pane. 2. Demonstrate secret use through a process that does not print its environment: ```bash export DB_PASSWORD="op://app-prod/db/password" op run -- application-command ``` 3. If writing a secret to disk is strictly necessary, establish restrictive permissions before creation and guarantee cleanup: ```bash umask 077 SECRET_DIR="$(mktemp -d)" trap 'rm -rf "$SECRET_DIR"' EXIT op read --out-file "$SECRET_DIR/key.pem" "op://app-prod/server/ssh/key.pem" chmod 600 "$SECRET_DIR/key.pem" ``` 4. Add explicit warnings that secret-bearing commands must not be followed by tmux pane capture, terminal recording, debug tracing, `printenv`, `env`, or log collection. 5. Prefer ephemeral mechanisms such as `op run` and direct process input over plaintext files. Where an application supports standard input or dedicated credential descriptors, pass secrets through those channels. 6. Document that generated configuration files containing injected secrets require restrictive permissions, exclusion from version control, and deletion immediately after use. 7. Add a review rule requiring all examples to remain consistent with the `SKILL.md` prohibition against placing secrets in logs, chat, or code. ]]>