Triaging Vulnerabilities Effectively
A practical guide to reviewing scan results, assessing impact, documenting decisions, and connecting vulnerabilities to your product's risk profile.
What You'll Learn
Understanding the Vulnerability Record
Product Security Hub vulnerability records are aligned to the CycloneDX VEX (Vulnerability Exploitability eXchange) standard, ensuring interoperability and comprehensive tracking. Each record captures everything you need for triage and remediation.
Key Fields in a Vulnerability Record
💡 About CVE Sources
Vulnerability data in Product Security Hub comes from authoritative CVE sources, each with their own scoring methodology:
- Google OSV — Open Source Vulnerabilities
- NIST NVD — National Vulnerability Database
- GitHub — Security Advisories
- Ubuntu — Ubuntu Security Notices
- Red Hat — Security Advisories
- And more... — Via OSV aggregation
Setting Vulnerability Status
Every vulnerability needs a status that reflects your triage decision. Product Security Hub provides standard status options aligned with industry practices:
Open
Vulnerability is confirmed and needs to be addressed. This is the default state for newly discovered vulnerabilities.
In Progress
Remediation is underway—patch being developed, update being tested, or workaround being implemented.
Resolved
Vulnerability has been fixed through a patch, update, or removal of the affected component.
Not Affected
The vulnerability exists in the component but doesn't affect your product due to configuration, usage, or environment.
False Positive
The scan incorrectly flagged this vulnerability—component version is wrong, or the CVE doesn't apply.
Risk Accepted
Vulnerability is acknowledged but accepted due to low impact, compensating controls, or business constraints.
Documenting Your Decision
For each status change, document what you're doing about it and why. This creates an audit trail:
Connecting to Threats & Residual Risks
Vulnerabilities don't exist in isolation—they connect to your broader threat model. Product Security Hub lets you map vulnerabilities to existing threats or residual risks for complete traceability.
🔗 When to Create a Residual Risk
If a vulnerability could impact your product, you should connect it to a residual risk. This is where you evaluate the actual risk to your product, not just the generic CVE severity.
Create or link to a residual risk when:
- The vulnerability is exploitable in your product's context
- Remediation will take time and risk must be tracked
- You need stakeholder approval for risk acceptance
- The vulnerability relates to an existing threat in your model
How to Link Vulnerabilities
- 1
Open the vulnerability record — Click on any vulnerability in your Vulnerability Management page.
- 2
Look for the "Related" section — Here you can link to threats or residual risks.
- 3
Map to existing threat — If the vulnerability aligns with a threat from your threat model, link them.
- 4
Create or link residual risk — Either create a new residual risk or tie to an existing one if the vuln impacts your product.
Vulnerability Record
Contains CVE data from external sources:
- • CVE ID and description
- • Source CVSS score (read-only)
- • Affected component version
- • Your status and action items
- • Links to threats/risks
Residual Risk Record
Where you assess your product's risk:
- • Product-specific CVSS score
- • Risk justification
- • Compensating controls
- • Stakeholder approval status
- • Remediation timeline
Product-Specific CVSS Scoring
CVE authorities provide generic CVSS scores based on worst-case scenarios. Your product's actual risk may be different based on how you use the affected component.
⚠️ Important: Two Different CVSS Scores
Source CVSS (Read-Only)
The score from the CVE authority (NVD, GitHub, etc.). This is the "official" score and doesn't change in Product Security Hub.
Product CVSS (Your Assessment)
Your score based on how the vulnerability affects your specific product. Set this on the residual risk record.
When Your Score Differs from the CVE Score
It's common for your product-specific CVSS score to differ from the source. Here are valid reasons:
Lower Score Justified
- • Vulnerable code path isn't reachable in your implementation
- • Network-based attack but component is not network-exposed
- • Requires authentication that your product enforces
- • Compensating controls reduce exploitability
Higher Score Justified
- • Your product exposes the vulnerable functionality more broadly
- • Regulatory impact increases severity for your domain
- • Data sensitivity in your product amplifies impact
- • Critical infrastructure context raises stakes
Writing CVSS Justification
When your product CVSS differs from the source, you must provide justification. This is critical for audits and stakeholder communication.
Example Justification
"Source CVSS is 9.8 (Critical) based on network-accessible RCE. Our product score is 6.5 (Medium) because: (1) the affected library is only used for offline batch processing with no network exposure, (2) the vulnerable function requires admin privileges which are restricted to 3 internal users, and (3) we have network segmentation that isolates the processing server from external access."
Complete Triage Workflow
The 5-Step Triage Process
Review the vulnerability details
Understand the CVE, affected component, and source CVSS score
Determine applicability
Is this vulnerability exploitable in your product's context?
Set status and document action
Choose the appropriate status and explain what you're doing
Link to residual risk (if applicable)
Create or connect to a residual risk if the vuln impacts your product
Assess product-specific risk
Set your CVSS score on the residual risk and justify any differences
Best Practices
Do
- ✓ Triage vulnerabilities promptly after scans
- ✓ Document justifications thoroughly
- ✓ Link critical vulns to residual risks
- ✓ Re-assess when product context changes
Don't
- ✗ Ignore vulnerabilities—always document status
- ✗ Change CVSS without justification
- ✗ Mark "Not Affected" without analysis
- ✗ Forget to update status when remediated
What's Next?
Once you've triaged your vulnerabilities, continue with compliance and risk management:
- 1 Manage Residual Risks
Document risks from unresolved vulnerabilities for stakeholder visibility
- 2 Prepare for Audits
Export vulnerability and risk evidence for compliance audits
Master Vulnerability Management
Product Security Hub gives you the tools to triage vulnerabilities efficiently, connect them to your risk profile, and maintain audit-ready documentation.