testing/security-testing

security testing Shipped

What this lens looks for

Security scans MUST be run as part of post-generation verification — they are CLI tools the agent can invoke directly, so "not run" is a failure, not an acceptable default. Three layers, matched to the changed code's stack: (1) SAST — Semgrep for all languages (semgrep scan --config=auto .), Bandit for Python (bandit -r src/), CodeQL for deep analysis (Swift, Kotlin, C#, Python, TS, Go); (2) Dependency scanning — pip-audit (Python), npm audit (Node.js), dotnet list package --vulnerable (.NET), or Snyk (snyk test) for any stack; (3) DAST — OWASP ZAP against running web services (zap-cli quick-scan http://localhost:...) when the change is web-facing. Reviewer's stance: confirm the layers appropriate to the diff's language and surface were actually run and came back clean; treat high/critical SAST findings and vulnerable dependencies as blocking, and pair scanning with the implementing/security guidelines for the full reference.

What its verifier checks

SAST run for the changed code's language (semgrep scan --config=auto ., plus Bandit for Python / CodeQL for deep analysis) with no critical findings; dependency scan run for the stack (pip-audit / npm audit / dotnet list package --vulnerable / Snyk) with no high or critical vulnerabilities; DAST (OWASP ZAP) run against the local service when the change is web-facing; the security layers matching the diff's language and surface were actually executed (not skipped) and any high/critical finding is resolved before completion.