Analyze Open Source weaknesses before they become known vulnerabilities with CAST Highlight’s OSSIDB

While it is important to ensure that your application is not exposed to known vulnerabilities from the National Vulnerability Database (NVD), a hacker could exploit software weaknesses that are not referenced yet in the NVD. CAST Highlight now identifies these security flaws on popular Open Source components as a result of CAST’s unique understanding of software structural quality. This article explains how it works and describes how to use this capability for making more informed decisions about Open Source risk.

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 Application Intelligence Platform (AIP) 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.

In CAST Highlight, the CWE information from OSSIDB is available at both the portfolio and application levels:


  • 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.