SSDF RV.1.1 asks you to gather information on possible vulnerabilities in your software and its third-party components from acquirers, users and public sources, and to investigate every credible report. A routine has three parts: automated matching against your inventory, a place for people to report, and a triage owner.
What RV.1.1 says
The task text: gather information from software acquirers, users and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports. NIST's examples include monitoring vulnerability databases and mailing lists by manual or automated means, using threat intelligence to understand how vulnerabilities are exploited, and automatically reviewing provenance and software composition data for new vulnerabilities.
Three input streams
| Stream | What it catches | Evidence |
|---|---|---|
| Inventory matching | New advisories for components you ship | Scan logs, alert records |
| Public sources | Mailing lists and databases for your stack | Subscription list, review notes |
| Reports from people | Customer and researcher reports | Intake inbox, ticket history |
The inventory is the base. Without a current SBOM or dependency list per release, you cannot tell whether an advisory applies to you.
Steps
- Keep an inventory per supported release (see PS.3.2).
- Schedule automatic matching of that inventory against vulnerability data, daily if you can.
- Subscribe a shared mailbox, not a person, to sources for your main languages and platforms.
- Publish a way to report issues, such as a security contact page.
- Name a triage owner each week, with a backup.
- Log each credible report as a ticket with a start time.
What investigate means
For each credible report, confirm whether you ship the affected component, whether the vulnerable path is present and what the exposure is. Those answers feed RV.2, where you analyze and prioritize. Keep the notes brief but dated.
Keep the noise down
A stream of unfiltered alerts trains people to ignore them. Group alerts by component, drop findings for components you do not ship, and track how long credible reports sit untouched. That last number tells you more than the alert count.
Measuring whether it works
Pick two simple measures. First, the time between a vulnerability becoming public and your team recording a decision on it. Second, the number of credible reports older than your own target that still lack a decision. Review both monthly. If they drift, the cause is usually ownership, not tooling: a triage role with no backup, or alerts sent to a mailbox nobody reads. Fix the routine first, and then tune the tools.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how new findings appear against an existing inventory without a manual rescan.
Quick check
Is a weekly scan enough for RV.1.1?
NIST does not set a frequency. Choose one that fits your risk, document it and follow it.
Do customer reports count?
Yes. The task names acquirers and users as sources, so keep their reports in your tracking system.
Safeguard offers SBOM and dependency scanning and zero-day discovery, and the free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
