A lot of developers are focused on CVEs, as we need to know does the library, language or other building block I use to create a solution have an identified vulnerability that needs mitigating? We probably also pay attention to OWASP (Open Worldwide Application Security Project). But CVEs and OWASP aren’t the beginning and end of the story. This a larger ecosystem of standards involved.
CWE (Common Weakness Enumeration) is of particular interest if you get a chance to step back from fire fighting CVEs. This is interesting because, rather than addressing individually identified vulnerabilities, like the OWASP Top 10s, it looks at a classifies the vulnerabilities. When you get down the Base and Variant categories we’re into specific details. This is helpful, as classifying our CVEs against CWE can tell us the technical domains where the maximum effort can return the greatest level of mitigation/remediation of CVEs (be that creating a patch or defining a mitigation strategy).
I was going to sketch out the relationships between the key standards, but realized an LLM can do a better job, so here is a visual summary:
With so many TLAs in the diagram, here is a quick reference pulled together (including from my own library of handy links).
| Acronym / reference | Expanded form | Official HTTP link | One-sentence summary | Authority / allocation relevance |
|---|---|---|---|---|
| CVE | Common Vulnerabilities and Exposures | cve.org/about/overview | CVE provides globally recognised identifiers and records for publicly disclosed cybersecurity vulnerabilities. (cve.org) | CVE IDs are assigned by authorised CNAs or by MITRE/CVE Program structures. |
| CNA | CVE Numbering Authority | cve.org/partnerinformation/listofpartners | CNAs are authorised organisations that assign CVE IDs and publish CVE Records within an agreed scope. (cve.org) | Primary delegated authorities for allocating CVE IDs. |
| CNA-LR | CNA of Last Resort | cve.org/ProgramOrganization/Structure | A CNA-LR supports CVE assignment when no more specific CNA is available for a vulnerability. (cve.org) | Fallback route for CVE ID allocation. |
| MITRE | The MITRE Corporation | mitre.org/focus-areas/cybersecurity/capabilities-resources | MITRE is closely associated with CVE, CWE, CAPEC and ATT&CK as a maintainer, operator or steward of major cybersecurity knowledge bases. (MITRE) | Current CVE Program Secretariat and maintainer of CWE/CAPEC resources. |
| CWE | Common Weakness Enumeration | cwe.mitre.org | CWE is a community-developed catalogue of software and hardware weakness types that can lead to vulnerabilities. (Common Weakness Enumeration) | CWE IDs are maintained by MITRE; they classify weakness types, not individual vulnerabilities. |
| CWSS | Common Weakness Scoring System | cwe.mitre.org/cwss | CWSS is a CWE-related scoring method for prioritising software weaknesses, but the older version referenced by MITRE is marked obsolete. (Common Weakness Enumeration) | Scores weaknesses, not CVE vulnerabilities; largely secondary compared with CVSS in current vulnerability workflows. |
| CVSS v4.0 | Common Vulnerability Scoring System version 4.0 | first.org/cvss/v4.0 | CVSS v4.0 is the current major CVSS standard family used to express vulnerability severity with base, threat, environmental and supplemental metrics. (FIRST Forum) (Forum of Incident Response and Security Teams) | Maintained by FIRST; it scores vulnerabilities but does not allocate vulnerability IDs. Defines the scoring structure/ranking scale, not ID allocation. |
| NIST | National Institute of Standards and Technology | nist.gov | NIST hosts and maintains important security automation resources including NVD and CPE-related specifications. (NVD) | Maintains NVD and official CPE dictionary infrastructure. |
| NVD | National Vulnerability Database | nvd.nist.gov | NVD enriches CVE records with structured metadata such as affected platforms, weakness classifications, references and severity scores. | Enrichment database, not the allocator of CVE IDs. |
| CPE | Common Platform Enumeration | nvd.nist.gov/Products/CPE | CPE provides standardised names for identifying affected products, platforms and software configurations. (NVD) | Supports product/platform matching in NVD and vulnerability scanners. |
| CAPEC | Common Attack Pattern Enumeration and Classification | capec.mitre.org | CAPEC is a MITRE-maintained catalogue of attack patterns used to understand how weaknesses may be exploited. (CAPEC) | CAPEC entries relate to CWEs and help connect weaknesses to attack behaviour. |
| CSAF | Common Security Advisory Framework | oasis-open.org/committees/csaf | CSAF is an OASIS standard for creating and exchanging structured machine-readable security advisories. (OASIS) | Advisory exchange format that can carry CVE, product status, remediation and scoring data. |
| VEX | Vulnerability Exploitability eXchange | cisa.gov SBOM resources | VEX communicates whether a known vulnerability is exploitable in a specific product or deployment context. (CISA) | Helps qualify CVE findings so consumers can distinguish exploitable from non-exploitable exposure. |
| CISA | Cybersecurity and Infrastructure Security Agency | cisa.gov | CISA publishes operational vulnerability guidance and maintains the Known Exploited Vulnerabilities catalogue. (CISA) | Maintains KEV and participates in the wider CVE/vulnerability ecosystem. |
| KEV | Known Exploited Vulnerabilities catalogue | cisa.gov/known-exploited-vulnerabilities-catalog | KEV is CISA’s authoritative catalogue of vulnerabilities known to have been exploited in the wild. (CISA) | Prioritisation signal based on observed exploitation, not severity alone. |
| EPSS | Exploit Prediction Scoring System | first.org/epss | EPSS estimates the probability that a published CVE will be exploited in the wild within the next 30 days. (FIRST Forum) | Probability-based prioritisation signal that complements CVSS and KEV. |
| CERT/CC | CERT Coordination Center | kb.cert.org/vuls | CERT/CC coordinates vulnerability disclosure and publishes Vulnerability Notes. (CERT Coordination Center) | Can act as a coordinator in disclosure workflows and may interact with CNA/CVE processes. |
| CVD | Coordinated Vulnerability Disclosure | CERT Guide to CVD | CVD is the process of coordinating information among finders, vendors and other stakeholders before public disclosure and mitigation communication. (CERT Coordination Center) | Process framework around disclosure; not itself an ID system. |
| SBOM | Software Bill of Materials | ntia.gov/software-bill-materials | An SBOM describes the software components that make up a product so downstream users can reason about exposure and supply-chain risk. (NTIA) | Often paired with VEX and vulnerability feeds to assess affected components. |
| CycloneDX | CycloneDX Bill of Materials standard | cyclonedx.org | CycloneDX is an OWASP full-stack Bill of Materials standard for supply-chain and cyber-risk use cases. (CycloneDX) | SBOM/VEX-capable format used in vulnerability management pipelines. |
| SPDX | Software Package Data Exchange | spdx.dev | SPDX is an open standard, ISO/IEC 5962:2021, for representing SBOMs and other software supply-chain metadata. (SPDX) | SBOM format often used alongside vulnerability data sources. |
| SWID | Software Identification tag | NIST SWID guidance | SWID tags are ISO/IEC 19770-2 software identification files that can support software asset, patch and vulnerability management. (NIST Computer Security Resource Center) | Product identification standard related to CPE-style inventory matching. |
| SSVC | Stakeholder-Specific Vulnerability Categorization | CMU SEI SSVC v2.0 | SSVC uses decision trees to prioritise vulnerability response actions for specific stakeholder contexts. (SEI) | Prioritisation model that complements CVSS, KEV and EPSS. |
| MITRE ATT&CK | Adversarial Tactics, Techniques and Common Knowledge | attack.mitre.org | MITRE ATT&CK is a knowledge base of adversary tactics, techniques and procedures based on real-world observations. (MITRE ATT&CK) | Related attack-behaviour framework that can be connected to CAPEC/CWE/CVE analysis. |
| OWASP Top 10 | Open Worldwide Application Security Project Top 10 | owasp.org/Top10 | The OWASP Top 10 is a standard awareness document for developers and web application security risks. (OWASP Foundation) | Useful application-security reference that often maps conceptually to CWEs. |
| OSV | Open Source Vulnerabilities / OSV schema | osv.dev | OSV provides a machine-readable vulnerability format and database that maps open-source vulnerabilities precisely to package versions or commit hashes. (OSV) | Adjacent vulnerability-data ecosystem, especially useful for open-source dependency scanning. |
or red card out. But the bottom line is that these risks are perhaps more appreciated because it is easier to understand external entities attacking seeking direct attacks to disrupt or access information. But there are often subtler and at least more costly to repair attacks such as internal attacks and indirect attacks such as compromising software deployment mechanisms.
There are circumstances in which notifications from the Oracle API Platform CS could be seen as desirable. For example, if you wish to ensure that the developers are defining good APIs and not accidentally implementing APIs that hit the 
I’ve started to subscribe to the 
Ensuring the API has mitigation’s against the classic 
Phil (aka MP3Monster)'s Blog 
You must be logged in to post a comment.