Many agree that software supply chains are a necessary evil in business IT infrastructure. They represent a challenge for companies to secure and involve departmental collaboration beyond your organization’s virtual walls. Furthermore, software supply chains are still an area where many companies don’t have effective programs. According to a speech by Feryal Clark at the National Cyber Security Centre on the 10th anniversary of the Cyber Essentials security accreditation scheme, only six percent of companies are assessing cyber risks from their supply chains.

Four areas to hone in on

The challenge around software supply chains is that every organisation has different security processes in place. These processes may vary based on how large each organisation is, how many developers it has, what software they use, and how well various teams collaborate.

There are four primary risk areas, security concerns, and potential attack approaches regarding software supply chains that you should be aware of.

1. The risk of using malicious software packages

Threat actors can compromise software libraries or packages that your organisation uses for any number of applications. This malicious package would be bundled into your application each time it’s compiled, including malicious code in each software update. Over time, this could be spread and exploited by that initial threat actor, or potentially even others.

For instance, this might look like a threat actor creating compromised packages on the npm JavaScript registry that mimics real packages.

2. Threat actors attempting to compromise an entire code repository

This involves injecting malicious code alongside existing legitimate software, and then waiting for it to make its way into unsuspecting users’ environments.

For example, threat actors might copy a very popular repository and only slightly alter its name (typosquatting) and code in the hopes that the difference would go unnoticed and mistakenly downloaded by an unsuspecting developer.

3. Third-party exploitation

Related to the attack vendors above, third-party exploitation means your software provider itself has been compromised. A threat actor has gained access to their network and may use their tool or environment to access their end users, including your organization. By gaining access to one company, attackers can target multiple others. This differs from a software package attack because you likely do not have full visibility into your third-party provider’s software, and it also presents more risk because you’re placing trust in your vendor’s software security versus internally developed software.

An example here would be the SolarWinds breach, where the company’s software was compromised and subsequently used to infiltrate several large enterprises and government organisations.

Looking for advanced methods to reduce Cybersecurity risks?

4 days of Keynotes, Sessions & Workshops in Munich, December 1 - 5, 2025

Discover now

4. Attackers may try to get their code contributed and included within open source software

This is the long-con approach based on social engineering tactics and attacks against project maintainers, where the attackers look to build trust and gain direct access to the project then add their own code.

The attack on XZ Utils, a data compression utility included with most Linux distributions, where obfuscated code was created and inserted after a committer spent years getting embedded and trusted within the community would be an example of this supply chain security risk.

How to protect your software supply chain and security benefits

Defending against these attacks requires a complete understanding of how your organization’s software development lifecycle works and how projects move from start to finish. Once you can confirm there are continuous integration and continuous deployment (CI/CD) pipelines in place and that infrastructure as code (IaC) is used to automate deployments, building best security practices earlier into the software development lifecycle will help ensure security risks are caught before they become potential issues.

For internally developed applications, building security as code (SaC) and policy as code (PaC) practices into your IaC templates will also help enforce security policies and checks at each stage of the CI/CD pipeline.

Using IaC security measures has two benefits: First, it ensures that every developer and IT professional who works with infrastructure understands and sees the policies in place because they are all cemented in code.

Second, implementing “anything as code” makes it easier for developers to enforce policies throughout an environment without fear of missing a step or wasting unnecessary time, and it’s also easier for developers to hone in on and remediate policy errors.

In the event of a supply chain attack, when a malicious component accidentally gets embedded, it may pass your coded policy checks. After all, that package is from a known source, so why would it be considered a risk? At this point, runtime security scanning is essential to your security process. A runtime scanner looks at the behavior of every software component as it is executed in production. From a security perspective, this focuses on what components actually do rather than what they may say they will do. Now, if and when a suspicious library starts acting outside its normal parameters, that activity can be immediately flagged for investigation.

For third-party software packages, getting that deep insight may not be possible, as many applications are provided as binaries to run rather than full collections of containers and their dependent libraries.

To work around this, you can ask during business negotiations for software bills of materials (SBOMs) that list included components – while many companies don’t yet automatically provide SBOMs for their systems, it is slowly being regulated into becoming the standard. It is required for any company providing software to the US Government, and it is mandated in the EU’s Cyber Resilience Act. In any case, checking security processes and accreditations can also help demonstrate that your supplier follows security best practices in their environments.

However, relying solely on what your vendor says they will do is still not enough. A runtime security tool also looks at what is actually happening within applications and can track that behavior over time. Similar to monitoring your internally created applications, knowing what that third-party application should be doing and looking for deviations can indicate potentially malicious activity where the software may have been compromised.

Plan ahead

Good security always starts with planning. Keeping your software supply chain secure involves looking ahead and understanding how your system would handle potential attacks. Once you have conducted a threat model or tabletop exercise with your developers and other stakeholders, you can work together to build security autonomously into the software lifecycle.

But before you run off, you cannot rely on this initial design work to secure your whole system. While it might be nice to think that this extensive preparation will keep your whole pipeline secure in the long term, the reality is that security is messy. However, by looking at both sides of the software pipeline – from initial development through the supply chain to your production deployments – you can comprehensively harden your environment.

Using a runtime security tool for real-time threat detection ensures you know when something is wrong in your production environment and equips you to fix or mitigate those potential vulnerabilities as they arise. This real-time, runtime security approach is your last line of defense, and it also complements the layers of security that you have already factored in.

No software supply chain is perfectly secure but with runtime security, you can get close.