Secrets and dependencies

Two everyday sources of breaches that have little to do with clever attacks: leaked secrets and vulnerable dependencies. Both are about hygiene, and both are squarely within your control.

Handling secrets

A secret is anything that grants access — API keys, database passwords, signing keys, tokens. The rules, building on the configuration lesson:

• Never commit them. Git history is permanent; a key pushed even once is compromised. Keep secrets in environment variables or a secrets manager, and .gitignore secret files.
• Rotate on exposure. If a secret leaks, revoke and reissue it — deleting the commit isn't enough, since clones and forks retain it.
• Scope them tightly. Least privilege again: a key that can only read one bucket is far less dangerous than an all-powerful one.
• Don't log them. Secrets in logs are secrets leaked (the observability lesson's warning).

The dependency supply chain

Modern projects run mostly other people's code — hundreds of transitive dependencies (the project-shape lesson's node_modules). Each is code you're trusting and a potential entry point. This is supply-chain risk: a vulnerability — or malice — in a dependency becomes a vulnerability in you.

Practical hygiene:

• Keep dependencies updated — most exploits target known, already-patched flaws. Tools that scan for vulnerable versions (e.g. npm audit, Dependabot) flag them.
• Pin versions with a lockfile so builds are reproducible and an update is a deliberate, reviewable event.
• Minimise what you pull in — every dependency is attack surface and maintenance. Do you really need a package for a three-line function?
• Vet new additions — is it maintained, widely used, reputable?

Where to go next

Last in this module: a tour of the common vulnerabilities every developer should recognise.