T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:15
- Finding
- Plaintext Secrets Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `SKILL.md:15-18`, `SKILL.md:58-61`, and `SKILL.md:65-66` **Vulnerability Type**: Plaintext sensitive-data exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```bash # Store a secret (creates or updates) ravi secrets set OPENAI_API_KEY "sk-abc123..." --json # With optional notes ravi secrets set STRIPE_SECRET_KEY "sk_live_..." --json ``` The integration example repeats the unsafe pattern and also expands a retrieved secret into the `curl` command line: ```bash # Store a key for the agent to use later ravi secrets set OPENAI_API_KEY "sk-abc123..." --json # At runtime, retrieve the key API_KEY=$(ravi secrets get OPENAI_API_KEY --json | jq -r '.value') curl -H "Authorization: Bearer $API_KEY" https://api.openai.com/v1/... # Store multiple service keys ravi secrets set ANTHROPIC_API_KEY "sk-ant-..." --json ravi secrets set GITHUB_TOKEN "ghp_..." --json ``` ### Technical Analysis The documentation instructs users and agents to pass API keys, tokens, and other secrets directly as command-line arguments. Shells commonly retain entered commands in history files, meaning a real secret supplied in place of the examples can remain available after the vault operation completes. Command-line arguments may also be visible temporarily through process-inspection facilities, monitoring agents, diagnostic collectors, audit systems, or process-listing tools, subject to the operating system's access controls. The `curl` example similarly expands the retrieved API key into the `Authorization` header argument, placing the plaintext token in the process argument vector. Encrypting a value inside the vault does not protect the value before it reaches the vault CLI or while it is exposed through another command's arguments. The repository contains only `SKILL.md`, so the claimed end-to-end encryption and any secret-safe input mechanism in t ...[truncated 1316 chars]
- Remediation
- ## Remediation Suggestions 1. Replace command-line secret arguments with a protected standard-input interface, for example: ```bash printf '%s' "$OPENAI_API_KEY" | ravi secrets set OPENAI_API_KEY --value-stdin --json ``` The CLI should clearly document that it reads only the secret value from standard input and should avoid echoing or logging it. 2. Provide an interactive no-echo prompt when standard input is attached to a terminal: ```bash ravi secrets set OPENAI_API_KEY --prompt --json ``` 3. If the CLI does not currently support standard input or protected prompts, add those capabilities before recommending it for real credentials. Avoid suggesting temporary files unless they are created atomically with restrictive permissions and securely removed. 4. Add an explicit warning that users must not place real secrets directly in command arguments because they may be retained in shell history, process metadata, audit logs, or telemetry. 5. Avoid expanding bearer tokens into `curl` arguments. Prefer a client integration that injects credentials without exposing them in the process argument vector. If a temporary configuration or header file is unavoidable, create it with owner-only permissions, prevent logging and backups, and delete it immediately after use. 6. Recommend credential scoping, short expiration periods, rotation, and revocation procedures to reduce the impact of accidental exposure.