An audit committee needs five plain statements: what the scanners find, how management decides what to fix first, what reachability adds, what it cannot see and how decisions are checked. Add three metrics that include the open items, and a short list of questions the committee can ask management each quarter.
Why a committee cares
Members are not reading call graphs. They want assurance that known weaknesses in software are being handled by a process that can be inspected, and that nobody is hiding behind a technical label. A one page briefing gives them a way to ask good questions.
The five statements
- We find known weaknesses in the components we use. Scanners compare our software inventory with public advisories.
- Findings are ranked by more than severity. We consider whether the weakness is known to be exploited, and whether our code can reach it. CISA recommends using its exploited vulnerabilities catalog as an input to prioritization.
- Reachability helps focus effort. A library can be present without its risky function running. We check, and we record the result.
- The method has limits. Some code paths are hard to see, so unclear results are treated as risky until reviewed.
- Decisions are checked. Deferrals carry an owner, a reason and a review date. A sample is reviewed each quarter.
Three metrics that hold up
| Metric | What it tells the committee | Watch for |
|---|---|---|
| Open findings by class, including reachable, unknown and not reachable | The whole picture, not just the closed items | Unknown growing |
| Exploited in the wild findings and time to decision | Whether urgent items move first | Long tails |
| Deferrals past their review date | Whether decisions are revisited | Any non zero count |
Resist a single headline number. A falling total can mean progress or can mean relabeling. Showing all classes makes relabeling visible.
Questions the committee can ask
- What share of deferred items are classified by a person who is not the code owner?
- How many findings changed class last quarter, and why?
- Which decision would we regret if the analysis were wrong?
- What did the quarterly sample of deferrals find?
- Where are the records, and who can change them?
What the page should not say
It should not claim certifications, state that the product is secure or promise zero vulnerabilities. It should not describe an audit as complete if it is in progress. The NIST Secure Software Development Framework frames vulnerability response as analysis and risk based decisions with recorded exceptions, which is a calmer and more accurate description of what management does.
Make it a standing item
Use the same template every quarter so trends are comparable. Include the date, the owner and the policy version. For the underlying vocabulary, see vulnerable versus exploitable versus reachable versus exposed.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the same list reads once it is grouped.
Quick check
Should the committee see individual CVEs?
Rarely. Show classes and a few examples. Individual items belong with management and the auditors who sample them.
How often should the briefing be refreshed?
Each quarter, or sooner after a significant exploited vulnerability.
Safeguard provides reachability analysis, policies and evidence automation that produce the underlying records. You can try the free scan.
Sources
- Known Exploited Vulnerabilities Catalog, CISA
- NIST SP 800-218, Secure Software Development Framework 1.1
Last reviewed: 19 October 2026.
