Chapter 7 of 8 · 5 checks · 3 min

Supply chain, integrity and secrets (A03, A08)

Software supply chain failures are new at number three. Your app is only as safe as the packages, build steps and keys it depends on.

Show

Commit the lockfile and install from it in CIMust
Why it matters and how to check
Without a lockfile, every build can pull a different version of a dependency, including a freshly compromised one. Commit package-lock.json, pnpm-lock.yaml or the equivalent, and use the clean install command in CI and deploys, such as npm ci, which fails if the lockfile and manifest disagree.
To verify, confirm the lockfile is in git and that your CI and deploy logs show npm ci or pnpm install --frozen-lockfile, not a plain install. A pull request that changes dependencies should show a lockfile diff you can review.
Scan dependencies for known vulnerabilities on every changeMust
Why it matters and how to check
Known vulnerable components are the easiest way in, because the exploit is already public. Turn on automated dependency alerts in your repository host, run npm audit or an equivalent in CI, and decide a rule for when a high severity finding blocks a merge.
To verify, open your repository's security or dependency alerts page and confirm it is enabled and that no critical alert is older than your agreed fix window. Check that a CI job runs the audit on pull requests and that its result is visible.
Review new packages and install scripts before adding themShould
Why it matters and how to check
Typosquatted and hijacked packages often do their damage in install scripts or in a tampered entry file, before your code ever runs. Before adding a dependency, check its name carefully, its maintainers, its download history and whether it really needs install scripts. Consider disabling lifecycle scripts by default and allowing them per package.
To verify, list packages with install scripts using your package manager, and confirm each one is expected. Compare the number of direct dependencies with last quarter: growth should be deliberate, not accidental.
Example
Shell
# Run installs without lifecycle scripts, then allow only what you need npm ci --ignore-scripts
Keep secrets out of the repository and the client bundleMust
Why it matters and how to check
API keys, database URLs and signing secrets belong in environment variables or a secrets manager, not in source files, and never in variables that your framework exposes to the browser. Turn on secret scanning in your repository host so pushes with keys are blocked or flagged.
To verify, run a secret scanner over the full git history, not just the current tree. Search your built client JavaScript for strings like sk_, mongodb+srv and PRIVATE KEY. Any secret ever committed must be rotated, even if the commit was later removed.
Use Subresource Integrity on scripts loaded from a CDNNice to have
Why it matters and how to check
A script tag pointing at a third-party CDN runs whatever that CDN serves tomorrow. For static library files, pin an exact version and add an integrity hash with crossorigin, so the browser refuses a changed file. Scripts that change by design, such as analytics loaders, cannot be pinned, so keep that list short.
To verify, view the page source and list every external script. Each pinned library should carry an integrity attribute, and the remaining unpinned ones should be a short, known list.