Along with properly managing OSS component versioning, proper OSS governance requires vigilance around use of older versions of components. Failure to do so leads to an accumulation of security vulnerabilities. Out of a fast-forward scan of an application, CAST Highlight identification of potential security vulnerabilities…
This is the second in a two-part series on a software intelligence strategy for open-source software. To read part one, click here.
Along with properly managing OSS component versioning, proper OSS governance requires vigilance around use of older versions of components. Failure to do so leads to an accumulation of security vulnerabilities. Out of a fast-forward scan of an application, CAST Highlight identification of potential security vulnerabilities is twofold:
Common Vulnerabilities and Exposures (CVEs)
Leveraging the NVD database from NIST, consisting of more than 130,000 CVEs, CAST helps identify common vulnerabilities and exposures in codebases with quick and easy static scans of a copy of the codebase. Such risks can be referred to as a code breach that “when exploited, results in a negative impact to confidentiality, integrity, or availability.” Mitigation of the vulnerabilities in this context typically involves coding changes but could also include specification changes or even specification deprecations.
Directly reporting the same scoring system in its UI, CAST Highlight gets the level of criticality of the CVEs which can prove useful in large codebases to identify redundance and propagation of CVEs among a portfolio. Users typically first run an analysis of their application to establish a CVE baseline and prioritize risk mitigation actions. Also, it is not a static report, meaning the Software Composition Analysis results present in the dashboards are also updated daily. Without having to rescan the applications, notifications will get sent if a new CVE is disclosed and detected in one of the OSS components embedded in the analyzed applications. That contributes to building responsiveness against the detection of a potential OSS breach, from its detection to remediation. A plethora of actions could then be implemented like a component upgrade or replacement, if applicable.
Nonetheless, even with automated email notifications, when a new CVE is released, the MITRE process to request and reference a new CVE in the industry is quite tedious. It requires a clear identification of independently fixable issues, affecting one codebase at a time, and the acknowledgement by the vendor with additional documentation. Hence, this is quite a complex process that can take up to several days or even weeks to reference a new CVE. This elapsed timeline is massively exploited by attackers and should then be counterbalanced. For that reason, CAST Highlight leverages additional vulnerability sources.
Common Weakness Enumerations (CWEs) are a community-developed list of common software and hardware weakness types that have security ramifications. Common examples include cross-site scripting, buffer overflows, hard-coded passwords, directory tree/path traversal errors, and more. By leveraging the widest possible group of interests and talents, the CWE elements, specific effects, behaviors, exploit mechanisms, and implementation details are broadly covered. CAST Highlight is also using the Gitlab Advisory Database (open source edition): GitLab researches, finds and publishes this database independently from the NVD. These findings are not deemed classified as official vulnerabilities and therefore are not used in the CAST Highlight Open-Source Safety Score calculation. However, it commits to maintaining a rapidly updated corpus of vulnerability information that their own scanners and customers can reference. Often, the vulnerabilities categorized as CWEs end up being referenced by the NVD and hence become CVEs. According to CAST, up to 67% of the current CVEs are also CWEs.
Rationalize component catalogue adoption and obsolescence
Managing the component obsolescence plays a big role in OSS risk management. As projects are evolving and expanding, components’ features often mature from version to version, offering new perspective and a high-rate flexibility for the teams using them. Sticking to the most recent versions is a great endeavor to avoid the accumulation of exposures. New vulnerabilities are discovered almost daily, and it is often likely that some of them impact older component versions. Continuous use of them then brings to light avenues for potential attackers to exploit. Hence it is up to the application owners to find the right balance between using outdated and exposed versions of components and adapting the system to the safest and most recent updates. Similarly, it is important to consider crosschecking the component or one of its versions with its business context and lifecycle.
Once done in CAST Highlight, portfolio managers can create a list of accepted/denied versions of OSS components to enforce a governance policy across the portfolio. They can search for any component name in the database and select the versions they judge acceptable from security, licensing, and obsolescence standpoints. Ultimately, this list of accepted/denied components can be viewed directly on the supported OSS forge web sites by developers (npmjs, maven, nuget, github, gitlab, packagist). This helps shift left the SDLC process by building up awareness about the choice of any OSS component.
Finally, selection can also be based on the component’s license profiles, whether an organization wants to proactively avoid any IP liabilities by rapidly identifying permissive licenses from the restrictive ones, such as AGPL – Affero GPL, GPL – GNU General Public License, LGPL – Lesser General Public License and many others. This detection renders decision making easier, but it’s not designed to replace the advice of an IP lawyer when recommended.
SHARE