Analyze Open Source weaknesses before they become known vulnerabilities with CAST Highlight’s OSSIDB
Why chasing CVEs is not enough?
It is often said that security is a race against time. While more mature organizations have shifted vulnerability management of their third-party components to the left, InfoSec teams now want to focus on the vulnerabilities that have not been disclosed yet and cannot be found in vulnerability repositories such as the National Vulnerability Database from MITRE.
Since most third-party components are Open Source, any hacker can easily access the source code of a recent version to exploit a new flaw that is not widely known yet. Hence the need for InfoSec teams to have the freshest information possible. What if they could predict the future?
The CAST Research team analyzed 150K+ vulnerabilities from the NVD and found that 67% of these Common Vulnerabilities & Exposures (CVEs) were actually Common Weakness Enumerations (CWEs). In other words, if one can identify the nature of a security weakness (CWE), one will be able to theoretically find 67% of the potential future known vulnerabilities (CVEs). Obviously, the level of effort required to identify all occurrences of a CWE manually on each version of an Open Source component would be enormous. That’s where CAST’s unique Software Intelligence technology comes into play to automatically analyze software weaknesses.
Now, at this point, some of you may wonder what is the difference between a CWE and a CVE. We have the perfect metaphor to apprehend these two notions:
- CWEs are suspected of a crime
- As there are different types of crime, CWEs are also categorized)
- CVEs are proven guilty and convicted of a crime (with a criminal record, eventually a prison number)
OSSIDB: a knowledge base to predict future CVEs
For the past few months, the CAST Highlight team has been leveraging the unique capabilities of CAST MRI for Software to analyze Open Source components in an automated fashion. For those not familiar, CAST AIP has the unique ability to identify the critical flaws that really matter, i.e. the hard-to-find architectural problems which lead to unpredictable stability, performance, security, and data integrity issues, including most of the CWE defects.
We automated this fine-grained security analysis on the source code of the most popular Open Source components and created this exclusive Open Source Software Intelligence Database (OSSIDB).
As of today, CWEs have been identified for 3,000+ components, which represents a total of 48,000 distinct artifacts (components and versions), these numbers increasing every day as we continue.
Below is a sample of occurring CWEs we have identified and added to the OSSIDB.
| CWE Identifier | Name |
|---|---|
| CWE-22 | Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) |
| CWE-73 | External Control of File Name or Path |
| CWE-78 | Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) |
| CWE-89 | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) |
| CWE-93 | Improper Neutralization of CRLF Sequences (‘CRLF Injection’) |
| CWE-111 | Direct Use of Unsafe JNI |
| CWE-117 | Improper Output Neutralization for Logs |
| CWE-134 | Use of Externally-Controlled Format String |
| CWE-259 | Use of Hard-coded Password |
| CWE-284 | Improper Access Control |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm |
| CWE-352 | Cross-Site Request Forgery (CSRF) |
| CWE-401 | Improper Release of Memory Before Removing Last Reference (‘Memory Leak’) |
| CWE-477 | Use of Obsolete Function |
| CWE-489 | Leftover Debug Code |
| CWE-561 | Dead Code |
| CWE-611 | Improper Restriction of XML External Entity Reference |
| CWE-614 | Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute |
| CWE-916 | Use of Password Hash With Insufficient Computational Effort |
| CWE-1050 | Excessive Platform Resource Consumption within a Loop |
How to use this data in CAST Highlight
This unique OSSIDB on Open Source components provides enterprise leaders with exclusive insights on possible future security vulnerabilities to the risk from hackers. This information can be leveraged in different ways:
- Identify components to replace: In addition to known vulnerabilities, see if a component has a high number of distinct CWEs and CWE occurrences. This indicates a higher probability that these security flaws will turn into real vulnerabilities in the future. In this case, you might consider replacing it with an equivalent but safer component. With CAST Highlight, you can estimate the impact of this component and how frequently it is used across your application portfolio. You can also add the component to your Deny list as you may not want it to be used in the future.
- Compare risks for similar components: When planning to add new capabilities to your application, you may develop a shortlist of Open Source components that have no known vulnerabilities. This CWE information can help you decide on the best options from a security risk perspective.
- Contribute to the community: When you identify a CWE for a component you are using, you can notify the component team about these possible security issues so that they can implement a fix before exploitation.
- Portfolio Level: from the Components tab of the Software Composition dashboard, a new ‘CWE’ column identifies the number of distinct weaknesses that have been triggered for a given component. Clicking on this number opens a screen that indicates the CWEs detected along with the corresponding CAST AIP quality rule and component version where these issues have been identified.
- Application Level: from the Software Composition tab of an application detail page, a new ‘CWE’ column identifies the number of distinct weaknesses that have been triggered for a given component in the version used by the application. Clicking on this number opens a screen that indicates the CWEs along with the corresponding CAST AIP quality rule.
- Component Timeline: Retrieve the CWE data from the component timeline to see how many distinct CWEs have been triggered version by version
- If you want to know more about a specific CAST AIP quality rule, simply click on the question mark icon to view the documentation with code samples and insights on how this quality rule is applied.