Count of advisories based on the weaknesses in components can be seen in the vulnerability tab in software composition analysis dashboard.
Details
Advisories for a component are explanations about the possibility of a potential issue or in other words if a component has an advisory it means it has potential security flaws which may lead to real vulnerabilities with CVE's as the identifier. Only a known instance of vulnerability for a component will make it into a CVE.
An advisory should normally reference a CWE which is an identifier for weaknesses. For eg CWE-400 seen in the screen shot below falls in the category for uncontrolled resource consumption.
Since it is not yet a vulnerability and a since a CVE may not yet be assigned, count of advisories are not included in the OSS score calculation but can be prioritized for fixing the issue.
Open Source Software Intelligence Database (OSSIDB) in Highlight built up using automated structural code analysis makes it possible to analyze possible security weaknesses of Open Source components or Common Weakness Enumerations (CWE ) before they potentially become known as Common Vulnerabilities & Exposures (CVEs) in the National Vulnerability Database (NVD). Please refer Analyze Open Source weaknesses before they become known vulnerabilities with CAST Highlight’s OSSIDB
Essentially CWEs, or Common Weakness Enumerations, are standardized identifiers used to categorize software weaknesses. In CAST Highlight, CWEs represent potential security flaws found in open-source components, which may later develop into confirmed vulnerabilities but do not yet have a CVE assignment. Essentially, a CWE refers to a type of weakness or flaw, while a CVE indicates a confirmed vulnerability.
CVE stands for Common Vulnerabilities and Exposures. It is a system used to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. In this context, CVEs represent known and confirmed vulnerabilities, whereas CWEs refer to underlying weaknesses that may potentially develop into CVEs in the future.
On the other hand
Common Platform Enumeration (CPE) is a structured formal name format, for checking names against a system. CPE identifiers are commonly used to search for Common Vulnerabilities & Exposures (CVEs) that affect the identified product. The CPE Product Dictionary provides an agreed upon list of official CPE names.
CPE is thus a standardized name for a product that vulnerabilities can be attached to.
Example: cpe:2.3:a:apache:tomcat:9.0.0:*:*:*:*:*:*:*
This means:
a → application
apache → vendor
tomcat → product
9.0.0 → version
CVE databases (like NVD) don’t say “this affects tomcat-embed-websocket.jar”
They say “this affects Apache Tomcat” — via CPEs.
Known Exploited Vulnerabilities (KEV) are vulnerabilities that cybercriminals have already exploited. The KEV Catalog is maintained by CISA. CAST’s KEV integration tags a CVE as KEV if it appears in CISA’s KEV database, indicating it has been exploited and cataloged.
In summary an advisory signals a possible issue, a CWE defines the weakness type, and a CVE confirms a known vulnerability. CPEs help match products to vulnerabilities, and KEV highlights CVEs that are known to have been exploited.
NB:
Advisories from Gitlab start with GMS as the prefix, while advisories from Github start with GHSA.
Related Articles
Software Composition in Highlight: How Open Source component detection works
CAST HIGHLIGHT - SCA - How to verify if any file is open-source and has SCA results
CAST HIGHLIGHT - Results - SCA - How Highlight Identifies Vulnerabilities using CVE and CPE
CAST Highlight - SCA - How to Know Which CPE Was Assigned to Components?
CAST HIGHLIGHT - SCA - CVE's fewer than expected
Additional Resources
CAST Highlight Troubleshooting Guides
CAST Highlight Product Documentation
Ticket
38645, 56586, 56991
Comments