To show root cause analysis under SSDF RV.3, record why each vulnerability happened, look for patterns across them, search the code for the same flaw, and show a change you made to your process. Evidence is cause notes on tickets, a pattern review and an updated practice.
The four tasks
| Task | What it asks |
|---|---|
| RV.3.1 | Analyze identified vulnerabilities to find root causes |
| RV.3.2 | Analyze causes over time to find patterns, such as a practice not followed consistently |
| RV.3.3 | Review the software for similar vulnerabilities and fix them proactively |
| RV.3.4 | Review the SDLC and update it to stop the cause recurring |
The aim is fewer vulnerabilities in the future, not only fixing today's.
Record the cause, not the symptom
A ticket that says "SQL injection fixed" is a symptom. A cause is the reason it got through: no review rule for query code, no test, a library helper that was easy to misuse. The examples suggest recording causes and lessons learned in a searchable wiki.
Look across tickets
RV.3.2 examples say to add toolchain mechanisms to detect future instances of a cause automatically, and to update manual processes. A quarterly look at the cause field often shows one or two repeats.
Close the loop
- Add the cause to the ticket when you close it.
- Each quarter, group causes and find repeats.
- For a repeat, search the codebase for the same pattern.
- Add a check or rule so it is caught next time.
- Record the process change with a date and owner.
What counts as proof
- Tickets with a cause field filled in
- A dated pattern review note
- A search or scan for the same flaw class
- A pull request that adds a test, rule or standard in response
- An SDLC document change log
Auditors ask: show me a vulnerability and what changed because of it. One traced example is worth more than a template.
An example chain
Suppose three findings in a quarter trace to unchecked input in different services. The pattern review notes it. A search finds two more instances, which are fixed. A lint rule and a review checklist item are added, and the secure coding standard gets a paragraph on input handling. Each step has a ticket or pull request. That chain, from findings to a changed process, is precisely what RV.3.4 describes.
Quick check
Does every low severity bug need a root cause?
The practice says to analyze identified vulnerabilities. A lighter touch for minor ones is a sensible, documented choice.
What if we find no patterns?
Record that you looked. A dated review that finds nothing still shows the practice is run.
Where tooling helps
Safeguard offers policies and gates, which can turn a repeated cause into an automatic check, and compliance and evidence automation for keeping the record. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
