Supply chain and secrets
Most of the code you ship was written by people you have never met, and it reaches production through a pipeline that holds the keys to your cloud. This lesson shows you where that chain can be attacked and the control that belongs at each link: lockfiles and an update policy, SBOMs that answer "are we affected?" in minutes, signed builds, and secrets that are short-lived, scanned and quickly rotated.
By the end you can
- Explain five ways a dependency becomes a risk and the control that catches each one
- Set up lockfile installs, an update policy with a waiting period, and an audit gate that fails only on real risk
- Query SBOMs to list every app affected by a new advisory, comparing versions correctly
- Harden a GitHub Actions workflow: pinned actions, a read-only token, build provenance and OIDC to the cloud
- Run the first hour of a leaked-secret response in the right order
The everyday picture
Think of a restaurant kitchen. The chef cooks every dish, but almost nothing starts in the kitchen: flour, oil, spices and meat come from dozens of suppliers, and some of those suppliers buy from others. A careful kitchen does four things. It buys from known suppliers and checks the seal on every delivery. It writes down which batch of each ingredient went into which dish, so when a supplier announces a recall, the chef knows in minutes which dishes to pull. It keeps the delivery door locked and changes the code when a former employee leaves. And it never tapes the safe combination to the fridge.
Software works the same way. Your dependencies are the ingredients, the lockfile and the SBOM are the batch records, a signed build is the sealed delivery, and your API keys and cloud credentials are the safe combination. Each habit is cheap on a normal day and saves you on the day something goes wrong.
Why the supply chain made the Top 10
The OWASP Top 10 2025 lists Software Supply Chain Failures as the third most important risk. It replaces and widens the 2021 entry "Vulnerable and Outdated Components". The old entry was about running an old library with a known bug. The new one covers the whole path: the packages you install, the tools and actions that build your code, the artifacts you deploy and who could have changed them on the way.
The reason is scale. The Partner app that Lagoon Digital builds for Mangrove has roughly 40 direct dependencies in its package.json, and its lockfile lists close to a thousand packages, because each dependency brings its own. Those are transitive dependencies, and you run their code with the same rights as your own.
From the defender's side, a dependency becomes a risk in five common ways. Each has a signal you can watch for and a control that stops it.
- A known vulnerable version. The library has a published bug, and you are still on an affected version. Signal: an advisory. Control: an audit in CI and a habit of updating.
- A malicious new version of a real package. An attacker takes over a maintainer's account and publishes a release with hidden code. Signal: a release that appeared hours ago, often with a new install script. Control: a lockfile, so nothing changes without a pull request, and a waiting period before you accept new releases.
- A typosquatted name. Someone publishes a package with a name close to a popular one. Signal: a new dependency in a pull request that nobody discussed, with few downloads and a recent first release. Control: review every added dependency, and check the name against the one in the official docs.
- Install scripts. npm runs a package's
preinstallandpostinstallscripts during install, on laptops and in CI, before any test runs. Signal: a lockfile diff that adds a package with install scripts. Control: install with scripts turned off and allow the few packages that really need them. - Abandoned packages. No releases for years, issues unanswered, so the next bug never gets fixed, and an expired maintainer email domain can let someone take the account over. Signal: the last release date and open security issues. Control: replace it, or fork it into your own organisation and own it.
Quick check
A pull request from a teammate adds a dependency called expres-session (one "s") that nobody mentioned in the ticket. The package was first published last week. Which control is the right one here?
A typosquatted package usually has no advisory yet, so a clean audit proves nothing. The lockfile pins whatever you chose, including the wrong package. The signals are the near-miss name, the recent first release and that nobody discussed adding it.