Software Supply Chain Attacks: Why Build Pipelines Are the New Breach Vector

Threat actors no longer need to breach your network when they can compromise the software you already trust. By targeting developer build pipelines and stealing code-signing certificates, attackers deliver malicious code that your systems accept as legitimate. For small businesses relying on third-party integrations, this creates a risk most IT teams never anticipated: the software running your business may have been weaponized before you installed it.

This post explains how software supply chain attacks work, why they’re accelerating, and what your business must do to vet vendors and monitor for compromise.

Table of Contents

1. What Are Software Supply Chain Attacks?
2. Why Build Pipelines Are the Target
3. The Role of Code-Signing Certificates in Supply Chain Attacks
4. Real-World Examples: SolarWinds, Kaseya, and Beyond
5. Who Is Affected by These Attacks?
6. Defense Posture: What Your Business Can Actually Do
7. What to Ask Your IT Firm and Software Vendors
8. Conclusion

What Are Software Supply Chain Attacks?

A software supply chain attack occurs when a threat actor compromises a trusted software vendor, developer tool, or distribution channel to inject malicious code into legitimate software updates or installations. The victim organization downloads and runs the compromised software, believing it came from a trusted source. Because the malicious code is signed and distributed through official channels, traditional security controls usually miss it.

Unlike traditional cyberattacks that target one organization, software supply chain attacks are force multipliers. One successful vendor compromise gives attackers access to hundreds or thousands of downstream customers. The attacker invests effort once and harvests access across an entire ecosystem.

The most effective vector is the developer build pipeline – the automated system that compiles source code, runs tests, packages software, and prepares it for distribution. If an attacker gains access to this pipeline, they can insert malicious code that gets compiled into every build, signed with the vendor’s certificate, and pushed to every customer.

Why Build Pipelines Are the Target

Build pipelines sit at the intersection of trust and scale. Every piece of software your business uses passed through a build pipeline. Compromising that pipeline means the attacker’s code becomes part of the official product.

Modern development practices rely on continuous integration and continuous deployment systems. These systems automatically pull code from repositories, compile it, run automated tests, and deploy updates to production or customer-facing distribution channels. They’re designed for speed and automation, which also makes them vulnerable if access controls are weak.

Threat actors target build pipelines through several methods:

• Credential theft from developers or DevOps engineers who have access to the build environment
• Exploiting vulnerabilities in the continuous integration/continuous deployment platform itself, such as Jenkins, GitLab, or Azure DevOps
• Compromising a dependency or library that the build process pulls in automatically – a technique known as dependency confusion or typosquatting
• Social engineering developers to accept malicious pull requests or code contributions that introduce backdoors
• Gaining access to the infrastructure hosting the build servers and modifying build scripts or configurations

Once inside the build pipeline, attackers inject code at any stage. The malicious code is compiled alongside legitimate code, packaged into the final product, and distributed to customers. Because the build process applies the vendor’s code-signing certificate, the resulting software appears authentic to all downstream security tools.

The Role of Code-Signing Certificates in Supply Chain Attacks

Code-signing certificates are cryptographic credentials that software vendors use to prove the authenticity and integrity of their code. When you install software, your operating system checks the digital signature to verify that the code came from the stated publisher and wasn’t modified after signing. This system relies entirely on the assumption that the vendor protects its signing certificate.

If a threat actor steals or gains access to a vendor’s code-signing certificate, they can sign malicious code that your systems will accept as legitimate. The certificate acts as a trust anchor. Your endpoint protection, application whitelisting, and operating system security all defer to that signature.

Threat actors obtain code-signing certificates through several methods:

• Breaching the vendor’s build environment where certificates are stored, often in poorly protected key stores or environment variables
• Stealing credentials from developers who have access to the signing infrastructure
• Exploiting weak key management practices, such as storing private keys in source code repositories or unencrypted file shares
• Compromising hardware security modules or cloud-based key vaults if those systems are misconfigured
• Purchasing stolen certificates on underground markets, where previously compromised credentials are resold

Once signed, malicious software is extremely difficult to detect. Even if the vendor discovers the breach and revokes the certificate, many systems don’t check certificate revocation lists in real time. The malicious software may continue to be trusted for weeks or months after the certificate is revoked.

Certificate theft also has a delayed-disclosure problem. Vendors often don’t realize their signing infrastructure was compromised until customers report suspicious behavior or a security researcher discovers the malicious code. By that time, thousands of installations may already be affected.

Real-World Examples: SolarWinds, Kaseya, and Beyond

The most well-documented software supply chain attack is the SolarWinds Orion compromise, publicly disclosed in December 2020. Threat actors, later attributed to a Russian state-sponsored group, gained access to SolarWinds’ build environment and inserted a backdoor into the Orion platform’s software updates. The malicious code was compiled into official builds, signed with SolarWinds’ certificate, and distributed to approximately 18,000 customers, including multiple U.S. federal agencies and Fortune 500 companies.

The attackers gained initial access to the build environment months before the first malicious update was distributed, giving them time to study the infrastructure, test their code, and ensure it would evade detection. The backdoor, known as SUNBURST, allowed the attackers to conduct reconnaissance, escalate privileges, and move laterally within victim networks. The breach went undetected for months and was only discovered when a security firm noticed suspicious network traffic.

According to CISA’s supply chain compromise guidance, the SolarWinds incident demonstrated how a single vendor compromise can cascade across thousands of organizations. The attackers didn’t need to breach each victim individually. They simply waited for victims to install the trusted software update.

In July 2021, the Kaseya VSA remote management platform was compromised in a similar manner. Attackers exploited vulnerabilities in the VSA software and used the platform to deploy ransomware to approximately 1,500 downstream businesses. While this attack vector was slightly different – exploiting a vulnerability rather than compromising the build pipeline – the impact model was the same: one breach, many victims, delivered through trusted software.

Other notable supply chain incidents include:

• The compromise of CCleaner in 2017, where attackers inserted a backdoor into the popular system optimization tool, affecting 2.27 million users
• The ASUS Live Update utility compromise in 2019, which delivered malicious updates to over one million users
• The Codecov breach in 2021, where attackers modified a software testing tool used by thousands of development teams, potentially exposing source code and credentials
• The 3CX VoIP software compromise in 2023, where a trojanized installer was distributed to customers for months before detection

These incidents share a common pattern: attackers invested significant time to compromise trusted software, knowing the payoff would be broad and sustained access to downstream victims.

Who Is Affected by These Attacks?

Software supply chain attacks don’t discriminate by company size. Any organization that uses third-party software is a potential victim. The impact varies depending on your security posture, the type of compromised software, and the attacker’s objectives.

Large enterprises and government agencies are often the ultimate targets, but small and mid-sized businesses are frequently collateral victims. The attackers compromise a widely used software vendor and then selectively interact with only the high-value targets within that victim pool. Smaller businesses may have the malicious code running in their environment without the attacker ever using it, but the risk remains.

Small businesses face unique challenges defending against software supply chain attacks:

• Limited visibility into vendor security practices and no leverage to demand third-party audits or security attestations
• Heavy reliance on software integrations and third-party tools to operate efficiently, creating a large attack surface
• Lack of advanced monitoring and threat detection tools that might identify anomalous behavior from trusted software
• Insufficient IT staffing to vet every software vendor, review security questionnaires, or track software bills of materials
• No incident response capability to quickly contain a breach if compromised software is discovered running in the environment

Industries that rely heavily on specialized software integrations face elevated risk. Healthcare practices using electronic health record platforms, accounting firms using tax and audit software, manufacturers using supply chain management tools, and professional services firms using client collaboration platforms all depend on software that could be compromised upstream.

Defense Posture: What Your Business Can Actually Do

Defending against software supply chain attacks requires a layered approach. No single control will prevent every attack, but a combination of vendor vetting, monitoring, and containment strategies can significantly reduce risk.

Vendor Security Assessment

Before adopting new software – especially software that will have access to sensitive data or integrate with critical systems – conduct a basic security assessment of the vendor. This doesn’t require a formal audit, but it should include questions about the vendor’s build process, key management, and incident response capability.

Ask vendors whether they follow secure software development practices, such as code reviews, automated vulnerability scanning, and separation of duties in the build pipeline. Ask whether their code-signing certificates are protected by hardware security modules and whether access to the signing infrastructure is logged and monitored.

If the vendor has undergone third-party security assessments, such as SOC 2 Type II audits or penetration testing, request a summary of findings. These assessments aren’t guarantees, but they indicate the vendor takes security seriously enough to invite external scrutiny.

Monitor Software Behavior

Even trusted software should be monitored for anomalous behavior. Endpoint detection tools, network monitoring, and application logging can identify unusual activity that may indicate a compromise.

Look for software making unexpected network connections, especially to unfamiliar IP addresses or domains. Look for unusual processes spawned by the software or unexpected file modifications. Many software supply chain attacks involve backdoors that communicate with command-and-control infrastructure or write additional payloads to disk.

If your business has a managed cybersecurity partner, ensure they’re monitoring for these indicators. The challenge with software supply chain attacks is that the malicious activity comes from a trusted process, which means traditional signature-based antivirus won’t flag it. Behavioral monitoring is essential.

Segment and Contain

Assume that any software you run could be compromised. Design your network and access controls to limit the damage if that assumption proves correct.

Don’t grant software broader access than it needs. If a vendor’s application only needs to access certain databases or file shares, restrict its access to those resources. Use network segmentation to prevent compromised software from moving laterally to other parts of your infrastructure.

Apply the principle of least privilege to service accounts and application credentials. If software runs under a highly privileged account, a compromise of that software gives the attacker the same level of access.

Maintain an Inventory

You can’t defend what you don’t know you have. Maintain an inventory of all third-party software running in your environment, including version numbers, update schedules, and the business function each application supports.

When a vendor discloses a software supply chain compromise, you need to know immediately whether you’re affected. If you don’t have an inventory, you’ll spend critical hours trying to determine what software is running and where, while the attackers are already inside your network.

Patch Management and Update Validation

Software supply chain attacks often abuse the software update process, but that doesn’t mean you should stop applying updates. Unpatched software is a far more common breach vector than compromised updates.

The key is to validate updates before deploying them widely. For critical systems, test updates in a non-production environment first. Monitor vendor security advisories and customer forums for reports of unexpected behavior after updates.

If a vendor releases an emergency patch outside their normal update cycle, treat it with extra scrutiny. Out-of-band updates can be legitimate responses to critical vulnerabilities, but they can also be indicators that something is wrong.

What to Ask Your IT Firm and Software Vendors

If your business works with a managed IT provider or relies on third-party software, you should be asking specific questions about supply chain security. These questions help you understand whether your vendors are taking the threat seriously and whether they have the controls in place to detect and respond to a compromise.

Questions for Your IT Provider

• Do you maintain an inventory of all third-party software running in our environment, including version numbers and update schedules?
• How do you monitor for anomalous behavior from trusted applications?
• What’s your process for vetting new software vendors before we adopt their tools?
• If a vendor discloses a supply chain compromise, how quickly will you know whether we’re affected, and what’s the response process?
• Are our systems segmented in a way that limits the damage if a trusted application is compromised?
• Do you subscribe to threat intelligence feeds or vendor security advisories that would alert you to supply chain incidents?

Questions for Software Vendors

• What security controls protect your build pipeline and code-signing infrastructure?
• Do you use hardware security modules or other protected storage for your code-signing certificates?
• Have you undergone third-party security assessments, and can you share a summary of findings?
• What’s your process for detecting and responding to a compromise of your build environment?
• How do you validate the integrity of dependencies and libraries you incorporate into your software?
• If your software is compromised, what’s your customer notification and remediation process?

Vendors who can’t or won’t answer these questions aren’t necessarily compromised, but they may lack the maturity to prevent or detect a software supply chain attack. That’s a risk factor your business should weigh when deciding whether to adopt their software.

Conclusion

Software supply chain attacks aren’t theoretical risks. They’re active, well-documented, and increasing in frequency. Threat actors have learned that compromising one software vendor is more efficient than breaching thousands of individual companies. By targeting build pipelines and code-signing certificates, attackers deliver malicious code through the most trusted channel available: official software updates.

For small businesses that rely on third-party integrations to operate, this threat requires a shift in thinking. The software you trust today may have been weaponized before you installed it. Your vendors’ security practices are now part of your security perimeter, whether you have visibility into them or not.

The defense posture isn’t perfect, but it’s actionable. Vet your vendors, monitor your software, segment your environment, and maintain an inventory. Ask hard questions of your IT provider and your software vendors. When a software supply chain compromise is disclosed, know immediately whether you’re affected and have a plan to respond.

The threat is real, but it’s not unmanageable. Businesses that take supply chain security seriously, build it into their vendor management process, and work with IT partners who understand the threat landscape will be far better positioned to survive the next SolarWinds-scale event.