Practical software supply chain security for teams that ship

"Software supply chain security" covers everything between a line of open-source code and your production server: the packages you depend on, the registries they come from, your build system and your CI. For most product teams, the risk sits in a few places, and a handful of habits cover most of it.

The attacks that actually happen

• Known vulnerabilities in dependencies. The most common issue by far. They are fixed by upgrading, but only if you know which upgrades matter.
• Malicious packages. Typosquats, hijacked maintainer accounts and worms that publish poisoned versions of real packages. They run code on install.
• Malware committed into repositories. Payloads hidden in build configs or editor tasks, spread through compromised developer accounts.
• Leaked or over-privileged credentials in CI, which turn any of the above into a breach.

Controls that cover most of the risk

1. Commit lockfiles everywhere. Exact versions are what every other control relies on. Without them you can't know what you run.
2. Keep an up-to-date inventory. Know which versions of which packages are in which repositories, across organizations. "Are we affected?" should take minutes, not a day of grepping.
3. Prioritise by exploitation, not just severity. Fix what CISA lists as exploited first, then critical and high issues in code that ships. See our guide to KEV and EPSS.
4. Gate pull requests. Fail pull requests that add new high-risk dependencies, and leave the existing backlog to a scheduled clean-up.
5. Limit install-time code execution in CI. For example, run npm ci --ignore-scripts where you can, and keep CI tokens short-lived and narrowly scoped.
6. Generate SBOMs where customers or regulators ask. CycloneDX and SPDX are the common formats.
7. Have a plan for a malicious package. Know who rotates which secrets, in what order.

Where Lockhound fits

Lockhound covers items 2, 3 and 4 for every GitHub repository you connect. It also flags known malicious packages and committed malware, and exports SBOMs on the Business plan. It reads only dependency files and a few malware-prone files, never runs your code, and needs no CI changes.

It doesn't replace secret scanning, SAST, container scanning or install-time package firewalls. If you need those, add tools built for them. The Dependabot comparison is a fair place to start if you're deciding what you need.