NIST CSF 2.0 ID.RA-01: Identify, Validate and Record Vulnerabilities

ID.RA-01 says vulnerabilities in assets are identified, validated, and recorded. Three steps, in order. Find them, confirm they are real and apply to you, and put them in a record that someone owns. Skipping validation fills the queue with noise. Skipping the record means fixes depend on memory.

CSF is voluntary guidance. There is no CSF certification, so nobody can be "NIST compliant" for running a scanner.

What good looks like

Scanning covers the places vulnerabilities actually live: operating systems and packages, cloud and application configuration, your own code, third party libraries, and architecture. Findings are checked for exposure before they are escalated. Every confirmed item sits in one system with an owner, severity and status.

How to implement it

1. Match methods to asset types. Use a vulnerability scanner for hosts and containers, dependency analysis for libraries, static and dynamic testing for your own applications, and configuration checks for cloud accounts.
2. Review architecture for design weaknesses at least once for each critical system, such as flat networks or shared credentials.
3. Assess physical sites that house critical computing assets, such as an office server closet, for access and resilience issues.
4. Monitor threat intelligence sources for new vulnerabilities in products you run (see ID.RA-02).
5. Validate. For each finding, ask: is the vulnerable component present, is the vulnerable code reachable, is the asset exposed, is there a known exploit? Reachability analysis, which checks whether your code actually calls the vulnerable function, removes a large share of false urgency.
6. Record in a single tracker with the asset, finding, evidence, severity, owner, due date and status.
7. Rescan after fixes and close with proof.

Coverage by asset type

A short matrix keeps coverage honest. For each asset type, note the method, the frequency and the owner.

• Hosts and containers: authenticated vulnerability scanning and image scanning, weekly or on every build.
• Open source libraries: dependency analysis against known vulnerability data, on every pull request and on a schedule for deployed software.
• Own code: static analysis and code review in the pipeline, plus dynamic testing of running applications.
• Cloud and SaaS configuration: continuous configuration checks against your chosen baseline.
• Architecture: design review at launch and after major changes.
• Facilities: a walkthrough checklist at least annually for sites with critical equipment.

Gaps in the matrix are your real vulnerabilities in coverage, and they are worth tracking in the same register.

Validation in practice

Validation is the step that earns trust. A useful sequence is: confirm the affected version is deployed, check whether the vulnerable function is reachable from your code, check whether the asset is internet facing or holds sensitive data, and check whether exploit code or active exploitation is known. Record the answers on the finding. A critical rated library flaw in a function your code never calls may be real but low urgency. A medium flaw on an internet facing service with public exploit code may deserve to jump the queue. Writing down the reasoning protects the team when someone later asks why an item waited.

What the record should contain

Every recorded vulnerability needs enough detail that another person can act without asking questions: affected asset and owner, identifier such as a CVE, where it was found, how it was validated, severity and the adjusted priority, due date, current status and links to the fix or exception. When an item is closed, store the rescan result or the pull request that fixed it.

Linking to the rest of the framework

This outcome feeds others. Prioritizing recorded vulnerabilities is the subject of ID.RA-06 and ID.RA-04, and disclosure handling for your own products sits in ID.RA-08. Keeping the record clean here makes the later steps much easier.

Try it yourself

The demo shows a vulnerability moving from detection through validation to a recorded, prioritized item.

Click through it at your own pace, or open it full screen.

For a quick look at library risk in one project, the free in browser dependency scan at https://gold.safeguard.sh/scan checks a manifest without any setup.

Evidence to collect

• Scan schedules and recent reports for each asset type.
• The vulnerability tracker with validation notes.
• A sample of findings showing the path from detection to closure.
• Architecture review notes for critical systems.
• Rescan results after fixes.

Common gaps

• Scans run but results stay in a dashboard no one owns.
• Own code is tested and third party libraries are not, or the reverse.
• No validation step, so teams stop trusting the scanner.
• Configuration and architecture weaknesses are not tracked as vulnerabilities at all.
• Facilities are never assessed.

Quick check

Sources

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf