T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:32
- Finding
- Automatic Broad Staging and Commit Without User Confirmation## Vulnerability Details **File Location**: `SKILL.md:32-47`; supporting implementation guidance in `references/safety-errors.md:19-24` and `references/workflow-examples.md:14-18` **Vulnerability Type**: Unrestricted staging of repository contents followed by an unconfirmed commit **Risk Level**: Medium ### Vulnerable Code `SKILL.md:32-34`: ```markdown 2. **暂存区为空**(`git diff --cached --stat` 无输出) - 先执行 `git add .` 添加所有变更 - 再分析变更内容,生成 commit message 并提交 ``` `SKILL.md:42-47`: ```markdown 所有操作都会: 1. 确认工作目录是 Git 仓库(非 Git 目录直接报错退出) 2. 检查暂存区状态(有内容→直接提交;无内容→先 git add .) 3. 分析代码变更 4. 生成符合规范的 commit message 5. 直接执行 `git commit -m "<message>"`(不需要用户确认) ``` `references/safety-errors.md:19-24`: ```bash # 3. 检查暂存区状态 if [ -z "$(git diff --cached --name-only)" ]; then echo "i️ 暂存区为空,自动执行 git add ." git add . fi ``` ### Technical Analysis When the staging area is empty, the Skill instructs the agent to execute `git add .`. This broadly stages all tracked modifications and all non-ignored, untracked files beneath the current repository path. The Skill then executes `git commit` without requesting user confirmation. This violates least-change principles for source-control automation. A request to commit intended code changes does not necessarily authorize the inclusion of every file in the working tree. The project mentions checking for sensitive information in `references/best-practices.md`, but it defines no concrete secret-detection procedure, sensitive-path denylist, staged-file review, or blocking control before the commit. An attacker does not need command execution to exploit this behavior. It is sufficient to place a sensitive or unrelated non-ignored file inside a repository and induce a user to invoke the Skill while the staging area is empty. The file can then become part of permanent Git history. ### Attack Path 1. A repository contains an untracked or modified file that th ...[truncated 1530 chars]
- Remediation
- ## Remediation Suggestions 1. Do not run `git add .` automatically. Preserve existing user staging decisions whenever possible. 2. If the staging area is empty, display `git status --short` and require the user to select or approve the exact paths to stage. 3. Prefer explicit commands such as `git add -- path/to/file` for approved files. If only modifications to already tracked files should be included, consider `git add -u` after clearly explaining its scope. 4. Before committing, display the final output of `git diff --cached --name-status` and require explicit confirmation. 5. Add blocking checks for common sensitive files and patterns, including environment files, private keys, credential exports, tokens, database dumps, and local configuration files. 6. Integrate a recognized secret scanner where available, while treating scanner success as an additional safeguard rather than a replacement for user review. 7. Abort when no files are approved, when unresolved conflicts exist, or when secret detection reports a possible credential. 8. Avoid committing automatically. Present the proposed commit message and staged-file summary, then execute `git commit` only after informed user approval.