Respond to Vulnerabilities (RV)

Respond to Vulnerabilities (RV) in the Post-Deployment CI/CD Steps

Respond to Vulnerabilities (RV)

Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

RV.1

Identify and Confirm Vulnerabilities on an Ongoing Basis: Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.

To satisfy SSDF RV.1 in a post-deployment context using open-source tools, the focus shifts to:

Continuously scanning live environments for new vulnerabilities
Correlating detected vulnerabilities to deployed components and SBOM data
Validating whether vulnerabilities are exploitable in the specific environment
Prioritizing remediation based on severity, exploitability, and operational impact

Tasks	Tools
RV.1.1: 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. RV.1.2: Review, analyze, and/or test the software’s code to identify or confirm the presence of previously undetected vulnerabilities. RV.1.3: Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy.
	OWASP Dependency Track Integrates with live SBOMs to detect and alert on vulnerabilities after release.
	Ortelius Links detected vulnerabilities directly to deployed service versions for traceability.
	DefectDojo Central vulnerability management hub with metrics and tracking.
	Trivy Identify vulnerabilities in images already deployed in Kubernetes or Docker environments.
	Grype Works with Syft-generated SBOMs to continuously check for new CVEs.
	OpenSCAP Provide scheduled compliance scans alongside vulnerability checks.
	VEX (Vulnerability Exploitability eXchange) + OpenVEX Helps teams prioritize remediation by filtering out non-exploitable vulnerabilities.
	Syft MFeed live SBOMs into scanners like Dependency-Track or Grype.

RV.2

Assess, Prioritize, and Remediate Vulnerabilities: Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.

To satisfy SSDF RV.2 in a post-deployment context using open-source tools, the focus shifts to:

Determining which vulnerabilities matter most in the deployed context
Using exploitability, business impact, and compliance requirements for prioritization
Executing timely remediation or mitigation actions in live environments
Tracking remediation status to closure with audit-ready records

Tasks	Tools
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.
	DefectDojo Centralizes risk scoring, workflow management, and reporting for remediation progress.
	OWASP Dependency Track Provides real-time vulnerability prioritization and integrates with issue tracking systems.
	Ortelius Enables environment-specific remediation prioritization and impact assessment.
	Jenkins + OPA (Open Policy Agent) Enforce remediation SLAs and automate rollouts of fixed versions.
	Trivy + Grype Continuous scanning plus integration with CI/CD to push patched artifacts.
	GitHub/GitLab Issues + Automation Bots Ensures no vulnerability is left without a tracked remediation action.
	Kubebench + Falco (Runtime Security) Provides real-time signals to prioritize operational security fixes.

RV.3

Analyze Vulnerabilities to Identify Their Root Causes: Help reduce the frequency of vulnerabilities in the future.

To satisfy SSDF RV.3 in a post-deployment context using open-source tools, the focus shifts to:

Determining whether it originated in coding, dependencies, build processes, or deployment configurations
Documenting lessons learned to prevent recurrence
Feeding analysis results back into security requirements, pipelines, and developer training

Tasks	Tools
RV.3.1: Analyze identified vulnerabilities to determine their root causes. RV.3.2: Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently RV.3.3: Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, and proactively fix them rather than waiting for external reports. RV.3.4: Review the SDLC process, and update it if appropriate to prevent (or reduce the likelihood of) the root cause recurring in updates to the software or in new software that is created.
	Ortelius Supports forensic analysis by tracking when and where a vulnerable component entered the system.
	DefectDojo Maintains historical data to identify trends in vulnerability origins.
	GitHub Supports forensic traceability and accountability in root cause analysis.
	Syft + Dependency Track nables version-diff SBOM analysis for root cause investigations.
	Semgrep Assists in determining whether vulnerabilities stem from code-level issues.
	OpenSCAP Enables root cause mapping to configuration weaknesses.
	Trivy + Grype Provides temporal context for root cause timelines.
	OSQuery Supports deep inspection during vulnerability forensics.

Last modified August 12, 2025