Auditors of government contractors accept vulnerability management that is defined, repeated and evidenced: a stated scope, a scanning cadence, remediation timelines by severity, extra priority for known exploited flaws, tracked exceptions and proof that fixes were applied. They rarely reward a tool. They reward a process you can show working.
What are auditors actually testing?
They test whether what you wrote matches what you do. For contractors handling Controlled Unclassified Information, the reference is NIST SP 800-171, whose Revision 3 was published in May 2024 and supersedes Revision 2. It sets security requirements for protecting CUI in nonfederal systems, and its families include risk assessment and system and information integrity, where vulnerability monitoring, scanning and flaw remediation live. Which revision and which requirements apply to you depends on your contract and any assessment program in it, so check the contract text.
Federal systems and cloud offerings have their own rules, and those differ again. This post covers the common core.
What does the evidence look like?
Think in four artifacts.
Scope. A list of systems, applications and environments in scope, matched to where the sensitive data flows. Auditors find the gap in what you left out, so be complete and keep the list current.
Cadence. Scans on a defined schedule and on change: authenticated infrastructure scans, dependency and container scans in the build, and code scanning. Logs showing they ran, with dates.
Timelines. A written policy such as "critical within X days, high within Y days" with your own numbers, chosen to be achievable and tied to risk. A policy you routinely miss is worse than a longer one you meet.
Closure. Tickets or records for each finding with owner, dates and the fix, plus a rescan showing it is gone.
How should you prioritize?
Severity scores alone produce long, undifferentiated lists. Add two signals. First, whether the flaw is known to be exploited: CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation, and treating anything on it that you run as top priority is easy to defend. Second, exposure and reachability: an internet-facing service with a reachable flawed function outranks an internal tool that never calls it. Write the rule down so two engineers reach the same answer.
How do you handle exceptions?
Some findings cannot be fixed on time: a vendor fix does not exist, or an upgrade breaks a certified system. Auditors expect these to be tracked, not hidden. Use a plan of action and milestones, or an equivalent register, with the finding, the reason, compensating controls, an owner and a target date. Review it on a schedule. A short, honest exception list reads as maturity.
A constructed audit walk-through
The assessor asks for the last quarter's scan evidence for a system in scope. You show the scan schedule, three dated reports, the findings export, and a ticket for one high severity finding opened on the day it was found, fixed in an agreed window, and closed after a rescan. The assessor then picks an item from the exception register and asks what changed since the last review. Because you have a dated review note, the conversation is short.
What commonly fails?
Scope drift, where new systems appear without scanning. Findings closed without a rescan. Tools running with no one reading the output. Policies with timelines nobody meets. Open source dependencies missing from the inventory because they are not "systems".
What to do
- Write down the in-scope systems and review the list every quarter.
- Set a scanning cadence for infrastructure, dependencies, containers and code.
- Publish remediation timelines by severity that you can meet.
- Prioritize known exploited and reachable flaws first.
- Open a ticket for every finding and close it only after a rescan.
- Keep an exception register with compensating controls and review dates.
- Store evidence in one place, organized by quarter.
- Read your contract to confirm the NIST revision and assessment rules.
Safeguard's dependency scanning, reachability analysis and compliance automation can help produce the software side of this evidence. It does not certify you against any framework or assessment.
Quick check
Do auditors require a specific scanner?
Generally no. They require that scanning happens at the stated cadence and that findings are tracked to closure.
Is the KEV catalog a legal requirement for contractors?
Not generally for contractors. It is a strong prioritization signal that is easy to justify to an auditor, and federal agencies have their own directives around it.
Sources
- NIST SP 800-171 Rev. 3
- CISA Known Exploited Vulnerabilities Catalog
- NIST SP 800-218: Secure Software Development Framework
Last reviewed: 18 October 2026.
