- Open Source Software is an established part of modern application development
- Supply Chain Security presents challenges which Application Security Testing must address
- Solutions include new techniques which go beyond generating Software Bills of Materials
Open Source Software is Everywhere
Developers are embracing the use of Open Source Software (OSS), incorporating it into applications to perform useful tasks that are common across many applications, such as managing connections to data stores or parsing user agent information in a request, so developers can focus on proprietary code. In an ESG survey, only 4% of respondents indicated that no OSS is used within their organization.
Attackers have also taken notice of the popularity of OSS. When new vulnerabilities are disclosed, attackers are quick to take advantage, leading to attacks like Heartbleed and Log4Shell. The more popular the package, the greater the opportunity for attackers.
It is a huge challenge for developers to keep track of which applications leverage which packages and their versions, while also cross-referencing with the latest threat intelligence. When Log4Shell first entered the news, the first question many organizations faced was, “Are we using Log4j, and if so, where and what version?”. In fact, in the same survey quoted above, ESG found that less than 48% of respondents indicated that their organization has security controls for OSS.
Application Security Must Evolve
Software Composition Analysis (SCA) was created to track the OSS packages used by an organization with a Software Bill of Materials (SBOM) for each application being a standardized output. More advanced SCA solutions also leverage code analysis to prioritize vulnerabilities based on the context in which the vulnerability lies. However, with increased attention from attackers on OSS, software supply chains have also become a target, leading to a different set of challenges which SCA solutions must address.
Traditional SCA identifies the packages an organization uses, and flags which ones have known vulnerabilities based on threat intelligence information. Typically, vulnerabilities are coding errors which attackers take advantage of – they are honest mistakes which can be made by developers working on closed source code just as easily as open source. Contrast that with supply chain attacks where attackers attempt to inject outright malicious code into packages which organizations may inadvertently include in applications.
New Techniques for New Threats
Open source ecosystems are vast, and by their very nature, built to enhance collaboration. This is a great strength of open source and has led to it being the foundation of much of modern computing, including server operating systems, hypervisors, containers, cloud platforms, and everything in between. Attackers continuously attempt to take advantage of OSS flaws and functionality, plus weaknesses in the supply chain itself to insert malicious code. The reason for this is simple. Infecting the OSS supply chain can tremendously increase attackers’ success rates.
To hunt these threats in open source software supply chains, new techniques must look at the health and wellness of open source projects, the reputation of contributors, anomalous activity such as sudden changes in package publishing routines, as well as performing static and dynamic analysis of package behavior. Performing, consolidating, and analyzing all of this (and more) information beyond the expertise of the vast majority of organizations.
In conclusion, Application Security Tools, specifically Software Composition Analysis, must incorporate new techniques to meet modern security challenges in the use of open source software.
Read the full ESG Showcase, “Comprehensive Open Source Supply Chain Security: Going Beyond SCA and SBOMs”
Dive into Checkmarx SCA and get a free demo.
Learn more about Software Supply Chain Security