Attacks on the software supply chain: risks and defense

Software supply chain attacks have become one of the most serious headaches for companies of all sizes. Protecting your own perimeter is no longer enough: if one of your software, hardware, or cloud service providers goes down, you can be affected even if you weren't the primary target.

The problem is that these incidents are often complex, silent, and have a massive reach : a single breach in a widely used provider can open the door to thousands of organizations simultaneously. That's why understanding how these attacks work, what real-world examples we've seen, and what practical measures you can take is key to reducing your exposure.

What is a software supply chain and why is it so vulnerable?

In cybersecurity, the supply chain encompasses all suppliers and third parties involved in providing digital services to a company: from hardware manufacturers and software developers to internet providers, cloud services, monitoring tools, and email and collaboration platforms.

The development and operation of software and hardware products rarely depend on a single actor. It's common for multiple manufacturers, integrators, resellers, and managed service providers to be involved. The end customer almost never sees all of these participants, but their security depends on them as much as on their own systems.

Cybercriminals exploit this reality to find the weakest link : a vendor with lax security practices, a poorly secured build chain, or a software component with vulnerable code. If they manage to inject a malicious fragment into that chain, they can infiltrate highly sensitive environments with relatively little effort.

That's why supply chain attacks have skyrocketed: a single compromise can give access to thousands of victims , facilitate the theft of confidential data, prolonged espionage, or even remote control of critical infrastructure.

Types of attacks on the software supply chain

Supply chain attacks are not a single type of incident, but a family of tactics that share the same objective : to exploit vulnerabilities in solutions or processes that are then reused in many organizations.

Among the most common modalities we can find several categories, which are often combined in sophisticated campaigns:

Compromised software

In this case, the focus is on application code, libraries, or development tools . The attacker can directly modify a component, manipulate compilation scripts, or poison repositories so that, without the vendor's detection, distributed products include malicious functionality.

The preferred vector is usually software updates : the cybercriminal introduces the backdoor into the build process or the patch distribution server, so that every customer who updates their product also installs the malware. To give it a legitimate appearance, stolen certificates are often used to sign the code.

Hardware and firmware tampered with

In the physical realm, attackers target mass-distributed devices , from network equipment to workstations and embedded components. Their goal is to introduce modifications to the firmware or even the hardware design, such as spyware or modules with backdoors.

Because these changes occur at very low levels, detection is complex and the potential scope is enormous: a device compromised from the factory can provide direct access to internal networks or allow the persistent capture of sensitive information.

pre-installed malware and stolen certificates

Another variation involves system images or hardware containing malware from the source . This can occur during production, in customization processes for a specific client, or in the preparation of virtual machine or container images.

Digital certificates stolen from manufacturers or developers are also very dangerous . With them, attackers can sign altered binaries to make them appear legitimate, bypass integrity checks, and drastically reduce the likelihood of detection during update or installation processes.

Specific risks of open source and “secrets”

The intensive use of open-source software (OSS) brings speed and flexibility to development, but it also multiplies the attack surface. Many projects rely on the altruistic maintenance of volunteer developers, who may not have the resources to review every contribution or respond quickly to new attack vectors.

On the other hand, poorly managed "secrets" —API keys, tokens, passwords, or certificates inadvertently embedded in the source code —are proliferating in code repositories . Ransomware groups and other sophisticated actors massively scan these repositories for exposed credentials that would allow them to pivot to other systems.

Real attacks on the supply chain: the most relevant cases

The last few years have seen numerous examples of supply chain attacks with global repercussions , many of them linked to major software or service providers. These are some of the most illustrative cases.

SolarWinds and the Solorigate campaign

One of the most high-profile incidents occurred in late 2020, when highly sophisticated attackers managed to compromise the build environment of SolarWinds , a provider of network monitoring software used by companies and public bodies around the world.

The attackers injected a malicious component into updates for Orion, their infrastructure management platform. Each customer who installed the update unknowingly received a Trojan horse that opened the door to secret remote access . It is estimated that more than 18.000 organizations may have been affected, including large technology companies, government agencies, and critical infrastructure entities.

Kaseya and the massive ransomware

Another powerful example was the attack on Kaseya , a remote management software (RMM) provider for managed service providers (MSPs). The REvil ransomware gang exploited a zero-day vulnerability in the VSA product, deploying malicious code to MSP customers using the platform.

Within hours, between 800 and 1.500 companies were affected by the encryption of their systems. The attackers demanded a multi-million dollar ransom (70 million dollars) in exchange for the master decryption key, demonstrating the enormous leverage that these types of attacks on suppliers have.

Mimecast, Codecov, Atlassian and other incidents

In the case of Mimecast , the incident revolved around a compromised digital certificate that some customers used to securely connect their Microsoft 365 Exchange services. By controlling that certificate, the attackers gained the ability to intercept and manipulate communications.

The attack on Codecov , a code coverage analysis company, was based on the modification of a Bash loading script. This alteration allowed cybercriminals to redirect sensitive information (such as source code and secrets) from Codecov's client environments to servers they controlled.

In 2020, Check Point Research discovered a chain of vulnerabilities in Atlassian that, when combined, allowed attackers to take control of accounts and applications linked via single sign-on (SSO). Although the disclosure was responsible and the vulnerability was patched promptly, it illustrated how a flaw in a core vendor can become a high-impact supply chain attack vector.

NotPetya and the British Airways case

The malware known as NotPetya began as a pseudo-ransomware distributed through a malicious update to accounting software used in Ukraine. In reality, it didn't store any decryption key, acting as a "wiper" that irreversibly destroyed data and spread rapidly, with serious economic consequences.

In the e-commerce sector, British Airways suffered an attack in 2018 from the Magecart group , which inserted malicious code into the systems of one of the airline's suppliers. This code ended up affecting its website and app, intercepting payment data from more than 380.000 customer transactions.

The attempted backdoor in Linux XZ

In 2024, a sophisticated attempt to inject a backdoor into XZ Utils , a widely used compression tool in Linux systems, was discovered. The attack was developed over years, gaining the trust of the open-source community before gradually introducing malicious changes to the code.

The hidden functionality allowed remote code execution for attackers who possessed a specific key. Although the compromised version was not widely deployed in production, it was present in development versions, and experts warned that, had it gone undetected, millions of Linux systems would have been exposed.

How these attacks work and why they are so dangerous

Supply chain attacks exploit implicit trust relationships between organizations. When you install a vendor's software, integrate a third-party library, or connect your email to an external service, you assume that company is adequately protecting its own security.

Cybercriminals target providers with the weakest defenses, knowing that if they can compromise them, they can then move on to better-protected customers by exploiting that trust. MSPs are particularly attractive targets, as they have deep access to the networks of many customers.

In scenarios like SolarWinds, the attack is orchestrated by gaining access to the build or update servers . There, a backdoor is injected into the code that will be distributed to thousands of organizations. In other cases, the attack vector is found in scripts, CI/CD chains, compromised repositories, or manipulated open-source dependencies.

The danger of these attacks lies in the fact that they don't attempt to breach the highest wall, but rather to force open the less guarded side gate . Even with a robust security program, if you don't manage the risk posed by third parties, you can still find yourself vulnerable.

Impacts and trends of supply chain attacks

Recent data points to explosive growth: between 2021 and 2023 attacks of this type increased by more than 400% , and subsequent studies indicate that hardware and software supply chains recorded one of the largest increases in incidents in 2024.

The hardest hit sectors include technology, financial services, law firms, consultancies and luxury brands , all of which have strong supplier ecosystems and a high value of the information they handle.

The motivations range from financial gain (ransomware, data theft for sale) to espionage and the disruption of critical services . Global demand for hardware and the rise of AI have made this technology chain a prime target for threat groups.

Furthermore, many incidents aren't even classified as supply chain attacks because incident response investigations prioritize restoring the direct victim's operations rather than tracing the exact source of the intrusion. This results in the problem being underestimated in official statistics.

Key best practices against supply chain attacks

Mitigating these risks requires combining third-party management, technical controls, and cultural changes in both IT and development. It's not a single tool, but rather a continuous and structured approach.

1. Inventory and control of assets and Shadow IT

The first step is knowing what you have and who provides it. Maintaining an up-to-date inventory of software , services, and vendors is essential for understanding your exposure surface. This includes SaaS applications, productivity tools, security solutions, and development components.

It's crucial to detect and reduce Shadow IT : applications, services, or integrations that employees adopt on their own without going through official processes. Each unauthorized tool is a new link in the supply chain that may not be under any scrutiny.

2. Evaluate and classify the risk of suppliers

Not all third parties pose the same level of risk. It is advisable to establish a formal process for evaluating the security posture of each provider , assessing aspects such as their certifications, secure development policies, vulnerability management, and use of encryption.

Next, they can be grouped according to their potential impact on your business (access to sensitive data, service criticality, position in your architecture). High-risk providers should be subject to stricter controls and monitoring , including regular reviews and clear contractual requirements.

3. Continuous risk validation and “cyber altruism”

Third-party management cannot be a one-off review at the start of the relationship. It must be treated as an ongoing monitoring process , regularly reviewing public incidents, changes in the provider's infrastructure, and the emergence of new vulnerabilities.

Some large organizations are adopting a "cyber altruism" strategy , sharing security tools, training, and capabilities with smaller vendors. The logic is simple: the entire ecosystem shares the same level of exposure, and you're only as strong as your weakest link.

4. Principle of least privilege and network segmentation

Reducing permissions is one of the most effective defenses. Applying the principle of least privilege means granting employees, applications, and external partners only the access strictly necessary for their function.

This approach is complemented by network segmentation : dividing the infrastructure into logical zones with well-defined access controls. This way, if one provider or third-party software is compromised, it will be more difficult for the attacker to move laterally and spread the damage to other systems.

5. DevSecOps and software lifecycle security

Integrating security into the development lifecycle (DevSecOps) is essential for detecting code tampering, builds, and CI/CD pipelines before they reach production. This includes static analysis (SAST), dependency checks (SCA), container scans, and artifact integrity verification.

Adopting standards like SLSA (Supply-chain Levels for Software Artifacts) helps to harden the build process , ensuring that only signed, reproducible, and verified builds can be distributed to internal or external customers.

6. Advanced endpoint detection and response

At the workstation and server level, it is important to have endpoint detection and response (EDR/XDR) tools capable of identifying anomalous behaviors linked to supply chain attacks: unusual code payloads, suspicious outbound communications, or execution of signed but malicious binaries.

Modern solutions incorporate automation to block threats in real time , isolate compromised teams, and help Security Operations Center (SOC) analysts investigate incidents that cross multiple vectors (network, cloud, email, mobile).

7. Client-side tools and browser controls

In scenarios such as Magecart attacks, the problem manifests itself in the end user's browser. In these cases, client-side protection tools become crucial , as they monitor the code executing on the page, detect injections, and validate the integrity of scripts and iframes.

These controls allow the identification of attempts to steal data in payment or login forms, even when the source is an external content provider or a compromised third-party integration.

8. Strict policies for code integrity and allowed applications

Another layer of defense involves using allowlisting and code integrity policies that only permit the execution of signed and verified binaries. This reduces the opportunity for fraudulently introduced components to run unchecked.

Combined with signature validation, hash verification, and certificate review, this ensures that only authorized software can run on the systems , minimizing the impact of potential compromises in the update chain.

9. Secured compilation and update infrastructures

Servers and build and update pipelines should be treated as high-value strategic assets . It is essential to strengthen their security with strict access controls, separation of duties, continuous monitoring, and robust authentication.

In addition, it is advisable to implement cryptographic signatures without an exposed key (for example, through secure hardware or centralized signing services), so that an attacker who compromises a build server cannot freely sign artifacts without leaving a trace.

10. Incident response processes adapted to the supply chain

Any modern incident response plan must address vendor or third-party component breach scenarios . This includes defining how to isolate affected systems, how to communicate with the vendors involved, how to revoke certificates, and how to deploy emergency patches.

It is also useful to practice simulation exercises specifically for supply chain attacks , as the context, timing, and coordination with third parties often differ from a purely internal incident.

Platforms and technologies that help protect the supply chain

In recent years, specialized solutions have emerged that aim to provide comprehensive coverage of the application lifecycle against these types of attacks, reducing the need to manage multiple disconnected tools.

Protecting source code and trade secrets

Modern AppSec platforms include real-time repository analysis, with capabilities for detecting code vulnerabilities (SAST) and exposed secrets (keys, tokens, credentials). They can block commits with dangerous content using CI/CD guardrails, preventing errors or malicious injections from leaving the repository.

In addition, many incorporate features to automatically validate and revoke leaked secrets , integrating with credential managers and identity systems, thus reducing the time an exposed credential remains useful to an attacker.

Security of the build phase, packaging, and dependencies

During the build phase, these platforms apply compliance checks based on frameworks like SLSA, verifying the integrity of artifacts and monitoring CI/CD jobs for anomalous behavior . If they detect anything suspicious, they flag and block the builds before release.

During the packaging phase, malware detection and license analysis are applied to each artifact, ensuring that the libraries used comply with legal and security requirements. In parallel, software composition analysis (SCA) goes beyond simply listing CVEs, assessing whether vulnerabilities are actually exploitable in that context.

Many manufacturers include remediation engines that suggest safe upgrade paths and specific patches , prioritizing versions that reduce risk without introducing known regressions. This speeds up problem fixes without slowing down development.

Unified visibility and intelligent response

A key benefit of these solutions is that they offer a unified view of risk across the entire SDLC , from code to production. Instead of managing multiple isolated tools, development and security teams access a single source of truth with consolidated data.

Some advanced engines generate automatic patches, pull requests, or step-by-step guides to resolve each issue, prioritizing based on impact and ease of exploitation. This lightens the workload for teams and helps them respond more quickly to emerging vulnerabilities and threats.

Reducing the impact of a supply chain gap

Even with all preventative measures in place, it's necessary to assume that a third-party supplier or component could be compromised at some point. Therefore, it's essential to design the architecture in a way that minimizes the impact of such a breach.

Zero Trust models rely on least privilege access and continuous identity verification of both users and applications. This way, even if one system is compromised, it will be very difficult for an attacker to move laterally to other, more critical assets.

Zero Trust Network Access (ZTNA) techniques, combined with segmentation, new code sandboxing, and behavioral analysis, help prevent a single breach from becoming a catastrophic incident that affects the entire organization.

In addition, it is advisable to have clear continuity and recovery plans, as well as agreements with key suppliers that specify how notifications, patches and collaboration will be managed in the event of incidents affecting the supply chain.

Software supply chain attacks have gone from being a technical curiosity to a central threat for any connected business, and the combination of ever-expanding digital ecosystems, massive use of open source, dependence on third parties, and AI tools has created the perfect breeding ground for them to continue growing. Only with a global view of your suppliers, least privilege controls, robust DevSecOps practices, and security platforms capable of monitoring the entire lifecycle of your applications can you truly reduce the attack surface and keep at bay adversaries who, now more than ever, seek to enter through your partners' doors rather than directly assaulting your fortress.