For SSDF RV.1 and RV.2, show that you watch for vulnerabilities in your software and its components, have a disclosure policy, analyze each finding for risk, and record whether you fix, mitigate or accept it. Evidence is monitoring setup, the policy, tickets with risk notes and decisions.
The tasks
| Task | In plain words |
|---|---|
| RV.1.1 | Gather information from acquirers, users and public sources and investigate credible reports |
| RV.1.2 | Review, analyze or test code to find previously unknown vulnerabilities |
| RV.1.3 | Have a disclosure and remediation policy with roles and processes |
| RV.2.1 | Analyze each vulnerability for enough risk information to plan a response |
| RV.2.2 | Plan and implement risk responses |
RV.1 evidence
Examples in SP 800-218 version 1.1 include monitoring vulnerability databases and mailing lists, using threat intelligence, automatically reviewing provenance and component data for new vulnerabilities, and running automated code analysis and testing regularly for all supported releases.
For RV.1.3 the examples include a vulnerability disclosure program that is easy for researchers to find, a product security incident response team and a playbook for reported vulnerabilities, zero days and exploited ones, plus periodic exercises.
Keep: the disclosure policy and its published location, monitoring configuration, an exercise record.
RV.2 evidence
RV.2.1 examples say to record each vulnerability in your issue tracker and calculate risk from estimated exploitability, potential impact and other characteristics. RV.2.2 examples say to make a risk based decision whether to remediate or address through other means such as risk acceptance, to plan temporary mitigation when a fix is not yet available, and to publish advisories for acquirers when needed.
Keep a ticket per vulnerability with these fields: source, affected component, risk rating, decision, owner, dates.
Make the ticket carry the decision
The cleanest evidence is a ticket that tells the whole story in order: where the report came from, what is affected, how risky it is and why, what was decided, and when it was done. If a vulnerability is accepted rather than fixed, add the reason, an owner and a review date. Auditors who sample three tickets and find that structure in each will usually move on quickly.
Try it yourself
Open the demo and see how exploitability changes which findings matter first. That is the same reasoning RV.2.1 asks you to record.
Click through it at your own pace, or open it full screen.
Quick check
Must every vulnerability be fixed?
No. RV.2.2 examples allow a risk based choice between remediation and other responses such as risk acceptance, with the decision recorded.
What if no fix exists yet?
The examples say to determine a temporary mitigation and add it to the plan until a permanent fix is available.
Where tooling helps
Safeguard offers zero day discovery, SBOM and dependency scanning, reachability analysis and compliance and evidence automation, which keep dated records of findings and decisions. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
