Skip to main content

Supply Chain Attacks - Threats in Software Delivery

About 2 min read

A supply chain compromise is an attack technique in which an attacker intervenes at some stage of software development, build, or distribution to inject malicious code into legitimate software. Because it abuses the trusted update path of software, it is extremely difficult to detect with traditional security measures. The 2024 xz Utils backdoor incident highlighted the fragility of open-source maintenance structures and renewed awareness of the importance of the SBOM (Software Bill of Materials).

What Verification Can and Cannot Confirm

A mechanism that records and compares a fingerprint of what was distributed answers whether what was obtained is the same as what was published. What it cannot answer is whether what was published is itself legitimate. Where a release that went through the procedures on the developer side and was published through the proper channel contains malicious code, the comparison matches. That is why this kind of attack sits poorly with conventional detection: the traces of the intrusion remain not in the environment of the user but in the upstream working environment, which the user cannot see. Next, the decision to fix a version in place has two sides as well. Fixing it means no unintended substitution occurs, but it also stops corrections from being taken in. As time passes with the version fixed, it becomes easy to end up continuing to use a release in which an already published defect remains. Neither fixing nor updating is the safe option; the choice becomes a question of where to place the effort of checking. The third point is the extent of what is covered. When parts are chosen for inclusion, what was chosen is only the set whose names were written down directly, whereas what is actually brought in is the whole that includes the parts those require. As the number grows, so does the proportion of parts whose names have never been seen. Grasping the extent is therefore not a matter of drawing up a list of what was chosen, but of counting the whole, including everything that follows on from it. For the part that is not grasped, there is also no way to know whether an update has occurred.

Supply Chain Attack Flow

Attacker breaches the build environment, repository, or maintainer
Malicious code is injected into legitimate software
The tainted version is distributed through the legitimate update channel
Users install or update it in good faith
The attacker accesses the internal network through the backdoor

Historical Background

Supply chain compromise drew global attention with the 2020 SolarWinds incident. A backdoor was planted in the build process of the IT management tool Orion, affecting more than 18,000 organizations, including U.S. government agencies. With incidents such as the 2021 Kaseya VSA attack and the 2024 xz Utils backdoor, attacks targeting supply chains are growing more sophisticated year after year. Reports of supply-chain-related vulnerabilities are also surging in the CVE database.

Defensive Measures

Creating and managing an SBOM (Software Bill of Materials) is the foundation of defense. Know which open-source libraries you use and their versions, and continuously monitor vulnerability information. Commit dependency lockfiles (package-lock.json, Gemfile.lock) to prevent unintended version changes. In the build pipeline, introduce mechanisms that detect tampering of artifacts through signature verification and hash checks. It is also important to focus on additions and changes to dependencies during code review. Protect CI/CD systems and package registry accounts with strong random passwords to prevent unauthorized access to the build process.

Related Terms

Was this article helpful?