Your app depends on hundreds of packages. Learn where supply chain attacks happen and the simple, low cost habits that reduce the risk, from lockfiles to build tokens.
A typical modern project pulls in hundreds of packages, each with its own dependencies. You trust all of that code with your users’ data, and you rarely read it. Attackers know this, which is why they target the packages, the build systems and the accounts of maintainers rather than your code directly.
You do not need a large security team to improve things. A handful of habits goes a long way.
Where the chain can break
Think of the journey from source code to running software as a chain. An attacker only needs one weak link.
Habit 1: Use a lockfile and commit it
A lockfile such as package-lock.json, poetry.lock or go.sum records the exact version of every dependency. Without it, a fresh install might quietly pick up a newer, compromised version. With it, everyone and every build gets exactly what you tested.
# installs exactly what the lockfile says, and fails if it does not match
npm ci
# Python equivalent with hashes
pip install --require-hashes -r requirements.txtHabit 2: Scan for known problems
Security researchers publish known vulnerabilities in packages. Tools check your dependencies against those lists. Run them in your pipeline so a vulnerable package fails the build instead of reaching production.
| Ecosystem | Built-in or common tool |
|---|---|
| JavaScript | npm audit |
| Python | pip-audit |
| Go | govulncheck |
| Many languages | Dependabot or Renovate for automatic update pull requests |
Habit 3: Think before you add a package
- Check the name carefully. Attackers publish packages with names one letter off from popular ones, hoping for a typo.
- Look at its health. Recent updates, active maintainers and a reasonable number of users are good signs.
- Ask if you need it. A package that does one tiny thing may be better as ten lines of your own code.
- Prefer fewer dependencies. Every one is another link in the chain.
Habit 4: Protect accounts and secrets
- Turn on two-factor authentication for your code host, package registry and cloud accounts.
- Never commit secrets. Use a secrets manager or environment variables, and scan your repository for leaks.
- Give CI jobs the least access they need, and use short lived credentials where possible.
- Rotate any key that may have been exposed, immediately.
Habit 5: Know what you ship
A software bill of materials (SBOM) is a list of every component in your software. When a new vulnerability is announced, an SBOM lets you answer “are we affected?” in minutes instead of days. Many build tools can generate one automatically.