Software Supply Chain Security: Check Dependencies

The National Cyber Security Centre (NCSC) has published guidance titled “Software supply chain attacks: check your dependencies”, warning that attackers are increasingly compromising open-source packages to spread malware through legitimate software. If your organisation builds or ships software, or simply relies on applications that pull in third-party code, the message is direct: review the dependencies you trust and review the code that uses them. The fastest way to act is to inventory every package you rely on, watch it for tampering, and commission a secure code review when the risk is material. This article explains the threat and how strong software supply chain security reduces it.

What the NCSC is warning about

The NCSC is warning that attackers poison popular open-source packages so malware flows downstream into every project that installs them. Compromising one widely used dependency is far more efficient than attacking thousands of organisations individually, and attackers have recognised exactly that.

The exposure exists because modern software is assembled, not written from scratch. A typical web application or backend service depends on hundreds of open-source libraries, and each of those libraries depends on others.

The NCSC blog highlights a pattern that has grown sharply: malicious code injected into open-source packages on public registries. The techniques vary. Some attackers hijack an abandoned package and publish a tampered version. Others use typosquatting, registering a package with a name one keystroke away from a trusted library, in the hope a developer installs the wrong one. A few compromise a maintainer’s account directly and push a backdoored release to people who already trust the original. In each case the malicious payload runs inside your build pipeline or your production environment with whatever privileges that code is granted.

The core point from the NCSC is that defenders cannot treat third-party code as inherently safe. You are responsible for what your software does, including the parts you did not write. That responsibility is the heart of software supply chain security.

Who this affects

Any UK organisation that develops its own applications, maintains internal tooling, runs a website with custom plugins, or deploys containers built from public base images is affected, because all of these consume open-source dependencies. The exposure is far wider than software houses alone.

SaaS providers, fintech firms, healthcare technology vendors and e-commerce businesses are all in scope, because their products are built on the same shared ecosystem.

The risk is sharpest where dependencies run with elevated access. A poisoned package inside a build server can exfiltrate signing keys and cloud credentials. A malicious library inside a customer-facing application can steal data, open a backdoor, or quietly tamper with transactions. Because the compromise arrives through a trusted update channel, traditional perimeter controls rarely catch it. This is precisely why the NCSC frames dependency review as a defensive discipline rather than a one-off task.

How to check your dependencies

Checking your dependencies is a practical programme of work, not a single scan. The following steps reflect the NCSC guidance and what we see work in real engagements.

• Build a software bill of materials (SBOM). You cannot secure what you cannot see. Catalogue every direct and transitive dependency, with versions, so you have a complete inventory to defend.
• Pin and verify versions. Lock dependencies to known-good versions and verify integrity using checksums or signatures, so an unexpected change cannot slip in silently.
• Scan continuously for known issues. Use software composition analysis to flag packages with published vulnerabilities, and wire it into your pipeline so new findings surface as code is built.
• Vet new and updated packages. Before adopting a library, check its maintenance health, download patterns and recent releases. Treat sudden maintainer changes or unexpected new scripts as warning signs of tampering.
• Constrain what code can do. Limit the privileges available to build agents and running applications, so a compromised dependency has less room to cause harm.
• Review the high-risk code paths by hand. Automated tooling catches known problems. It does not understand business logic, authentication flows or how a dependency is actually used in your application. That gap is where a human review earns its keep.

Automated checks are necessary but not sufficient. They tell you which packages have a recorded vulnerability. They do not tell you whether a quietly malicious update is abusing a legitimate function, or whether your own code uses a dependency in a dangerous way. Closing that gap is the role of a secure code review.

How secure code review and penetration testing address the risk

Secure code review addresses software supply chain risk by putting experienced testers inside your codebase to read the application the way an attacker would, going far beyond what a scanner can do. Reviewers analyse the code paths that automated tools rate as low priority but that an adversary would target first.

Our CREST-certified testers examine how third-party libraries are imported and invoked, whether dependency outputs are trusted without validation, how secrets and credentials are handled around those calls, and whether your build and deployment process can be subverted.

This complements penetration testing rather than replacing it. A penetration test probes the running application and infrastructure from the outside, proving what an attacker could actually reach and exploit. A code review works from the inside, finding flaws that never surface in black-box testing because they sit deep in logic or in the way a dependency is wired in. Used together, they give you both the attacker’s view and the architect’s view. For organisations responding to the NCSC guidance, the most effective approach is a dependency review combined with a focused secure code review of the components that handle sensitive data or run with high privilege.

The outcome is a prioritised, evidence-based report: what is exposed, how serious it is, and the specific remediation steps to fix it. That turns an abstract supply chain worry into a concrete, fundable plan of action.

What it costs and how EJN Labs helps

Cost depends on scope: the size of the codebase, the number of languages and services, the depth of dependency review required, and how much of the application handles sensitive data. As a guide, secure code review typical 2026 UK ranges are £3,500 to £7,000, £7,000 to £12,000, and £12,000 to £20,000. Our day rate is £1,100 to £1,400, and every tester on your engagement is senior or principal, never junior.

A smaller, single-service application with a contained set of dependencies usually sits in the lower band. A larger platform spanning multiple repositories, microservices and high-privilege build pipelines moves into the higher bands because there is genuinely more code and more risk to examine. We never quote a final figure without understanding your scope first.

You can see how we structure engagements on our secure code review service page, and review indicative figures across all our testing on our transparent penetration testing pricing page. When you are ready for an exact, scoped figure, the quickest route is to request a CREST penetration testing quote and tell us about your codebase. We will respond with a clear scope and a fixed price.

Frequently asked questions

What is a software supply chain attack?

A software supply chain attack compromises a trusted component your software depends on, rather than attacking you directly. The malicious code then runs inside your build pipeline or your application with whatever access that component holds, giving the attacker a foothold you installed yourself.

Common examples include malicious code injected into an open-source package, a hijacked maintainer account pushing a tampered release, or a typosquatted library installed by mistake.

How do I check my software dependencies for risk?

Build a complete inventory, or software bill of materials, of every direct and transitive dependency, then pin versions, verify their integrity, and scan continuously for known vulnerabilities. Follow that automated baseline with a review of the high-risk code paths by experienced testers.

Human review matters because automated tools cannot judge how a dependency is actually used in your application, nor spot a subtly malicious update.

Do I need a secure code review for software supply chain security?

Yes, if your application handles sensitive data, processes payments, runs with elevated privileges, or relies heavily on third-party libraries, a secure code review is strongly worthwhile. Automated dependency scanning catches known issues, but a human review finds logic flaws, unsafe use of dependencies and pipeline weaknesses that scanners miss.

If you are unsure whether your exposure justifies a review, ask us and we will give you an honest view of the scope.

How much does a secure code review cost in the UK?

Typical 2026 UK ranges are £3,500 to £7,000, £7,000 to £12,000, and £12,000 to £20,000, depending on codebase size, languages, and review depth. Our day rate is £1,100 to £1,400. Because cost is scope-dependent, we always confirm an exact price after understanding your codebase. The fastest way is to request a quote.

What is the difference between a dependency review and a penetration test?

A dependency review works from inside the source code, while a penetration test works from the outside against the running system. The review examines how libraries are used and where logic is unsafe, and the penetration test proves what an attacker could actually reach and exploit.

A code review shares the same inside-the-code vantage point. The disciplines answer different questions, and for supply chain risk they are most powerful when used together.

Is software supply chain security only relevant if we build our own software?

No. Any organisation that uses custom applications, internal tooling, website plugins, or containers built from public images is consuming open-source dependencies and shares the exposure. If you ship or operate software that pulls in third-party code, the NCSC guidance applies to you.