CVEs get a lot of attention, but they are at the tip of a pyramid when it comes to vulnerability management. This article contextualizes CVE findings to show teams how to build a solid foundation for effective vulnerability management.
Most organizations struggle with an overwhelming number of "critical" and "high" severity findings, making it difficult to prioritize remediation efforts effectively. By building a solid foundation that contextualize and triage CVE findings, teams can dramatically improve security outcomes.
Step 1: Knowing Where to Look - Properly Tracking Inventory Components
Before you can manage vulnerabilities, you need to know what assets you're protecting. Teams can track their dependencies and assets by using a combination of purl (Package URL) and Common Platform Enumeration (CPE).
A purl is a standardized identifier format used to uniquely identify software packages and components across different ecosystems and package managers. Purls follow a structured format like:
pkg:type/namespace/name@version?qualifiers#subpath
where:
- type specifies the package ecosystem (npm, maven, pypi, docker, etc.)
- namespace is the package namespace/organization
- name is the package name
- version is the specific version
Purls enable you to track your dependencies, and the vulnerabilities they contain, across your entire supply chain.
A CPE covers broader IT assets including operating systems, hardware, applications, and software packages. CPE identifiers use a structured format like:
cpe:2.3:a:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other
How CPE and Purl Intersect
Use purl for modern application dependency tracking and CPE for comprehensive infrastructure asset management. Purl handles the "developed" components and CPE covers the "deployed" infrastructure.
A typical cloud application might have:
- Application layer: Node.js packages, Python libraries → purl
- Runtime layer: Apache, Nginx, PostgreSQL → CPE
- OS layer: Ubuntu 22.04, Alpine Linux → CPE
- Infrastructure layer: AWS ALB, Kubernetes → CPE
This dual approach ensures comprehensive coverage across your technology stack.
How This Works in Practice
SBOM Generation Tools like Syft automatically extract purl identifiers from package manifests (package.json, requirements.txt, pom.xml) and container images. Asset management platforms like Lansweeper, Device42, and cloud-native solutions like AWS Config or Azure Resource Graph generate CPE identifiers for infrastructure components, often leveraging network discovery tools like nmap or masscan for the underlying service detection.
Modern vulnerability scanners consume both identifier types. Build-time tools like Grype, Snyk and Dependabot focus heavily on purl-identified dependencies, while enterprise scanners like Qualys VMDR and Rapid7 InsightVM use CPE data for broader infrastructure coverage. The key integration point is ensuring your asset inventory feeds both identifier types into your vulnerability management platform.
Step 2: Knowing What to Fix - Vulnerability Findings
Once you have comprehensive asset visibility, you need to understand what vulnerabilities actually mean. This requires familiarity with two key classification systems.
Common Vulnerabilities and Exposures (CVE) represents the actual vulnerability. Each CVE entry represents a specific vulnerability discovered in real-world software or hardware, assigned a unique identifier like CVE-2021-44228 (the infamous Log4j vulnerability). When a security researcher discovers a vulnerability, it receives a CVE identifier that allows everyone in the security community to reference that exact vulnerability unambiguously.
Common Weakness Enumeration (CWE) is a catalog that classifies the types of software weaknesses that can lead to vulnerabilities. Rather than identifying specific instances, CWE focuses on fundamental flaws in software design, implementation, or configuration. For instance, CVE-2021-44228 (Log4j) references CWE-502 (Deserialization of Untrusted Data) and CWE-400 (Uncontrolled Resource Consumption), helping security professionals understand not just that Log4j has a vulnerability, but what type of weakness enables the attack and how similar problems might be prevented in the future.
This CWE classification enables more sophisticated vulnerability management strategies by allowing teams to identify patterns across their vulnerability landscape, focus secure development training on the most common weakness types in their environment, and build detection rules that catch entire classes of vulnerabilities rather than individual CVEs.
Organizations can use CVE data for immediate patching decisions while leveraging CWE classifications to identify patterns in their vulnerabilities and improve their secure development practices.
How This Works in Practice
Vulnerability Scanners like Nessus, OpenVAS, and cloud-native tools automatically match your asset inventory (identified via purl/CPE) against vulnerability databases to surface relevant CVEs. The National Vulnerability Database (NVD) serves as the central CVE repository, while tools like CVE Details and security intelligence platforms provide API access for automated integration.
Most vulnerability management platforms consume NVD feeds and cross-reference CWE data to provide context-rich vulnerability reports. This integration allows security teams to move beyond simple vulnerability counts to understand the root causes driving their risk exposure.
Step 3: Knowing When to Fix - CVSS, VEX and Vulnrichment
Raw vulnerability data, even when properly classified, still overwhelms most security teams. Effective prioritization requires additional context about severity, applicability, and real-world threat activity.
Common Vulnerability Scoring System (CVSS) is a standardized framework for rating the severity of security vulnerabilities, providing a numerical score from 0.0 to 10.0 (with 10.0 being the most severe). However, CVSS scores should be considered alongside business context and threat intelligence rather than used as the sole determinant of remediation priority.
VEX is a standardized data format to communicate the exploitability status of vulnerabilities in specific products or systems. VEX documents allow software vendors, system integrators, and security teams to provide authoritative statements about whether a CVE actually affects their particular implementation. VEX answers "yes, this CVE applies to our product" or "no, this CVE doesn't affect our product because of how we implemented it, configured it, or because the vulnerable code path isn't reachable."
Vulnrichment adds critical contextual information to CVE entries, focusing on whether vulnerabilities are known to be exploited in the wild. This allows organizations to prioritize based on actual likelihood of exploitability rather than theoretical risk alone.
How This Works in Practice
CVSS Integration happens automatically in most vulnerability scanners. Tools like Nessus, Rapid7, and Qualys pull CVSS scores from the NVD and display them alongside scan results. VEX Documents are increasingly supported by software vendors (Microsoft, Red Hat, Google) who publish VEX statements alongside security advisories, and tools like Grype and Trivy can consume VEX data to filter false positives from container scans.
CISA's Vulnrichment data is available through the NVD API and is integrated into enterprise security platforms. Leading vulnerability management platforms now highlight CISA's "Known Exploited Vulnerabilities" catalog, automatically flagging CVEs with evidence of active exploitation for immediate attention.
Putting It All Together
Vulnerability management teams can track software, hardware and firmware components with purl and CPE, identify relevant CVEs within that scope, and then layer on contextual intelligence to make informed remediation decisions.
Building Your Integrated Workflow
- Start with Asset Discovery: Deploy tools that generate both purl (for dependencies) and CPE (for infrastructure) identifiers. Consolidate this inventory in a centralized asset management system.
- Layer in Vulnerability Detection: Configure scanners to consume your asset inventory and automatically correlate against CVE databases. Ensure your tools can ingest VEX documents from your software vendors and leverage CISA's vulnrichment data.
- Implement Risk-Based Prioritization: Rather than relying solely on CVSS scores, create workflows that elevate vulnerabilities with active exploitation evidence (vulnrichment) while deprioritizing those with VEX attestations showing non-applicability to your environment.
- Consolidate Reporting: Centrally track contextualized findings and provide near-real-time reporting on overall vulnerability remediation status across your entire technology stack.
The result is a vulnerability management program that moves beyond simple CVE counting toward risk-informed decision making that reflects your actual threat exposure. Adopting this approach leads to process efficiencies and increased trust with stakeholders.