How to Shut Down OSS Attack Vectors in Your Supply Chain
In a software supply chain attack, a malicious 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 main strength of the attack is its natural amplification. It only requires a single attack, maliciously altering a single piece of software. Distribution of the malware can then affect thousands of organizations that use it. This distribution often occurs through software updates, ultimately allowing the attacker to gain access to protected networks, user accounts, or sensitive information.
The past few years have seen several high-impact attacks, including SolarWinds, Kaseya, and Codecov.
These high-profile attacks, along with many organizations’ increased reliance on digital technology and increased use of open source software (OSS), have added to the recent focus on supply chain attacks. software. 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 the early stages of understanding and harnessing the true power of OSS. For OSS, any dependency is an attack target, the software using this dependency being the real target of an attack.
Looking at the open source ecosystem, we can see several possibilities for compromising software dependencies in the supply chain. There are also often several different maintainers, which makes the trust boundary more dynamic than with proprietary code.
The source code management platform
Code is managed through a source code management (SCM) platform in the open source ecosystem, GitHub being the most common. Maintainers have direct write access to the code and repository. Other contributors can fork the repository and open pull requests for bug fixes and accepted new features.
Thus, maintainers can manipulate the code immediately and maliciously. Although maintainers are within the trust boundary, there are two simple attack vectors that would allow non-maintainers to become maintainers:
If it is not possible to gain direct write access to the repository, a simple pull request with malicious code disguised as a bugfix would be another possibility. This was demonstrated in the infamous research done at the University of Minnesota, in which vulnerable code was added to the Linux kernel.
The broadcast platform
Although the code is on the SCM, the actual distribution of components is most often done through a distribution platform, such as npm or Maven central. This is very convenient because 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 the injection of malicious code. Here, compromised accounts are a very common attack vector, since they will allow vulnerable dependencies to be published directly.
Leaked and guessed passwords were used to (responsibly) leak 14% of npm packages. A reused and compromised password was used in an attack against 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 distribution platforms, there are several other ways malicious code can be injected into a software project. Here are some examples:
- Diversion of the communication channel: Unless a secure connection is used when downloading dependencies from the distribution platform, benign packages may be replaced by malicious packages.
- Dependency confusion: If the package manager is not properly configured, malicious public packages with the same name as local packages can take precedence when building software.
- Typosquatting: Malicious actors create malicious packages with very similar names to other packages. The hope is that the developers will use the malicious one instead, possibly due to a typo. Examples of this include those on PyPI and on npm.
Tools that can help
There is no single window to manage the supply chain attack threat. Better protection of account credentials would surely reduce the number of attacks. But what can we do as OSS consumers? Often we don’t know much about our vendors, but we rely heavily on their software and security.
Analysis of software composition
A good place to start is to better understand your software and its dependencies and encourage better and more secure software development practices.
This is, in a nutshell, what software composition analysis (SCA) is. It can analyze components and, through metrics, quantify their performance in a number of dimensions. Examples could include security, of course, but also its popularity and the properties of the developer community updating the software. The logic here is that “good” software is more likely to have developers following best practices.
SCA will not directly protect against attacks, but it is an important piece of the puzzle. A software project can have thousands of direct and indirect dependencies. It’s not possible to track them all, but all are potential targets of a supply chain attack.
SCA helps automatically patch software with security vulnerabilities, including malicious code. This allows the vulnerable component to be patched immediately. If a component with malicious code has been uploaded, the component can be replaced even before the malicious version reaches the production environment.
Knowing who you trust is fundamental, and listing all software components in a software bill of materials (SBOM) is a core feature of SCA. President Joe Biden’s recent executive order explicitly requires a buyer to receive an SBOM. Additionally, the United States Food and Drug Administration has decided to require SBOMs when shipping medical devices.
These requirements will provide more information about the software throughout the supply chain. The vendor is also incentivized to use better and more secure components as they can be judged by their choices.
Other remediation approaches
Following recent attention to software supply chain attacks and their high impact, the Cybersecurity & Infrastructure Security Agency and the National Institute of Standards & Technology have issued guidelines for defending against these types of attacks. cyberattacks. For the consumer, the guidelines include requiring SBOM and ensuring that the provider is following best practices.
Additionally, the guidelines recommend a better understanding of the application being developed, for example, understanding what data is critical and how that data is communicated. This will help harden the application so that attacks have less impact.