T09 · Insecure Skill Coding Practices
Warning
- Location
- FILE-MANAGEMENT.md:156
- Finding
- Indiscriminate Workspace Staging and Remote Push May Expose Sensitive Data## Vulnerability Details **File Location**: `FILE-MANAGEMENT.md:156-160` **Vulnerability Type**: Unsafe source-control handling and potential sensitive-data disclosure **Risk Level**: Medium **Vulnerable Code Snippet**: ```bash git add -A git commit -m "Cleanup: Remove dead files" git push ``` ### Technical Analysis The documented cleanup procedure uses `git add -A`, which stages every unignored change in the current repository, followed by an immediate commit and `git push`. The same document describes a workspace that may contain sensitive material, including user profiles, long-term memory, tool notes, API-related files, configuration, logs, data, and state files. The instructions do not require the user to inspect the staged diff, verify ignore rules, scan for secrets, select files explicitly, or confirm the destination and visibility of the configured Git remote. Consequently, unrelated sensitive files could be included in a cleanup commit and transmitted outside the local environment. This is an insecure operational practice rather than deliberate malicious behavior. Its exploitability depends on sensitive files being present and unignored, and on a configured remote accepting the push. ### Attack Path 1. Sensitive or private files exist in the workspace and are not covered by `.gitignore`. 2. A user follows the documented cleanup procedure from the repository. 3. `git add -A` stages all unignored additions, modifications, and deletions, including unrelated sensitive files. 4. The user commits without reviewing the staged content. 5. `git push` uploads the commit to the configured remote repository. 6. Anyone with access to that remote, or the public if the repository is public, can retrieve the committed information. Removing the files in a later commit may not eliminate them from Git history. ### Impact Assessment The issue does not grant operating-system privileges or perform privilege escalation. It ...[truncated 495 chars]
- Remediation
- ## Remediation Suggestions Replace blanket staging and immediate pushing with a review-based workflow: 1. Stage only the files intentionally changed, using explicit paths rather than `git add -A`. 2. Run `git status --short` and `git diff --cached` before committing. 3. Maintain a restrictive `.gitignore` covering logs, memory, state, credentials, environment files, API material, backups, and generated data. 4. Run an approved secret scanner against both the working tree and staged changes. 5. Verify the remote destination and repository visibility with `git remote -v` before pushing. 6. Require explicit user confirmation before any network-affecting `git push`. 7. If sensitive data has already been pushed, rotate exposed credentials, remove the material from repository history using an appropriate history-rewriting procedure, and coordinate removal from forks, mirrors, and caches. A safer documented example is: ```bash git status --short git add -- path/to/intended-file git diff --cached git commit -m "Cleanup: Remove reviewed dead files" git remote -v # Push only after reviewing the commit and confirming the remote. ```