Software supply chain attacks: how to secure a company against a hidden threat?

Every organization is building its digital defense walls, deploying advanced firewalls, intrusion detection systems and anti-virus software. We invest millions to protect gates, watchtowers and patrol the perimeter of our infrastructure. However, an attack on the software supply chain resembles the story of a Trojan horse – the threat does not try to breach the walls, but is brought inside by trusted allies. Cybercriminals have come to understand that it is often easier to compromise a smaller, less protected software vendor in order to then use its products as a vehicle to attack hundreds or thousands of its customers.

This fundamental shift in the attack paradigm requires IT and security leaders to make an equally fundamental shift in defense strategy. We can no longer trust software implicitly just because it comes from a well-known vendor and is signed with a digital certificate. This article takes an in-depth look at the mechanics of supply chain attacks, from compromising developers to infecting application building processes to exploiting vulnerable open-source libraries. More importantly, it lays out a concrete, multi-layered plan of action that will allow any organization to minimize risk and build resilience against one of the most sophisticated threats of the 21st century.

What is a software supply chain attack and why is it so effective?

A software supply chain attack is a cyberattack that targets an organization by compromising less secure elements in its supplier network. Instead of attacking the target directly, attackers infiltrate a third-party software vendor, service provider or technology partner. Their goal is to inject malicious code into a legitimate product or service, which is then distributed to targeted victims. In this way, the victim installs the malware themselves, trusting that it comes from a legitimate and secure source.

The effectiveness of this method lies in the abuse of trust, which is the foundation of the digital ecosystem. Every company uses dozens or even hundreds of applications and services from third-party vendors. Security mechanisms are configured to trust updates from vendors of operating systems, antivirus software or specialized business applications. By taking control of this trusted distribution channel, attackers bypass traditional perimeter defenses, such as firewalls, that would block unauthorized code.

What’s more, malicious code delivered as part of a legitimate update is often signed with a stolen or forged digital certificate, further putting defenses on alert. Such an attack gives criminals an initial foothold inside the networks of dozens and sometimes thousands of organizations at a time, allowing them to carefully select the most valuable targets for further exploitation. It is the scale and insidiousness of this method that makes it so dangerous.

What are the most common methods for cybercriminals to compromise suppliers?

To launch a successful attack on a supply chain, cybercriminals must first gain access to a software vendor’s internal infrastructure. They use a wide range of techniques to do this, often combining them into multi-stage campaigns. One of the most common methods is targeted phishing (spear phishing) targeting developers, system administrators or product managers. These messages are carefully crafted to persuade the victim to divulge their credentials or run malware that will give attackers remote access to their workstation.

Another popular vector is the exploitation of publicly known vulnerabilities in the vendor’s own systems. Criminals scan the vendor’s infrastructure for unpatched servers, misconfigured cloud services or poorly secured web applications. Gaining access to one system often allows further movement within the network (lateral movement) and access to key resources, such as source code repositories or servers that build software.

More sophisticated criminal groups may also employ attacks on physical infrastructure or use insiders. Although rarer, cases of bribing or blackmailing an employee with access to critical systems are not out of the question. Regardless of the method, the ultimate goal is always to seize control of a key element of the software development process that will allow the injection of proprietary malicious code.

How is malicious code hidden in legitimate software updates?

After gaining access to a vendor’s infrastructure, cybercriminals must discreetly place their malicious code inside a legitimate product. There are several key points in the software lifecycle that they can exploit for this purpose. One of the most desirable targets is the version control server (e.g. Git), where the application’s source code is stored. Attackers can add a few lines of malicious code to one of thousands of source files, hoping that the change will go unnoticed during code review.

An even more dangerous target is the build server. This is a system that automatically compiles source code into an executable file or installation package ready for distribution. Compromising this server allows attackers to inject malicious code after the review and testing stage. They can modify the libraries used during compilation or substitute finished binaries just before they are packaged.

The final step is to ensure that the malicious update is accepted by the victim’s systems. To do this, criminals must sign the modified code with the manufacturer’s digital certificate. If they have managed to take control of the build server, they often also gain access to the private keys used to sign the code. An application signed in this way is treated as fully legitimate and trusted by operating systems and antivirus software, allowing it to be installed and run with high privileges without problems.

What role do open-source libraries play in supply chain attacks?

Modern software is rarely written from scratch. The vast majority of commercial applications are built on a foundation of dozens or even hundreds of open-source libraries and components. This dependency, while speeding up development, creates a huge and often invisible attack surface. Attackers, instead of targeting a single, well-protected vendor, can compromise a single, popular open-source library to attack all projects that use it.

One technique is to compromise the account of the maintainer (maintainer) of a popular project. By taking control of the account, criminals can publish a new, malicious version of the library, which will be automatically downloaded and incorporated into thousands of applications around the world during their next build process. The high-profile xz library incident in early 2024 showed how a patient and sophisticated attacker can almost create a global security crisis by manipulating a single key component.

Other methods include so-called typosquatting and dependency confusion. In the case of typosquatting, criminals publish a malicious library under a name very similar to a popular, legitimate package (e.g. python-requests instead of requests), hoping for a programmer’s typo. Dependency confusion involves publishing a package with the same name as an internal, proprietary component in a public repository. If the build system is not properly configured, it can mistakenly download a malicious public version instead of a trusted internal one.

What were the consequences of the most famous supply chain attacks in history?

The history of cyber security knows several landmark attacks on the supply chain that changed the perception of this threat forever. The most famous example is the attack on SolarWinds in 2020. The attackers, affiliated with foreign intelligence, managed to inject a backdoor (named Sunburst) into the Orion network management platform. The malicious update was downloaded by more than 18,000 customers, including numerous US government agencies and major corporations. The attackers used this broad access to carefully select and more deeply infiltrate just a few dozen of the most strategic targets.

Another historical example that demonstrated the destructive power of such attacks was the NotPetya attack in 2017. It began by compromising the update servers of Ukrainian accounting software developer M.E.Doc. The malicious code, pretending to be ransomware but actually being a destructive wipe, spread around the world within hours, crippling global corporations such as Maersk, Merck and FedEx and causing losses estimated at more than $10 billion.

The 2021 attack on Kaseya, in turn, showed how the RaaS (Ransomware-as-a-Service) model can be combined with the supply chain vector. The REvil group exploited a vulnerability in Kaseya’s VSA software, used by managed service providers (MSPs) to remotely administer their customers’ systems. As a result, data at more than 1,500 companies worldwide was encrypted in one hit. These incidents clearly demonstrate that an attack on a single provider can have cascading, global consequences.

Why do traditional virus scanners and firewalls often fail in detecting these attacks?

Traditional defense mechanisms, such as antivirus software and firewalls, are based on a fundamental premise: distinguishing between what is “bad” and external and what is “good” and internal. A supply chain attack blurs this line, rendering these tools largely ineffective at the initial infection stage. The main reason is that the malicious code is delivered through a trusted distribution channel.

The firewall is designed to allow network traffic from known and trusted software vendor update servers. When an employee downloads an update from a compromised vendor, the firewall sees this as perfectly legitimate and expected communication. There is no basis for blocking it. Similarly, traditional antivirus software, which relies on signatures (i.e., the “fingerprints” of known malware), is helpless against new, specially crafted code that has never been seen before.

Moreover, the malicious code is often signed with an authentic digital certificate stolen from the manufacturer. For the operating system and security programs, such a signature is proof of the authenticity and integrity of the file. As a result, the infected application is treated as legitimate and is often given high system privileges, facilitating its further destructive actions. Only in the later stages of an attack, when the malware begins to communicate with C2 (Command and Control) servers or spread through the network, do more sophisticated systems (like EDR/NDR) have a chance to detect its anomalous behavior.

How to effectively assess and manage risks associated with software vendors?

Supply chain risk management must become an integral part of any organization’s security strategy. This process should begin even before signing a contract with a new supplier. A thorough security assessment (due diligence) of the potential partner should be conducted. This includes sending out security questionnaires that verify that the supplier follows good practices, such as regular penetration testing, secure software development cycle (SSDLC) and having an incident response plan.

It is also crucial to have appropriate contractual provisions in place. A vendor contract should clearly define its security responsibilities, including the requirement to immediately report any incidents that may affect our organization. It should also include the right to conduct security audits and clauses on financial liability in the event of a breach. It’s also a good idea to require key suppliers to provide independent audit reports, such as SOC 2, that confirm the maturity of their security controls.

Risk management is an ongoing process. It does not end when a contract is signed. You should regularly monitor your suppliers’ public information on security incidents and review their risk assessments. The table below provides a simplified framework that can help structure this process.

What is the Software Bill of Materials (SBOM) and why is it becoming an industry standard?

The Software Bill of Materials (SBOM), or “software component list,” is a formalized, machine-readable list of all the components, libraries and dependencies that make up an application. It can be compared to an ingredient label on a food product. Instead of “flour, water, salt,” SBOM lists all open-source libraries, commercial components and other modules, along with their exact versions and vendor information.

The importance of SBOM has grown exponentially, as it allows for transparency and quick response when a vulnerability is discovered in one of its components. Imagine a situation where a critical vulnerability is discovered in a popular open-source library such as Log4j (Log4Shell incident). An organization without an SBOM has to manually check hundreds of its applications to find out which ones are using the vulnerable library. This is a slow and error-prone process. An organization with an up-to-date SBOM for its software can search its resources in a matter of minutes and get a precise list of all systems that need immediate updates.

SBOM is becoming a global standard, and in some sectors, notably the US government, it is already a contractual requirement. For companies that buy software, requiring suppliers to provide SBOM is becoming a key element of supply chain risk management. For software vendors, on the other hand, creating and providing SBOM becomes a demonstration of maturity, transparency and concern for the security of their customers.

How can nFlo help strengthen resilience against supply chain attacks?

At nFlo, we take a comprehensive approach to supply chain security, combining audit, technical and strategic activities. We understand that protecting against this attack vector requires visibility, control and the ability to respond quickly. Our goal is to help organizations turn unmanaged risk into a consciously controlled component of their cyber security strategy.

One of our key services is supplier security audits. We help our clients develop and implement a formal risk assessment program for technology partners. We create dedicated security questionnaires, analyze documentation (e.g., SOC 2 reports, pentest results) and help negotiate contractual clauses that safeguard our clients’ interests. We act as an objective advisor, pointing out which suppliers meet the required standards and which ones pose a higher risk.

From a technical perspective, we perform advanced penetration testing and architecture analysis that assumes a scenario where one element of the supply chain is compromised. We verify whether mechanisms such as network segmentation and outbound traffic control (egress filtering) would effectively limit the spread of the attack and communication with C2 servers. Our team also assists in the implementation and configuration of EDR/XDR class systems, which through behavioral analysis are able to detect anomalous activity of trusted software, which is crucial in detecting these attacks.

Finally, we prepare organizations for the worst-case scenario. Our team of incident response specialists (Incident Response) helps create and test plans that take into account the specifics of supply chain attacks. We conduct simulation exercises (table-top exercises) to practice coordination, supplier communication and threat isolation processes before a real crisis occurs.

What is the role of DevSecOps in preventing the compromise of in-house software?

When discussing supply chain attacks, we often focus on the role of the victim. Equally important, however, is the question, “How do we avoid becoming the unwitting source of an attack on our customers?” For any software development company, the answer lies in implementing DevSecOps culture and practices. This is an approach that integrates security into the entire software development lifecycle (SDLC) – from design, coding and testing to deployment and maintenance.

DevSecOps practices include a number of automated security checks in the CI/CD (Continuous Integration/Continuous Delivery) pipeline. Static Code Security Analysis Tools (SAST) automatically scans source code for potential vulnerabilities even before it is compiled. Software Composition Analysis (SCA) tools scan the project for known vulnerabilities in the open-source libraries used and help automatically generate SBOMs.

Hardening (hardening) the development environment itself is also a key element. Enforcing the use of multi-factor authentication (MFA) for access to code repositories, securing build servers, implementing strict access controls, and protecting code signing keys are the absolute basics. Investing in DevSecOps is not only about protecting your own company, but also a fundamental part of building trust and credibility in the eyes of customers, for whom the security of the delivered software becomes a key selection criterion.