T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/run.py:111
- Finding
- API credential exposed through command-line arguments## Vulnerability Details **File Location**: `scripts/run.py:111-115` (credential use also occurs at `scripts/run.py:39-43`; insecure invocation is documented at `SKILL.md:29-31`) **Vulnerability Type**: Exposure of a secret through process arguments **Risk Level**: Medium ### Evidence `scripts/run.py:39-43`: ```python def call_llm(system: str, user: str, appkey: str) -> str: payload = {"model": MODEL, "temperature": 0.0, "messages": [ {"role": "system", "content": system}, {"role": "user", "content": user}, ]} body = _http_post(API_URL, payload, {"Authorization": f"Bearer {appkey}"}) ``` `scripts/run.py:111-115`: ```python parser.add_argument( "--appkey", required=True, help="内部医疗大模型鉴权 key。", ) ``` `SKILL.md:29-31`: ```bash python3 scripts/run.py --input input.json --output output.json --appkey YOUR_KEY ``` ### Technical Analysis The application requires the API credential to be passed in the `--appkey` command-line argument. Command-line arguments are not an appropriate secret transport mechanism because they can be exposed through shell history, process inspection facilities, job-runner logs, audit records, crash diagnostics, monitoring systems, or command transcription. The supplied value is subsequently used as a bearer credential in the HTTP `Authorization` header. Therefore, disclosure of the command-line value directly discloses a reusable authentication secret rather than a non-sensitive identifier. HTTPS protects the credential while it is transmitted to the configured API endpoint, but it does not mitigate exposure that occurs locally before the request is sent. ### Attack Path 1. A user follows the documented command and supplies a valid API key through `--appkey`. 2. The complete command is retained in shell history, recorded by an automation platform, or temporarily exposed through operating-system process inspecti ...[truncated 1074 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the required secret-bearing `--appkey` argument. 2. Read the credential from a protected environment variable or a dedicated secret manager. Avoid printing the value or including it in exception messages. 3. For interactive use, optionally support a non-echoing prompt through `getpass.getpass()` when no managed secret is available. 4. Update `SKILL.md` so its examples do not place a real credential in the command line. 5. Configure short-lived, narrowly scoped credentials and provider-side quota restrictions. 6. Document credential rotation and immediately revoke keys suspected of having appeared in shell history or logs. 7. If backward compatibility requires retaining `--appkey`, clearly mark it as deprecated and emit a warning without including the supplied value.
