T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:62
- Finding
- Broad Git Staging Can Persist Sensitive Data Missed by Filename-Only Scanning## Vulnerability Details **File Location**: `SKILL.md:62-128` **Vulnerability Type**: Incomplete secret detection followed by unrestricted Git staging **Risk Level**: Medium The SAVE procedure relies primarily on filenames and paths to identify sensitive files, but subsequently permits every modified and untracked file in `~/.openclaw` to be staged with `git add -A`. ```bash # Check for potential sensitive files in untracked/modified cd ~/.openclaw git status --short | grep -E '\.(pem|key|token)$|credentials/|secret' && echo "⚠️ SENSITIVE FILES DETECTED" ``` ```text When user says: "save before..." or "create checkpoint" 1. [REQUIRED] Check .gitignore exists - If missing: STOP and warn user 2. [REQUIRED] Scan for sensitive files - If detected: STOP and show list - Ask user to verify .gitignore 3. Show what will be committed git status --short 4. Ask user confirmation if autonomous "Will commit {count} files. Proceed?" 5. Execute commit git add -A # or targeted paths git commit -m "checkpoint: {description}" 6. Report commit hash and file count ``` ### Technical Analysis The scan examines only path names reported by `git status`. Its regular expression recognizes a limited set of patterns: `.pem`, `.key`, `.token`, `credentials/`, and names containing `secret`. It does not inspect file contents and therefore cannot identify credentials stored in otherwise ordinary files. Examples of data that can bypass this check include: - `.env` files and extensionless credential files. - API keys, access tokens, passwords, or private data embedded in JSON, Markdown, YAML, or other configuration files. - Sensitive content inside already tracked files. - User identity or memory data whose filenames do not match the expression. - Sensitive files not covered by the active `.gitignore` rules. Checking only whether `.gitignore` exists does not establish that its requir ...[truncated 1913 chars]
- Remediation
- ## Remediation Suggestions 1. Remove `git add -A` from the default SAVE workflow and require an explicit allowlist of files or directories: ```bash git add -- workspace/SOUL.md workspace/AGENTS.md ``` 2. Validate the effective ignore configuration rather than checking only for the existence of `.gitignore`: ```bash git check-ignore -v -- path/to/candidate-file ``` 3. Add mandatory exclusions for common credential formats, including `.env`, `.env.*`, authentication stores, cloud-provider credentials, SSH material, and local backup files. 4. Inspect the contents of staged changes before committing: ```bash git diff --cached --name-status git diff --cached ``` Integrate a reputable local secret scanner where available. 5. Perform scanning after staging and before committing so the scan covers the exact snapshot that will enter Git history. Abort the commit when suspicious content is found. 6. Exclude identity, user, and memory files from checkpoints by default. Require explicit, per-operation confirmation before staging these paths. 7. Display the exact staged file list to the user and require confirmation when any file falls outside a predefined configuration allowlist. 8. Document a response procedure for accidental commits, including credential rotation and proper Git-history rewriting. Simply deleting the working-tree file or adding it to `.gitignore` does not remove previously committed data.