Every Dependency Is a Supplier You Never Vetted

Most organisations vet their suppliers carefully. A new supplier means due diligence, a contract, security questions and someone accountable for the relationship. Then a developer types one command and adds a component written by a stranger, along with the dozens of other components it depends on, and nobody asks a single question.

Every one of those components is a supplier. It runs inside your systems, with your data and your credentials. This article sets out how much of your software they make up, how attackers are using them, and how to bring them under the same control as any other supplier without slowing your teams to a crawl.

Most of your software is someone else’s

Black Duck’s annual audit of commercial codebases found open source in 98% of the 947 it examined in 2025. The average application contained 1,180 open-source components, up 30% in a year, and 87% of codebases had at least one known vulnerability, 44% of them critical Black Duck. Black Duck sells tools to manage this, so treat the figures as vendor research, but the pattern has been consistent for years: the code your own people write is a small part of what you run.

That is not a problem in itself. Open source is one of the great productivity gains in the history of software. The problem is that it arrives without the controls you apply to everything else you buy.

Attackers have moved upstream

Why break into a thousand organisations when you can compromise one component they all use?

• The patient insider. In March 2024 an engineer, Andres Freund, noticed that logins over SSH on a test system were slightly slow. He traced it to a backdoor in xz Utils, a compression library present in most Linux distributions, planted by a contributor who had spent a long time earning the maintainers’ trust. It was caught before it reached most stable releases, by luck rather than by any process Datadog Security Labs.
• The phished maintainer. In September 2025 one maintainer of popular JavaScript packages fell for a convincing phishing email. Attackers published malicious versions of 18 packages, including chalk and debug, which between them are downloaded around two billion times a week. They were live for about two and a half hours The Register.
• The worm. A week later a self-replicating worm, “Shai-Hulud”, spread through more than 500 npm packages, stealing developers’ and cloud credentials and using them to publish infected versions of further packages. CISA’s advice was to pin dependencies to versions from before the attack, check lockfiles and caches, and rotate credentials CISA.
• The new owner. In 2024 the domain behind polyfill.io, a script embedded in more than 100,000 websites, was bought by a new company and began serving malicious redirects. Nothing in the component had to be hacked; it simply changed hands BleepingComputer.

Sonatype, another vendor in this market, counted more than 454,000 new malicious open-source packages in 2025, around 75% more than the year before Sonatype. Most are crude. It takes only one to get through.

The fixes exist; the process doesn’t

When the Log4j vulnerability was found in December 2021, the US Cyber Safety Review Board concluded that it was “endemic” and that vulnerable copies would remain in systems “for many years to come, perhaps a decade or longer” CSRB. It was right. In 2025, 13% of all downloads of Log4j were still vulnerable versions, years after the fix was released Sonatype.

The same research found that about 95% of the vulnerable components downloaded in 2025 already had a fixed version available. Organisations are not short of patches. They are short of knowing what they use, and of a routine for keeping it current.

What is now expected of you

This is no longer only a technical concern; it is becoming a governance one.

• The UK’s Software Security Code of Practice, published by DSIT and the NCSC in May 2025, asks software suppliers to “understand the composition of the software and assess risks linked to the ingestion and maintenance of third-party components”, with a senior owner accountable for it GOV.UK. It is voluntary, and it is fast becoming what customers ask for.
• The Cyber Governance Code of Practice, published in April 2025, puts cyber risk, supply chains included, on the board’s agenda for medium and large organisations, public and private GOV.UK.
• The Cyber Security and Resilience Bill, introduced in November 2025, would bring managed service providers into the NIS regime and let regulators designate critical suppliers GOV.UK.
• If you sell into Europe, the EU Cyber Resilience Act applies. Its duty to report actively exploited vulnerabilities begins in September 2026, and most obligations follow in December 2027 European Commission.
• In the US, Executive Order 14028 made a software bill of materials (SBOM), a list of everything in a piece of software, a requirement for software sold to federal government Federal Register.

Treat dependencies like suppliers

None of this means banning open source or reviewing every line of code. It means applying the controls you already use for suppliers, scaled to the volume.

1. Know what you have. Produce an SBOM for everything you build, and ask for one with everything you buy. You cannot patch, or answer a regulator’s question, about components you cannot list.
2. Decide what gets in. Agree who may approve a new dependency and on what basis: its provenance, the health of its maintainers, its licence, its security record. Tools such as OpenSSF Scorecard make this fast OpenSSF.
3. Pin and verify. Use lockfiles and checksums so builds use exactly the versions you approved, not whatever was published this morning. Prefer components that publish signed provenance SLSA.
4. Buy yourself time. Have builds pull only from your own internal repository, and hold new versions there for a few days before use. Most malicious versions are found and removed within hours; the chalk compromise lasted two and a half.
5. Keep current, deliberately. Set a deadline for fixing known vulnerabilities by severity, and block versions with known critical flaws from being used at all.
6. Make someone accountable. Give one senior person ownership of software supply-chain risk, as both UK codes expect, and report on it like any other supplier risk.

If you would like help putting these controls in place, talk to us. We also make Cold Harbour, which does steps 2 to 5 for teams that would rather not build it themselves.

Sources

1. Black Duck (2026). Open Source Security and Risk Analysis report. Vendor research.
2. Datadog Security Labs (2024). The XZ Utils backdoor (CVE-2024-3094).
3. The Register (2025). Developer falls for phishing email, and npm packages are compromised.
4. CISA (2025). Widespread supply chain compromise impacting npm ecosystem.
5. BleepingComputer (2024). Polyfill.io JavaScript supply chain attack impacts over 100K sites.
6. Sonatype (2026). State of the Software Supply Chain, including the vulnerability management chapter. Vendor research.
7. Cyber Safety Review Board (2022). Review of the December 2021 Log4j event: key findings and recommendations.
8. Department for Science, Innovation and Technology and NCSC (2025). Software Security Code of Practice.
9. Department for Science, Innovation and Technology (2025). Cyber Governance Code of Practice.
10. GOV.UK (2025). Cyber Security and Resilience Bill.
11. European Commission. Cyber Resilience Act: reporting obligations.
12. Executive Order 14028 (2021). Improving the Nation’s Cybersecurity. Federal Register.
13. OpenSSF. Scorecard, and SLSA version 1.0 (2023).