T09 · Insecure Skill Coding Practices
- Location
scripts/security-check.sh:156- Finding
Secret-bearing workspace lines can be exposed through audit output and generated reports
- Content
View full analysis
/dev/null | grep -v ".git" | head -5; then print_result "WARN" "Potential hardcoded key detected" "Review the files shown above" fi ``` Related report-generation behavior: ```bash ./scripts/security-check.sh > ~/openclaw-security-report.md ``` ```json "scripts": { "check": "./scripts/security-check.sh", "audit": "./scripts/security-check.sh --verbose", "report": "./scripts/security-check.sh > report.md" } ``` ### Technical Analysis The recursive `grep` command prints complete matching lines from the entire `~/.openclaw/workspace` tree. It does not restrict scanning to source-code directories, exclude logs or Agent memory, or redact token values. Consequently, a line containing a real API key, bearer token, authorization header, or other credential is written directly to standard output. The documented and configured report commands redirect that output into persistent report files. The project also describes reports as suitable for sharing, increasing the chance that credentials will be copied into CI artifacts, support bundles, audit deliverables, backups, or customer-facing reports. The `.git` exclusion is also incomplete: `grep -v ".git"` filters output lines rather than reliably excluding the `.git` directory during traversal. ### Attack Path 1. A real API key or bearer token is present in a source file, log, generated report, conversation memory, or another file under `~/.openclaw/workspace`. 2. The user invokes the recommended audit or report command. 3. Recursive `grep` reads the file and prints the complete matching line ...[truncated 758 chars]- Remediation
View remediation
