Supply chain
Are malicious packages a risk to your app?
Most of the code in a modern web app wasn't written by its developers. It's open-source packages, and the packages those packages depend on, often a thousand or more. Since 2025, attackers have repeatedly hijacked popular packages to steal developers' keys and spread themselves automatically. A software supply chain review checks what you depend on and whether your build could be used against you.
Rather just ask someone? Talk to usIn short
A supply chain attack compromises your app through something it depends on, usually an open-source package or a build tool. In 2025 the Shai-Hulud worm hijacked hundreds of npm packages to steal developers' keys. Protection is mostly hygiene: lockfiles, reviewed updates, scoped build credentials, secrets kept out of build machines, and a list of what you depend on.
General information, current as at November 2026, not legal advice. A review lowers risk; it can't guarantee a system won't be breached, and it isn't a certified penetration test or a compliance audit.
- What is a software supply chain attack?
- An attack on the components and tools used to build software rather than the software itself: a popular package, a build plugin, a CI service or a developer's machine. Because one compromised package can be installed by thousands of projects, it's an efficient way to reach many victims at once. 'Software Supply Chain Failures' entered the OWASP Top 10 in 2025, at number three.
What actually matters
It has happened repeatedly, and at scale
In September 2025 the Shai-Hulud worm compromised more than 500 npm packages, according to CISA, stealing GitHub tokens and cloud keys from anyone who installed them. A second wave in November hit about 800 more. In 2026, a campaign compromised security tools including Trivy, then the LiteLLM package on PyPI.
Developers' machines and build servers are the target
These attacks run when a package is installed, on a laptop or in CI, and look for whatever credentials are there: npm and GitHub tokens, cloud keys, AI tool keys. The Nx compromise in 2025 even used developers' own AI command-line tools to search for secrets.
Lock what you install
Commit a lockfile, install from it exactly in CI, and don't auto-upgrade straight to production. A short delay before adopting new versions, a few days is common, avoids most malicious releases, which are usually caught and pulled quickly.
Give the build only the access it needs
CI pipelines often hold publish tokens and production keys they don't need for most jobs. Scope tokens to a single job, prefer short-lived credentials, restrict who can change workflows, and don't let pull requests from outside run with secrets.
Know what you depend on
A software bill of materials (SBOM), or simply a reviewed dependency list, means that when the next compromised package is announced you can answer 'are we affected?' in minutes. Remove packages you no longer use; each one is another way in.
If you were affected, rotate everything it could see
Removing the bad package isn't enough. Assume every credential on the affected machine or pipeline was taken: rotate them, check for unfamiliar repositories, workflows and access tokens, and review recent publishes and deployments.
A quick supply chain check
Most teams can do this in an afternoon.
- A lockfile is committed and CI installs from it exactly
- Dependency updates are reviewed, not merged automatically to production
- Automated alerts for known-vulnerable packages are on (Dependabot or similar)
- CI secrets are scoped per job, and outside pull requests can't read them
- npm and GitHub accounts with publish rights use multi-factor login
- Unused dependencies have been removed
Where we'd point you elsewhere
If your site is a hosted platform such as Shopify, Squarespace or Wix and you haven't added custom code, the platform carries most of this risk for you. A supply chain review matters when you build and deploy your own code, or a developer does it for you.
Tell us what you'd like checked
Describe what you run and what's worrying you. We'll suggest a sensible scope and a fixed price, or tell you plainly if a different kind of specialist would serve you better.
Common questions
Compare your lockfile against the published lists of compromised package versions from the time, and check your GitHub account for unfamiliar repositories or workflows. If an affected version was ever installed on a machine or in CI, rotate every credential that environment could reach.
Yes, and it's unavoidable. Almost all modern software is built on it, and popular projects are often well maintained. The risk is in how it's managed: unpinned versions, automatic updates, unused packages and build pipelines with more access than they need.
They help with known vulnerabilities, and you should use them. They're weaker against a freshly compromised package that nobody has flagged yet, which is why lockfiles, delayed adoption of new versions and scoped build credentials matter as well.
A software bill of materials is a list of every component in your software and its version. Some enterprise and government customers ask for one. Even if nobody asks, a current list is what lets you answer quickly whether you're affected by the next incident.
See it working
Software we'd build, running with a fictional business and sample data. Use it, then decide.
Also worth a look
- Leaked API Keys: How to Check and What to Do
- Is AI-Generated Code Secure?
- Cloud and Hosting Security: What to Check
- Already broken or stuck? Fix & rescue
Last reviewed . General information, not legal advice. Figures cited are from the sources named on each page.