T09 · Insecure Skill Coding Practices
- Location
references/ship.md:53- Finding
Overly Broad Git Staging Can Publish Unintended Sensitive Files
- Content
View full analysis
Vulnerability Details
File Location:
references/ship.md, lines 53–67
Vulnerability Type: Unsafe repository staging and publication
Risk Level: MediumVulnerable Code
bash ### Step 4: Commit ```bash git add -A git commit -m "<type>(<scope>): <description> BREAKING CHANGE: <if applicable> Closes #<issue-number>"Step 5: Push
bash git push origin <feature-branch> --force-with-lease # --force-with-lease: refuses push if remote has new commitstext ### Technical Analysis The release workflow uses `git add -A`, which stages all tracked modifications, tracked deletions, and untracked files throughout the repository. It does not restrict staging to files intended for the release. The workflow subsequently commits the staged content and pushes the resulting commit to the configured remote repository. There is no intervening requirement to inspect the staged file list, review the staged diff, scan for secrets, or confirm the publication with the user. Git ignore rules may reduce exposure, but they do not provide a sufficient security boundary. Sensitive files may be unignored, ignore rules may be incomplete, or unrelated tracked files may contain local secrets or confidential changes. ### Attack Path 1. A sensitive or unrelated file is present in the repository working tree and is not excluded by Git ignore rules. Examples may include a local configuration file, generated artifact, credential file, or unrelated source change. 2. The user or release agent invokes the `/ship` workflow. 3. `git add -A` stages the unintended file together with the legitimate release changes. 4. `git commit` records all staged content in repository history. 5. `git push origin <feature-branch> --force-with-lease` transmits that commit to the configured remote. 6. Anyone with access to the remote branch or its history may obtain the unintentionally published content. This path can occur accidentally. ...[truncated 743 chars]- Remediation
View remediation
Remediation Suggestions
- Replace broad staging with an explicit allowlist of release files:
bash git add package.json package-lock.json src/ tests/- Before committing, require review of both the staged file list and staged content:
bash git diff --cached --name-status git diff --cached-
Abort automatically if staged paths are outside an approved allowlist or include sensitive patterns such as
.env, private keys, credentials, tokens, database dumps, or generated archives. -
Run a secret scanner against the staged diff before committing. Configure it to fail closed when high-confidence credentials are detected.
-
Require explicit user confirmation after displaying the exact staged paths and before executing
git commitorgit push. -
Verify that repository-specific ignore rules cover local configuration, credentials, build output, QA screenshots containing sensitive data, and temporary files. Treat ignore rules as defense in depth rather than the primary control.
-
Separate version updates from unrelated working-tree changes. Prefer running the release workflow only from a clean working tree or a dedicated temporary worktree.
-
Add preflight checks such as:
bash test -z "$(git status --porcelain)" || { echo "Working tree is not clean; review changes before release." exit 1 }If intentional release changes must already exist, capture and validate their paths before any automated versioning operation rather than accepting every working-tree change.