Over the past several years, you’ve probably heard more than you ever wanted or expected to hear about supply chain attacks. Sonatype’s 2021 State of the Software Supply Chain report found a 650% year-over-year increase in attacks targeting open-source software that year, and the trend has continued since: Sonatype’s later reports have tracked hundreds of thousands of malicious open-source packages identified cumulatively since 2019. The software development environments studied consistently showed low baseline security, with configuration errors present across virtually every organization analyzed.
The state of software supply chain attacks, in short: attacks increasingly target the build pipeline and dependency chain rather than the shipped application directly, from SolarWinds (2020) compromising a build process, to the XZ Utils backdoor (2024) embedded by a long-term contributor to a widely used compression library, to 3CX (2023) repeating the SolarWinds pattern. Code signing addresses the trust-verification half of this problem; it doesn’t replace pre-signing vulnerability scanning or build integrity controls.
Key Takeaways
- The XZ Utils incident (March 2024) is the most sophisticated supply chain attack disclosed to date: a contributor spent roughly two years building trust in the project before inserting a backdoor into a compression library used by SSH across major Linux distributions. It was caught before wide distribution, by a developer noticing an unexplained performance regression, not by any automated control.
- This page tracks the incident landscape and trends. For the full threat model, containment, revocation, and recovery playbook for an active compromise, see Strengthen Code Signing Security Against Integrity Bypasses.
What is a Software Supply Chain Attack?
When nefarious hackers penetrate third-party software dependencies utilized in numerous “downstream” applications, it results in a software supply chain attack. The common element is open-source software, frequently an automatically trusted source of code utilized by internal system developers. Attackers may potentially steal sensitive information from, disrupt services for, or breach networks at hundreds or even thousands of businesses by infiltrating a single open-source program or library.
Damage dealt
More recent research sheds light on the tendency that three out of five companies were subject to software supply chain attacks. A 2021 industry survey found only 38% of businesses claimed to be unaffected by this attack type that year. Not every attack is the same; some are big, while others are swiftly in the rearview mirror. Some of the High-profile Software attacks which took the internet off the storms were:
-
Solarwinds (Dec 2020)
Threat actors used the Orion software as a weapon to access several government networks and thousands of private systems worldwide, making the SolarWinds supply chain attack a worldwide hack. The US departments of health, treasury, and state were noteworthy victims of this attack.
-
Codecov (April 2021)
Attackers were able to insert a backdoor into Codecov to gain access to sensitive client data, which led to a recent large breach. Very skilled attackers used a flaw in how Codecov created Docker images to carry out this intrusion. They utilized this to alter a script that let them launch several attacks from a remote server using the environment variables from the CI of Codecov users.
-
Microsoft’s Winget (May 2021)
WinGet’s software registry was inundated with pull requests for applications that were either duplicates or misbehaved the weekend after launch. It was inundated with faulty or duplicate packets, which overwrote the already present ones.
-
Kaseya (July 2021)
Numerous managed security providers’ remote monitoring and management software platforms contained a zero-day vulnerability that a ransomware organization found and exploited. This incident encrypted the files of over 1,500 businesses.
-
Log4j Vulnerability (Dec 2021)
The flaw enables attackers to obtain remote access to Log4j-using apps. The vulnerability is in the communication mechanism, allowing an attacker to insert malicious code into the logs and have it run on the system.
-
3CX (March 2023)
Attackers compromised 3CX’s build environment and used a legitimate code signing certificate to sign a trojanized version of its desktop softphone application, closely repeating the SolarWinds pattern: the certificate was valid and the code was legitimately signed, the build itself had been compromised before signing.
-
XZ Utils Backdoor (March 2024)
A contributor who had spent roughly two years building maintainer trust in the widely used XZ compression library inserted a backdoor targeting SSH authentication on major Linux distributions. It was discovered by a Microsoft engineer investigating an unexplained SSH performance regression, before the backdoored version reached most stable distributions, making it one of the closest calls in recent supply chain history.
And many more on the list.
Top Attack vectors
Many distinct attack vectors are utilized to compromise a software provider and successfully attack through the development pipeline. Attackers mainly concentrated their attacks on these points:
-
Exploiting Open-Source applications flaws
Most commercial software has open-source code. Two areas are the focus of vulnerable application supply chain assaults:
- One is exploiting flaws in previously extensively installed and disseminated programs. E.g., Log4j vulnerability.
- Including malicious code in well-known private and open-source packages to get automated pipeline tools to include them in the application build process. E.g., us-parser-js package poisoning.
-
Compromised Pipeline tools and altered the build process
The second attack method is the compromise of pipeline tools, which enables attackers to alter or introduce malicious code. The source code of an application, which serves as its blueprint as well as the development infrastructure and procedures, can be made public by a compromised CI/CD pipeline.
At the same time, the program is being built (as was the case of SolarWinds). Additionally, the pipeline is coupled with dozens of external dependencies that can be utilized to access and launch attacks, like the Codecov attack.
-
Manipulating the Code of Integrity
Sensitive data in code, poor code quality, and security vulnerabilities were frequently observed in the environments of many of the customers. The submission of flawed code to source code repositories has been recognized as the third risk factor. This influences the security posture and artifact quality.
How can Codesigning help?
Code signing is a process to confirm the authenticity and originality of digital information, such as a piece of software code. It assures users that this digital information is valid and establishes the author’s legitimacy.
Code signing also ensures that this digital information has not changed or been revoked after it was validly signed. Code signing can assure double authentication, thwart attacks, and even avoid namespace conflicts as you share source code throughout the SDLC.
Best Practices
Here are a few code-signing best practices to guarantee the security of your application code.
-
Securing all the private keys
The loss, theft, or compromise of a code-signing private key poses a serious security risk. There are some simple rules we can follow to avoid the risk:
- Restricting unauthorized access to the keys.
- Implementing physical security control over the keys to limit the process.
- Securing keys with cryptographic hardware items.
-
Automating the signing process by Pipelines
An end-to-end centralized approach to code signing procedures while enforcing security regulations is part of the automated code signing process. Without slowing down the SDLC, this automation approach connects with CI/CD pipelines and uses granular access control.
- Describe the roles, responsibilities, and procedures for approval.
- Integrating with existing environments and tools can make code signing quick and simple for the internal teams.
- Using time stamps to record all codesigning activities.
Frequently Asked Questions
Was the XZ Utils backdoor caught because of code signing?
No. It was caught because a developer noticed an unexplained SSH performance regression during unrelated investigation. Code signing wasn’t the control that stopped it, which illustrates why signing alone, without pre-signing scanning and build scrutiny, doesn’t catch a sophisticated, patiently-built insider compromise.
What do SolarWinds, 3CX, and XZ Utils have in common?
All three targeted the build or contribution process rather than attacking the shipped application directly. In SolarWinds and 3CX, a legitimate signing process signed already-compromised code; in XZ Utils, a trusted contributor inserted the backdoor directly into the source.
Does code signing alone prevent software supply chain attacks?
No. It verifies origin and integrity from the point of signing forward. It doesn’t detect malicious code inserted before signing, which is why pre-signing vulnerability scanning, build isolation, and code review remain necessary alongside it.
Conclusion
Your software supply chain is intricate, extensive, and interrelated, making it vulnerable to attacks. There have been a few devastating and small attacks in the past, and the future could be much better. Attackers have been using different attack vectors to target a specific side. The application of code signing is a crucial security-hardening technique.
Code signing ensures no tampering from unapproved parties and that the final published software is from the original publisher. By following certain code signing best practices, we can ensure that the Supply Chain attacks no longer threaten us.
For more information, you can contact us [email protected]
