There is generally a lot less awareness of Software Supply Chain Security in the contemporary IT landscape and thus its aspects are completely ignored by DevSecOps practices. In this two-part article, I aim to provide an overview of what software supply chain is, what attack vectors you render yourself vulnerable to when not including these aspects in your pipelines and how you can reduce your attack surface area using various tools / frameworks / guidelines like SLSA, sigstore, in-toto, SBOM, TUF, OpenSSF etc. We will also shed light on how the open source community as a whole is combating this threat.
What does software supply chain look like?
This is something that most of the readers must be already aware of, so just a short summary would suffice. A developer writes code and pushes it into a source code repository (git, svn etc.). The code is built through a pre-defined, mostly using GitOps and automated processes (Github Actions, Jenkins Pipelines, Argo CD, Tekton etc.) while requiring certain dependencies which may include some open source artifacts (numpy, pandas, spring etc.). The built artifact or package is then pushed into a Package Repo (OCI Container Registry, Artifactory etc.) where the consumer (your CD Pipeline) consumes the package and deploys it to the target system.
Attacks on the Software Supply Chain
There are multiple attacks possible throughout the Software Supply Chain:
- Submit unauthorized code / Bypass Code Review - You might say to this that it’s not possible to do at your company but don’t forget that you might be consuming open source artifacts which are vulnerable to such attacks as shown by this, where a researcher tried to intentionally introduce vulnerabilities into the Linux kernel.
- Compromise Source Control (git/svn server) / Unauthorized access - One of such recent attacks (in 2021) was on PHP’s self hosted git server where two malicious commits were injected - more information here.
- Build from modified source code - Such attacks are quite prominent where the attacker compromises the build process to use source code which is not even part of your source control. An example of this is the attack on Webmin.
- Compromise build process - Solarwinds attack, one of the most high profile cyber attacks from 2020, was performed by compromising the build platform in a way that a malicious behavior was injected during each build.
- Using a compromised dependency in the build process - This kind of attack might be already known to people who use npm, especially the event-stream package which was compromised a few years ago where an attacker added a seemingly unharmful dependency and then later updated the dependency to add malicious behavior.
- Upload Compromised Package or Bypass CI/CD - This is generally possible when credentials gets leaked which gives the attackers the opportunity to upload compromised packages which were not built by your CI pipeline. An example of such an attack recently is CodeCov.
- Compromise Package Repo - Package managers use different security mechanisms that provide varying levels of usability and resiliency to attacks. Most of these package managers have vulnerabilities that can be exploited by a man-in-the-middle or a malicious mirror as shown in this paper.
- Use Compromised Package - These are generally performed by techniques like Typosquating/Brandjacking, where the attacker creates packages with misspelled names of a popular component or spoofing it closely. Such attacks rely on developers misspelling component names which happens as often as you think it does. Malicious payloads can be executed (crypto miners, install malware, steal credentials etc.) using such techniques as most developer build tools have the privileges to execute commands.
- Compromise Open Source Artifact Server or dependencies - All of the attacks mentioned above can similarly happen outside of your CI/CD pipeline and creep through dependencies.
For further depth on attacks and what is being done to thwart them, I highly recommend reading the report on the State of the Software Supply Chain by Sonatype published in 2022. For those with limited time, here is a TL;DR and the most important pieces of information presented as quotes from the report with some details around it:
- “The overall download volume across the four major ecosystems (Java, Javascript, Python and .Net) is now projected to top 3 trillion downloads overall.” - This points towards our increasing dependence on open source artifacts, while not having much or any idea about what sort of security mechanism are in place to produce them.
- “There has been an astonishing 742% average annual increase in Software Supply Chain attacks over the past 3 years.” - This is an alarming rate of increase!
- “The most serious development in 2022 is an approaching collision of two critical issues in our industry: the continued growth of open source security concerns along with a dramatic legislative response by governments worldwide.” - The governments around the world are taking these threats very seriously. The US issued a Software Supply Chain Security Guidance Under Executive Order 14028, published a Securing Open Source Act of 2022 and a Secure Software Development Framework. The UK government unveiled its National Cyber Security Strategy 2022, specifically citing supply chain vulnerabilities as an area of concern. Germany issued the Information Security Act 2.0 (IT-SiG) and the Second Ordinance Amending the BSI Criticality Ordinance (BSI KritisV) which specifically states that suppliers, i.e. manufacturers of critical components, will also be subject to certain obligations to safeguard the entire supply chain. Similar actions are taking place in other regions around the world as well.
- “About 6 out of every 7 project vulnerabilities come from transitive dependencies.”
- “1.2 billion vulnerable dependencies are downloaded each month.”
- “We’ve hit an inflection point, and development teams must address software supply chain attacks and select better open source projects.”
What actions are being taken? (Isolated)
GitHub introduced mandatory two-factor authentication for the top 100 npm maintainers and PyPA is working to reduce dependence on setup.py, which is a key element to how these attacks can launch alongside while promoting 2FA adoption using a public dashboard. These measures are an important step in preventing maintainer hijacking of known popular packages and will encourage added trust in the integrity of the package maintainer.
Some registries such as the Maven Central Repository require mandatory organizational verification and a namespaced coordinate system to help avert attacks like Dependency confusion, a form of attack relying on spoofing internal package names and publishing them to an open source registry with an abnormally high version number.
While there are these isolated actions, they don’t solve all supply chain issues and there is certainly a need for more concerted, organized actions which the organizations, businesses and enterprises around the world need to take to be more robust in order to avert these attacks.
In part two, I’ll discuss what actions can be taken in an organized manner and what tools are available to do so. Time for a quick break now!
