The Four-Question Dependency Review
A short framework V-Spot researchers run on every dependency that touches production. Four questions. Honest answers in writing. We use this in every supply chain brief we publish.
Most package compromises do not require new defensive technology to catch. They require asking four questions out loud, in writing, before the package enters the build. The framework below is deliberately small. It is meant to be run by an engineer in ten minutes, not by a committee over six weeks.
- Question 01
Who can publish this package, and how is that controlled?
Most supply chain attacks start with a publish-credential compromise. If you cannot answer this in under a minute by reading the package’s metadata and repository, the package is failing the first test. Look for: number of maintainers, presence of provenance attestations, whether 2FA is enforced on the registry account, and whether publishing is automated from a build pipeline or done by hand from a developer machine.
- Question 02
What does it run at install time, and what does it touch?
A package with a postinstall hook can do anything on your machine the moment you run npm install. Read the install scripts, the build steps, and any code that runs before the actual library import. If the package fetches additional code from the internet at install time, that is not a dependency, that is a delivery channel.
- Question 03
What changes between the version you pinned and the version you are about to install?
Pinned versions only help if you actually read the diff before bumping. Most supply chain compromises ship as a minor or patch version that looks routine. Compare the package contents tarball, not just the GitHub release notes. The GitHub release is what the maintainer chose to tell you. The tarball is what npm actually serves to your build.
- Question 04
If this package is compromised tomorrow, what is the blast radius?
Some dependencies sit at the edge of your system and a compromise is recoverable. Others sit on the critical path and a compromise rotates every credential you have. Map this once per dependency. The packages whose compromise would cost you a week of incident response are the ones that get the deepest review.
How to use this in practice
Run all four questions on every new direct dependency. Run questions 01, 03, and 04 on every transitive dependency that shows up in a lockfile diff. Capture the answers in a short note attached to the pull request. The note is the artefact, not the checklist; if a future incident happens, the note is what tells you what was reviewed and what was not.
The point of the framework is not to slow things down. It is to make the review legible. Most teams already think about most of this implicitly. Writing it down is what turns implicit caution into a defensible process.
The framework in action
Each brief in the V-Spot TeamPCP research series applies this framework to a real-world supply chain compromise.
See the TeamPCP series