T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/sync.sh:76
- Finding
- Unrestricted Staging and Upload of Potentially Sensitive Repository Contents<![CDATA[ ## Vulnerability Details **File Location**: `scripts/sync.sh:76-84` and `scripts/sync.sh:141-150` **Vulnerability Type**: Uncontrolled sensitive-data inclusion in automated Git backup **Risk Level**: High ### Vulnerable Code ```bash if [ "$TRACKED_CHANGES" = true ] || [ "$UNTRACKED_FILES" = true ]; then log_info "Changes detected. Staging all files..." git add . log_success "All changes staged successfully." else log_info "No uncommitted changes found." fi ``` ```bash # Step 11: Push to remote log_info "Pushing changes to remote branch '$CURRENT_BRANCH'..." if git push origin "$CURRENT_BRANCH" 2>/dev/null; then log_success "Successfully pushed to remote." else log_warning "Standard push failed (no upstream set). Attempting to set upstream..." if git push --set-upstream origin "$CURRENT_BRANCH" 2>/dev/null; then log_success "Successfully pushed with new upstream branch tracking." ``` ### Technical Analysis The script recursively stages all tracked and untracked files that are not already excluded by Git configuration through `git add .`. It subsequently commits and pushes those files to the configured `origin` remote without: - Restricting the backup to an explicit allowlist of intended memory files. - Detecting credentials, private keys, tokens, `.env` files, or other sensitive configuration. - Displaying the staged file list for approval. - Requiring confirmation before transmitting data to the remote repository. The large-file scan only excludes files based on size and provides no protection against small sensitive files. Although `SKILL.md` advises users not to commit credentials, this is documentation rather than an enforced security control. Once sensitive content is committed and pushed, deleting the working-tree file does not necessarily remove it from Git history. Anyone with access to the remote repository or its historical objects may continue to retrieve the exposed content. ### Attack Path 1. ...[truncated 1432 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace `git add .` with an explicit allowlist of files or directories that the skill is intended to back up. 2. Resolve and validate the repository root before staging, and reject operation outside the expected workspace. 3. Before committing, inspect staged paths and content for common sensitive patterns, including: - `.env` and environment-specific variants. - PEM, SSH, PGP, and other private-key files. - Cloud credential files. - Access tokens, passwords, connection strings, and high-entropy secrets. 4. Run a dedicated secret scanner against staged changes and stop the operation when findings are detected. 5. Print the complete staged-file list and require explicit user confirmation before committing and pushing. 6. Maintain a secure default `.gitignore` containing common credential and private-configuration patterns. 7. Use path-scoped staging, for example: ```bash git add -- memory/ approved-backup-path/ ``` 8. If sensitive data has already been pushed, revoke and rotate affected credentials immediately, purge the data from Git history with an appropriate history-rewriting tool, force-push the sanitized history where permitted, and verify that remote caches, forks, and mirrors are addressed. ]]>