Skip to content

The NCSC warning on software dependencies

Your software relies on more than your own code. Learn why the NCSC is warning businesses to check their software dependencies.

// key points

  • In June 2026 the NCSC warned that attackers are compromising open-source packages, including in the npm and PyPI ecosystems, to spread malicious software.
  • One trusted package can pull in a long chain of other dependencies, and each one is a possible route in.
  • The NCSC recommends knowing your third-party components, checking them for known vulnerabilities and keeping an inventory such as an SBOM.
  • An SBOM works like an ingredients list, so you can answer "are we affected?" quickly.

When you open an app, log into a customer portal or use a piece of business software, it might feel like one complete product.

Behind the scenes, it’s more like a building made from parts supplied by hundreds of different manufacturers.

Modern developers rarely write every line of software from scratch. They use existing packages and libraries to add everything from login functionality and payment processing to sending emails and displaying information on screen.

It makes building software faster and more affordable. But it also creates a question many businesses may never have considered:

What happens if one of those trusted building blocks is compromised?

The NCSC has issued a warning

In June 2026, the UK’s National Cyber Security Centre (NCSC) warned that attackers are compromising open-source software packages to spread malicious software.

The NCSC highlighted recent attacks affecting widely used software ecosystems including npm and PyPI, which developers around the world use to add ready-made functionality to applications.

The problem is trust.

A developer might choose one trusted package. That package may rely on several others. Those packages can depend on even more.

Before long, one application can have a surprisingly large chain of dependencies sitting underneath it.

An attacker doesn’t necessarily need to find a weakness in the software your team wrote. If they can compromise something your software already trusts, that can provide another route in.

Do you know what’s inside your software?

This is why visibility matters.

The NCSC recommends organisations understand the third-party components their software uses and regularly check them for known vulnerabilities. It also recommends keeping an inventory of those components, which can take the form of a Software Bill of Materials, or SBOM.

Think of an SBOM like an ingredients list for your software.

If a security problem is discovered in one particular ingredient, you can quickly establish whether your software contains it.

Without that visibility, answering a seemingly simple question, “Are we affected?” …  can become much harder.

This isn’t just a developer problem

Businesses increasingly depend on bespoke software, customer portals, mobile apps, integrations and internal systems. And with AI making software quicker and easier to create, the amount of code organisations rely on is only growing.

You don’t need to understand every package inside your application.

But somebody needs to be checking them.

Hacka scans your source code and the components it relies on, looking for vulnerabilities and helping you understand what actually needs attention. It can also produce an SBOM, giving you a clearer picture of what’s sitting underneath your software.

Because security isn’t only about the code you can see.

Sometimes, the risk is hiding several layers underneath it.

Do you know what’s inside your software?

Start today with a free Hacka scan to identify your first vulnerability!

<Scan.Exploit.Secure> Find out what's exposed in your code.

Hacka finds vulnerabilities, risky dependencies and exposed secrets, proves what's exploitable and shows you the fix. Your first scan is free, with no card required.

The Hacka team

Hacka is built by the team at Code Galaxy, who make AI-powered security scanning that finds vulnerabilities in code, proves which are exploitable and shows how to fix them.

Published 11 Sep 2026 · Updated 10 Nov 2026 ← All articles
All articles
Updates

Why security debt is the new technical debt

The shortcuts taken to meet deadlines, the legacy code nobody wants to touch, the features that “work for now”. Why security debt builds up the same way, and costs more.