T09 · Insecure Skill Coding Practices
Warning
- Location
- references/scanning-gotchas.md:18
- Finding
- Unattended broad staging and potentially destructive force-push## Vulnerability Details **File Location**: `references/scanning-gotchas.md:18-19` **Vulnerability Type**: Unscoped, unattended repository publication **Risk Level**: Medium ### Vulnerable Instruction ```markdown - **Maintain a skill index**: Build and maintain `~/.hermes/profiles/<profile>/references/skill-index.md` listing all skills and their GitHub repos. Refer to it instead of re-deriving from scratch every time. After any skill file modifications, commit and push to the source repo immediately. - **Push local changes to GitHub (MANDATORY — user directive)**: After modifying any skill file (SKILL.md, references/, scripts/), **always** commit and push to the source repo immediately after testing and code verification. `git add -A && git commit -m "sync" && git push origin main` (or `--force` if remote diverged). **Do not wait for the user to ask.** This is an explicit user directive ("ALWAYS... automatically push and merge... Do not wait for the user to ask"). Never leave local changes uncommitted. ``` A related summary directive appears at `SKILL.md:118`: ```markdown - Never force model overrides on cron jobs; maintain skill index; push local changes to GitHub immediately (user directive) ``` ### Technical Analysis The instruction requires an agent to publish repository changes without obtaining current confirmation. The prescribed `git add -A` stages every tracked modification and every untracked file in the repository, rather than limiting the commit to files intentionally changed by the current Finch task. This creates a concrete scope violation when the working tree contains unrelated edits, generated artifacts, local configuration, or sensitive untracked files. All such content can be included in the commit and transmitted to the configured Git remote using the user's authenticated Git credentials. The alternative instruction to use `--force` when the remote diverges creates an additional integrity risk. A force push can rewrite remote branch ...[truncated 1825 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `git add -A` with an explicit allowlist of files modified by the current task, for example: ```bash git add -- SKILL.md references/specific-file.md scripts/specific-script.py ``` 2. Before committing, require inspection of both the file list and staged diff: ```bash git status --short git diff --cached --stat git diff --cached ``` 3. Run the project's PII and secret checks against the exact staged content before publication. 4. Remove all authorization for plain `git push --force`. If history rewriting is exceptionally required, obtain current explicit user approval and use `--force-with-lease` only after verifying the expected remote commit. 5. Validate that the configured remote URL and branch match the user-authorized repository before pushing: ```bash git remote get-url origin git branch --show-current git fetch origin ``` 6. Prefer pushing a dedicated branch and opening a reviewable pull request instead of directly updating `main`. 7. Require explicit confirmation for publication from unattended cron workflows. A historical statement recorded in Skill documentation should not serve as perpetual authorization for future remote changes. 8. Abort if unrelated working-tree changes or untracked files are present, unless the user separately authorizes their inclusion.