What it does
Runs the configured security scanners plus functional security tests (authorization matrix, input validation, headers, rate limiting) concentrated on critical risk areas, classifies findings by severity, and fails the gate on configured block-severities. An automated OWASP Top 10 / ASVS Level 1 baseline — not a full pen-test.
When to use it
For security testing of the app/API (the automated baseline).
Prerequisites
qa.config.yml with tooling.security.* toggles, gates.security_block_on, stack.api_spec_path, environments, risk_areas; a non-prod target for DAST.
Output
Security findings report (ISO/IEC/IEEE 29119-3 Test Execution Log) -> reports_dir/SECURITY-SCAN-<scope>.md, with each above-gate finding raised as an Incident (Defect) Report to /qa:triage.
Mechanics
How it works
- Read config; gate that tooling.security is present (else route to qa-init)
- Resolve scope from arguments (sast/sca/dast/secrets/all; default all)
- Run each enabled scanner (SAST, SCA, DAST against non-prod, secrets over git history)
- Add functional security tests on critical risk areas (authz, input validation, headers, rate limiting)
- Classify findings by severity and apply the gates.security_block_on gate
- Ticket below-gate findings with owner/SLA; route confirmed above-gate findings to triage
Why it works
The theory behind it
Non-functional security testing (CT-SEC; OWASP Top 10 / ASVS) mapped to the ISO/IEC 25010 Security characteristic (confidentiality, integrity, non-repudiation, accountability, authenticity). OWASP supplies the concrete threat checklist.
CT-SEC (Specialist) · OWASP Top 10 / ASVS · ISO/IEC 25010 Security · CTFL v4.0 §2.2.2
Example
See it in use
> /qa:security-scan all✓ Correct when It uses the configured tools (Semgrep/npm-audit/OWASP-ZAP/gitleaks) and blocks on high/critical per gates.security_block_on.
Related commands
Used by