Dependency hygiene and software supply-chain checks

Goal

Reduce the risk that a third-party package, build step or artifact introduces malicious or vulnerable code, and be able to answer "are we affected" quickly when a vulnerability is published.

Prerequisites

A lockfile for every package ecosystem in use and a pipeline that installs from it.

Steps

1. Inventory direct and transitive dependencies; remove those that are unused or trivially replaceable.
2. Pin exact versions and verify hashes at install time (pip's hash-checking mode; equivalents exist for npm, Cargo and others).
3. Run a vulnerability audit against the lockfile in the pipeline and on a schedule, and triage findings with an owner.
4. Assess upstream projects before adopting them: maintenance activity, release signing, security policy; OpenSSF Scorecard automates many of these checks.
5. Build in a clean, ephemeral environment from source control, and record provenance; SLSA describes increasing levels of build integrity.
6. Update dependencies deliberately in small, reviewed batches rather than never or all at once.

Expected result

Every artifact can be traced to pinned, hash-verified inputs; a published vulnerability is matched against the lockfile within a day; upgrades are routine.

Limits and test basis

Hash checking verifies that you got what you pinned, not that what you pinned is safe. Audits only know published vulnerabilities. Provenance frameworks require build-system support. Guidance follows the cited sources.