Security Audit: Multi-Pass Application Security Review

Structured, multi-pass security audit. Combines automated tooling with manual pattern analysis, maps findings to OWASP Top 10:2025, and produces a prioritized report.

Patterns drawn from real OSS incidents (unauthenticated admin endpoints, credential exfiltration, zip slip, auth bypass whitelists, Trivy supply chain compromise) and OpenSSF/SLSA/OWASP standards.

Target versions (May 2026):

• Semgrep 1.161.0, Bandit 1.9.4
• Gitleaks 8.30.1, Betterleaks 1.1.1 (successor by same author), TruffleHog 3.95.2
• Trivy 0.70.0 (0.69.4-0.69.6 was compromised - see known incidents; 0.70.x is the safe upgrade path)
• OpenSSF Scorecard 5.1.0 (v6 in proposal stage)
• OWASP Top 10:2025 (confirmed January 2026), OWASP Agentic Top 10:2026 (released December 2025)

Scope: TypeScript/JavaScript (Bun, Node.js, Deno), Python, Go, Rust web applications, CLI tools, Dockerfiles, Compose stacks, CI/CD workflows, Helm charts, Terraform, Proxmox/LXC configs, shell scripts. This skill is SAST + config + supply chain. Not DAST or network pentesting.

When to use

• Security review of application code, services, or self-hosted apps
• Secret scanning, dependency audit, auth review, or OWASP-focused assessment
• Supply chain review for build config, CI/CD, containers, or AI-agent integrations
• Pre-release security gate for a repository or deployment artifact

When NOT to use

• Correctness bugs, logic errors, or race conditions without a security angle - use code-review
• Style, slop, or maintainability cleanup - use anti-slop
• CI/CD pipeline design, runner architecture, or pipeline hardening strategy - use ci-cd
• Offensive testing, privilege escalation, or post-exploitation work - use lockpick
• Novel vulnerability research, fuzzing, patch diffing, or exploit development - use zero-day
• Network appliance administration or firewall tuning - use firewall-appliance
• Linux networking setup and troubleshooting - use networking

AI Self-Check

Before returning any security audit report, verify:

• All automated tools attempted: betterleaks/gitleaks/trufflehog, semgrep/bandit, trivy/audit ran (or noted as missing)
• No false positives included: each finding reviewed independently, uncertain items marked "possible false positive"
• Severity classification accurate: follows the report guide table, not inflated for impact
• OWASP mapping present: each finding maps to the relevant OWASP Top 10:2025 category
• Remediation is specific: concrete fix per finding, not generic advice ("validate input" is insufficient)
• Commit SHA recorded: report anchored to a specific point in time
• Report gitignored: warned user and checked .gitignore for SECURITY-AUDIT.md
• Known incidents checked: dependency audit verified against the known supply chain incidents listed in Step 3 (event-stream, ua-parser-js, colors any version, faker, polyfill.io, xz-utils, trivy 0.69.4-0.69.6, TrapDoor, Mini Shai-Hulud worm, outdated lodash), not just CVE databases
• Agentic risks covered (when applicable): MCP servers, AI tool handlers, prompt injection surfaces audited if present
• Scope respected: no external service probing, no DAST, repo-only analysis
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• Threat model matched: findings map to the app's actual assets, actors, trust boundaries, and deployment
• Exploitability stated carefully: severity is based on reachable paths and impact, not scanner labels alone

Performance

• Run secret and dependency checks early; they are cheap and often high impact.
• Prioritize auth, authorization, input handling, deserialization, and supply-chain paths before low-risk headers.
• Use targeted dynamic tests for risky flows instead of broad unauthenticated crawling only.

Best Practices

• Separate confirmed vulnerabilities, hardening recommendations, and open questions.
• Protect sensitive findings and reproduction data in reports.
• Include concrete remediation and verification steps for each material finding.

Workflow

Step 1: Preflight

1. Detect project language(s) and framework(s) from manifest files (package.json, requirements.txt, go.mod, Cargo.toml, etc.)
2. Check which tools are available (run in parallel, each with ; true to avoid failing on missing):
   • command -v semgrep, command -v betterleaks, command -v gitleaks, command -v trufflehog, command -v trivy, command -v scorecard, command -v checkov
3. Missing tools: note as "skipped (not installed)" in the report. Don't install without asking. Critical tools (at least one must be available): betterleaks or gitleaks or trufflehog (secret scanning), semgrep (static analysis). If all critical tools are missing, warn that the audit will be manual-only and significantly less thorough.
4. Determine scope: user-specified files > uncommitted changes (offer choice) > full repo.
5. Record current commit SHA for the report.

Step 2: Secret Scanning (Pass 1 - Automated)

Find hardcoded credentials, API keys, tokens, and secrets in code and git history.

Tools (preference order, use whatever's available):

1. betterleaks detect --source . or gitleaks detect --source . --report-format json --report-path /tmp/gitleaks-report.json
2. trufflehog filesystem . --json > /tmp/trufflehog-report.json
3. Fallback: use rg, grep, or equivalent pattern search with references/grep-patterns.md (Secret Scanning Fallback section)

Also check git history for committed-then-removed secrets: git log --all --diff-filter=A - '*.env*'

What to look for: hardcoded API keys, passwords/tokens in source, .env in git history, base64-encoded creds, private keys, connection strings with embedded passwords, OAuth client secrets.

Step 3: Dependency Audit (Pass 2 - Automated)

Find known CVEs in dependencies and assess supply chain risk.

Tools by ecosystem (pick the one matching the lockfile):

• Bun (bun.lock/bun.lockb): bun audit --audit-level=high (supported levels: low, moderate, high, critical)
• npm (package-lock.json): npm audit --audit-level=high --omit=dev
• pnpm (pnpm-lock.yaml): pnpm audit --audit-level high --prod
• yarn (yarn.lock): yarn npm audit --severity high (Berry) or yarn audit --level high (Classic)
• Python: pip-audit --format json or safety check --json
• Go: govulncheck ./...
• Rust: cargo audit --json - also check for unsafe blocks without // SAFETY: comments, transmute misuse, unvalidated FFI boundaries
• General: trivy fs --scanners vuln . (use Trivy 0.70.0+ from official releases, or 0.69.3 only as a March 2026 incident rollback; never use 0.69.4-0.69.6)

Flag: HIGH/CRITICAL CVEs with fixes available, deps unmaintained 2+ years, lockfile out of sync with manifest, non-standard registries.

Known supply chain incidents - flag these by name, not just by CVE:

• event-stream 3.3.6 (2018 backdoor targeting bitcoin wallets)
• ua-parser-js 0.7.29/0.8.0/1.0.0 (2021 cryptominer injection)
• colors any version / faker 6.6.6 (2022 maintainer sabotage - t