16.12 Implement Code-Level Security Checks
Use static and dynamic analysis tools across the application life cycle to confirm secure coding practices are being followed. Implementation Group: IG3 only (for enterprises facing sophisticated attackers or holding highly sensitive data). Asset type: Software. Security function: Protect.
Source: CIS Controls v8.1, 16.12. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open CIS Controls v8.1 in the compliance library.
Each safeguard shows its Implementation Groups. IG1 is the essential baseline for every enterprise, IG2 adds to it, IG3 is all 153. Version 8.1 adds the Govern security function and asks for more processes to be documented; numbering is unchanged from v8.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- SAST and DAST tool configuration in CI/CD pipelines · Source control / CI pipeline
- Scan results and triage records · Vulnerability scanner / patch tooling
periodic reviewEvidence produced at each review
none for this control
governing documentDocuments that govern the control
- Build gates on high-severity findings · Policy repository / GRC workspace
First move
Common gaps auditors find
- Scans run but results ignored
- Only some repositories scanned
- No dynamic testing
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet16.11 Leverage Vetted Modules or Services for Application Security Components · 16.13 Conduct Application Penetration Testing