In a software supply chain attack, a bad actor makes a malicious modification to a software component in the supply chain. This later affects any other software that uses the malicious component as a dependency.
The attack's main strength is its natural amplification. It requires only one attack, maliciously altering one piece of software. The distribution of the malicious software can then affect thousands of organizations that use it. This distribution often occurs through software updates, ultimately giving the attacker access to protected networks, user accounts, or sensitive information.
Recent years have seen several high-impact attacks, including SolarWinds, Kaseya, and Codecov.
These high-profile attacks, together with many organizations' increased dependency on digital technology and the increased use of open-source software (OSS), have added to the recent focus on software supply chain attacks. Here are some factors to consider when creating your security strategy for OSS.
Software supply chain attacks and open-source software
OSS provides a number of entry points for attacks, and we are still in early stages of understanding and leveraging the true power of OSS. For OSS, any dependency is an attack target, with the software using that dependency being the real target of an attack.
Looking at the open-source ecosystem, we can see several possibilities to compromise the software dependencies in the supply chain. There are also often multiple diverse maintainers, making the trust boundary more dynamic than with proprietary code.
The many-to-many relationship between suppliers and customers adds fuel to the flames. The median number of transitive dependencies for JavaScript projects is around 700, according to GitHub. So dependencies are used by many projects and projects use many dependencies.
The source code management platform
Code is managed through a source code management (SCM) platform in the open-source ecosystem, with GitHub being the most common. Maintainers have direct write access to the code and the repository. Other contributors can fork the repository and open pull requests to get bug fixes and new features accepted.
Thus, maintainers can immediately and maliciously manipulate the code. Although maintainers are within the trust boundary, there are two simple attack vectors that would allow non-maintainers to become maintainers:
- The credentials for a maintainer can either be accidentally leaked or guessed if the password is not well chosen.
- An attacker can ask to help out by becoming a maintainer. Such social engineering was the case in the well-known attack on the event-stream package from npm.
In case it is not possible to get direct write access to the repository, a simple pull request with malicious code disguised as a bug fix would be another possibility. This was demonstrated in the infamous research made at the University of Minnesota, in which vulnerable code was contributed to the Linux kernel.
The distribution platform
Though the code is on the SCM, the actual distribution of the components is most often done through a distribution platform, such as npm or Maven central. This is very convenient since the dependencies and versions can be automatically downloaded and managed with a corresponding package manager.
Since it hosts the software, the distribution platform is another target for injecting malicious code. Here, compromised accounts are a very common attack vector, since they will allow the direct publishing of vulnerable dependencies.
Leaked and guessed passwords have been used to (responsibly) disclose 14% of the npm packages. A reused, compromised password was used in an attack on the eslint-scope and eslint-config-eslint packages. Another attack that allegedly used a compromised account was the one against the popular UAParser.js package on npm. A similar attack was also mounted on the bootstrap-sass gem, distributed on RubyGems.
More attack possibilities
In addition to the account compromises seen on the SCM and the distribution platforms, there are several other ways to inject malicious code into a software project. Here are some examples:
- Hijacking the communication channel: Unless a secure connection is used when downloading dependencies from the distribution platform, benign packets can be replaced by malicious ones.
- Dependency confusion: If the package manager is not properly configured, malicious public packages with the same name as local packages could take precedence when building the software.
- Typosquatting: Bad actors create malicious packages with names that are very similar to other packages. The hope is that developers will use the malicious one instead, maybe due to a typo. Examples of this include those on PyPI and on npm.
Tools that can help
There is no one-stop shop for handling the supply chain attack threat. Better protection of account credentials would surely reduce the number of attacks. But what can we do as consumers of OSS? Often, we do not know much about our suppliers, but we rely heavily on their software and security.
Software composition analysis
A good starting point is to better understand your software and its dependencies and to encourage better and more secure software development practices.
This is, in a nutshell, what software composition analysis (SCA) is all about. It can analyze the components and, through metrics, quantify their performance across a number of dimensions. Examples could include security, of course, but also its popularity and properties of the developer community upgrading the software. The rationale here is that "good" software is more likely to have developers following best practices.
SCA will not directly protect against the attacks, but it is an important piece of the puzzle. A software project can have thousands of direct and indirect dependencies. It is not feasible to keep track of them all, but all are potential targets of a supply chain attack.
Automatic patching
SCA helps to patch software with security vulnerabilities, including malicious code, automatically. This allows the vulnerable component to be patched immediately. If a component with malicious code has been downloaded, the component can be replaced even before the malicious version reaches the production environment.
Software bill of materials
Knowing who you trust is fundamental, and enumerating all software components in a software bill of materials (SBOM) is a basic SCA functionality. The recent executive order from President Joe Biden explicitly requires that a purchaser should be provided with an SBOM. Also, the US Food and Drug Administration has set out to require SBOMs when shipping medical devices.
Such requirements will provide more information about the software throughout the supply chain. The vendor is also incentivized to use better and more secure components, since they can be judged by their choices.
Other remediation approaches
Following the recent attention given to software supply chain attacks and their high impact, the Cybersecurity & Infrastructure Security Agency and the National Institute of Standards and Technology have released guidelines for defending against these types of cyber attacks. For the consumer, the guidelines include requiring SBOMs and making sure that the supplier follows best practices.
In addition, the guidelines recommend a better understanding of the developed application—for example, understanding which data is critical and how this data is communicated. This will help harden the application so that attacks have less impact.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
