Audit-ready evidence for vulnerability management.

What auditors look for

ISO/IEC 27001:2022 Annex A.8 (the renumbered control set) covers vulnerability management under A.8.8 (technical vulnerabilities) and A.8.25–A.8.34 (secure development lifecycle). Auditors want evidence on three axes:

• Identification. A documented, repeatable process that surfaces vulnerabilities — not just CVEs but code-level weaknesses (input validation, auth, crypto).
• Evaluation. Risk-based prioritisation. Critical and high-severity must be addressed within defined SLAs.
• Remediation. Action taken, tracked, and closed. Evidence retained.

How RepoWarden fits

Each enabled repo gets a monthly LLM-deep scan. Findings are classified critical / high / medium / low using the same rubric your assessor expects (CVSS-aligned). They become tickets on a kanban board with file/line evidence, suggested fix, and reproduction steps. When the team merges a remediation PR, the ticket automatically transitions through in-review → done — closing the loop your auditor wants to see.

The scan history page (/repos/<repo>/security) is what you screen-share to the auditor: scan dates, findings count, commit SHA at scan time, time-to-remediation. Everything timestamped, everything attributable.

Mapping to specific controls

• A.8.8 Technical vulnerabilities. Monthly scan + tickets + remediation tracking.
• A.8.25 Secure development. CE+ readiness audit covers auth, validation, crypto.
• A.8.28 Secure coding. Findings include suggested fix as a code-block; auditor can verify the patch landed.
• A.8.29 Security testing in development. Scan runs on every active repo; result history is per-commit.
• A.5.36 Compliance with policies, rules and standards. CSV export of scan history available on request for evidence packs.