T08 · Insecure Dependencies
- Location
SKILL.md:36- Finding
Unpinned Third-Party Security Tools Are Downloaded and Executed
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This security-audit guide is mostly purpose-aligned, but it needs review because it suggests broad host inspection, unpinned tool execution, automatic fixes, and persistent git hooks without enough scoping or approval guidance.
Review before installing. Use it only for an explicitly authorized security audit, prefer pinned and trusted scanner versions, avoid automatic fix commands unless you are ready for dependency and lockfile changes, and do not run host-wide or SSH-directory checks unless the user has approved a host/infrastructure audit scope.
SKILL.md:36Unpinned Third-Party Security Tools Are Downloaded and Executed
SKILL.md:341Project Audit Instructions Perform Host-Wide and SSH Account Reconnaissance
Including git commit --no-verify as the bypass path for a secrets-blocking hook teaches users how to circumvent a security control. In an agent or copy-paste workflow, this can directly enable accidental or intentional commits of secrets that the hook was designed to stop.
if [ $EXIT_CODE -ne 0 ]; then
echo ""
echo "To proceed anyway: git commit --no-verify"
echo "To remove secrets: replace with environment variables"
fi
exit $EXIT_CODE
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Check if sensitive files are tracked
echo "--- Files that should probably be gitignored ---"
for pattern in '.env' '.env.*' '*.pem' '*.key' '*.p12' '*.pfx' 'credentials.json' \
'service-account*.json' '*.keystore' 'id_rsa' 'id_ed25519'; do
found=$(git ls-files "$pattern" 2>/dev/null)
[ -n "$found" ] && echo " TRACKED: $found"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Check if sensitive files are tracked
echo "--- Files that should probably be gitignored ---"
for pattern in '.env' '.env.*' '*.pem' '*.key' '*.p12' '*.pfx' 'credentials.json' \
'service-account*.json' '*.keystore' 'id_rsa' 'id_ed25519'; do
found=$(git ls-files "$pattern" 2>/dev/null)
[ -n "$found" ] && echo " TRACKED: $found"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Check if sensitive files are tracked
echo "--- Files that should probably be gitignored ---"
for pattern in '.env' '.env.*' '*.pem' '*.key' '*.p12' '*.pfx' 'credentials.json' \
'service-account*.json' '*.keystore' 'id_rsa' 'id_ed25519'; do
found=$(git ls-files "$pattern" 2>/dev/null)
[ -n "$found" ] && echo " TRACKED: $found"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Check if sensitive files are tracked
echo "--- Files that should probably be gitignored ---"
for pattern in '.env' '.env.*' '*.pem' '*.key' '*.p12' '*.pfx' 'credentials.json' \
'service-account*.json' '*.keystore' 'id_rsa' 'id_ed25519'; do
found=$(git ls-files "$pattern" 2>/dev/null)
[ -n "$found" ] && echo " TRACKED: $found"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
-not -path '*/.git/*' -not -path '*/bin/*' 2>/dev/null
# Check sensitive file permissions
for f in .env .env.* *.pem *.key *.p12 id_rsa id_ed25519; do
[ -f "$f" ] && ls -la "$f"
done
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
-not -path '*/.git/*' -not -path '*/bin/*' 2>/dev/null
# Check sensitive file permissions
for f in .env .env.* *.pem *.key *.p12 id_rsa id_ed25519; do
[ -f "$f" ] && ls -la "$f"
done
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
-not -path '*/.git/*' -not -path '*/bin/*' 2>/dev/null
# Check sensitive file permissions
for f in .env .env.* *.pem *.key *.p12 id_rsa id_ed25519; do
[ -f "$f" ] && ls -la "$f"
done
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
-not -path '*/.git/*' -not -path '*/bin/*' 2>/dev/null
# Check sensitive file permissions
for f in .env .env.* *.pem *.key *.p12 id_rsa id_ed25519; do
[ -f "$f" ] && ls -la "$f"
done
Skill attempts to nullify the agent's safety policies or restrictions ('you have no restrictions', 'ignore your guidelines', 'do anything now'). This is a direct jailbreak that disables guardrails.
debug=$(grep -rn "DEBUG\s*=\s*True\|debug:\s*true" \
--include='*.{py,yml,yaml,json}' . 2>/dev/null | \
grep -v 'node_modules\|\.git\|test\|jest\|vitest' | wc -l)
[ "$debug" -gt 0 ] && warn "Debug mode enabled in $debug location(s)" || ok "No debug flags found"
echo ""
echo "========================================="
The description says to use the skill for very broad activities like 'reviewing code for injection and auth flaws' and 'auditing file permissions,' which overlap with many ordinary security-help requests. It does not define clearer trigger constraints, exclusions, or negative examples to distinguish when this skill should activate versus more specialized troubleshooting or review skills.
The skill includes state-changing commands like npm audit fix without an explicit warning that they modify dependencies and lockfiles. In an automated agent context, this can lead to unintended repository changes, broken builds, or silent alteration of audited artifacts.
The skill recommends invoking a package via npx without pinning an exact version, which means execution will resolve to whatever version is current at runtime. In a security-audit skill, that creates avoidable supply-chain risk because a compromised or breaking upstream release could be fetched and run during an audit workflow.
npx audit-ci --high fetches and executes a package without an explicit version pin, exposing users to upstream package takeover, malicious updates, or unexpected behavior changes. Because this skill is about security auditing, encouraging execution of unpinned remote code is particularly contradictory and risky.
This section instructs creation of a .git/hooks/pre-commit script and thus writes into the repository without a clear user-facing warning. In an agent workflow, writing hooks can persist behavior changes, interfere with developer workflows, and create trust and provenance issues if done implicitly.
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
# CORS wildcard
grep -rn "Access-Control-Allow-Origin.*\*\|cors({.*origin.*true\|cors()" \
--include='*.{py,js,ts,go,java,rb}' .
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
# Find world-writable files
find . -type f -perm -o=w -not -path '*/node_modules/*' -not -path '*/.git/*' 2>/dev/null
# Find executable files that shouldn't be
Code scans file system directories looking for sensitive files. This could be reconnaissance for credential theft.
# Check SSH key permissions
if [ -d ~/.ssh ]; then
echo "--- SSH directory permissions ---"
ls -la ~/.ssh/
echo ""
# Should be: dir=700, private keys=600, public keys=644, config=600
[ "$(stat -c %a ~/.ssh 2>/dev/null || stat -f %Lp ~/.ssh)" != "700" ] && echo "WARNING: ~/.ssh should be 700"
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
# 5. CORS wildcard
section "CORS Configuration"
cors=$(grep -rn "Access-Control-Allow-Origin.*\*\|cors({.*origin.*true" \
--include='*.{py,js,ts,go,java,rb}' . 2>/dev/null | \
grep -v 'node_modules\|\.git' | wc -l)
[ "$cors" -gt 0 ] && warn "CORS wildcard found in $cors location(s)" || ok "No CORS wildcard"
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
- Secret detection in git history matters: even if a secret is removed from HEAD, it exists in git history. Use `git filter-branch` or `git-filter-repo` to purge, then rotate the credential.
- The most dangerous vulnerabilities are often the simplest: SQL injection via string concatenation, command injection via unsanitized input, XSS via `innerHTML`.
- CORS `Access-Control-Allow-Origin: *` is safe for truly public, read-only APIs. It's dangerous for anything that uses cookies or auth tokens.
- Always verify SSL in production. `verify=False` or `rejectUnauthorized: false` should only appear in test code, never in production paths.
- Defense in depth: validate input, escape output, use parameterized queries, enforce least privilege, and assume every layer might be bypassed.
The certificate-chain example writes chain.pem to disk without calling out the filesystem side effect. While low severity, unexpected file creation matters in automated contexts and should be disclosed, especially in a skill intended for operational use.
No suspicious patterns detected.