Reachability and exploitability records most directly support SSDF practices RV.2.1, which analyzes each vulnerability, and RV.2.2, which plans risk responses. They can also feed RV.1.1 monitoring. They do not demonstrate that you meet the framework as a whole, and no record on its own is a certification.
What the framework text says
NIST SP 800-218 groups vulnerability response under "Identify and Confirm Vulnerabilities on an Ongoing Basis" (RV.1), "Assess, Prioritize, and Remediate Vulnerabilities" (RV.2) and root cause analysis (RV.3). The task wording below is from SSDF version 1.1.
- RV.1.1: gather information from acquirers, users and public sources on potential vulnerabilities in the software and its third party components, and investigate all credible reports.
- RV.2.1: analyze each vulnerability to gather sufficient information about risk to plan its remediation or other risk response.
- RV.2.2: plan and implement risk responses for vulnerabilities.
- RV.1.3: have a policy that addresses vulnerability disclosure and remediation, with roles, responsibilities and processes.
A mapping you can hand over
| SSDF task | Record that supports it | What it does not show |
|---|---|---|
| RV.1.1 | Feed or scan results showing components checked against advisories | That every credible report was found |
| RV.2.1 | Reachability result, exploited in the wild check, severity, impact note per finding | That the analysis was correct for every code path |
| RV.2.2 | Decision record: fix, defer, accept, with owner and date | That the response was adequate for the risk |
| RV.1.3 | Written policy and role assignments | That people follow it |
The notional examples in RV.2.1 mention risk calculations based on estimates of exploitability and the potential impact if exploited. A reachability result is one input to the exploitability estimate. The examples in RV.2.2 include making a risk based decision about remediation or other means, and updating records of approved exceptions. A dated decision record is that update.
How to present it
- State the framework and version you mapped to.
- Give the table above with your own record names.
- Attach two or three sample records, redacted if needed.
- Say plainly which tasks you have not covered.
The last step is what builds trust. An honest partial map is better received than a complete looking one with gaps hidden.
Words to avoid
Do not say "SSDF compliant" or "certified" unless a recognized process has said so. Say that your records support the practices and describe how. Do not tell a customer that an attestation is required unless their contract says so.
Keep it current
SSDF version 1.1 is the text we read. Check whether a newer version applies when you prepare. Date your mapping and review it on a schedule. See also reachability analysis and your remediation record.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one record can support more than one control.
Quick check
Does a reachability tool make us SSDF compliant?
No. It produces records that support some tasks. Compliance depends on the whole process and on who is assessing it.
Which task covers a deferral with an owner?
RV.2.2 fits best, since it covers planning risk responses and recording approved exceptions.
Safeguard offers compliance and evidence automation with reachability analysis, so records can be mapped to controls and exported. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
