Supply chain dependency reviews
A dependency update changes more than a version number
Review the resolved code, its build-time access and the path to production. A clean vulnerability scan is useful evidence, not a complete trust decision.
In this article
Identify what the package will be allowed to do
A small formatting package may run only in the browser. A build plugin can execute inside CI with access to source code, network connections and any credentials exposed to that job. The second package can have substantial reach even if it never ships in the runtime bundle.
Classify dependencies by where they execute: installation, build, test and production. Record the sensitive capabilities available in each environment. The distinction between development and production dependencies does not, by itself, describe security impact.
An illustrative failure is a compromised build dependency reading a deployment credential from the job environment. Removing that package from the final container would not undo the earlier exposure. Limit build credentials as well as reviewing the dependency.
Review the resolved change
Inspect the manifest and lockfile together. A direct version update can introduce new transitive packages or change their sources. Review the actual graph difference rather than assuming the top-level changelog covers everything installed.
A lockfile helps make resolution repeatable. For npm, the documented clean-install command rejects a manifest and lockfile mismatch rather than silently updating the lock. That is a reproducibility property, not proof that the locked code is trustworthy.
Keep package-manager configuration and runtime versions with the build evidence. Different installation settings can affect what executes or which optional components are selected.
- Resolved changeDirect and transitive versions, sources and integrity
- Execution reachInstall, build, test and runtime capabilities
- VerificationAdvisories, source review and relevant behaviour tests
- Release evidenceArtifact identity, provenance and rollback option
Use several kinds of evidence
Check known vulnerability advisories, maintenance history, release notes and relevant source changes. A scanner can identify known issues in recognised dependencies, but absence of an advisory does not establish absence of malicious or faulty behaviour.
Provenance can connect an artifact to its build process and source inputs. It helps answer where the artifact came from, while the verifier still needs a policy for trusted builders and expected source. A signed statement is not a general endorsement of the code's behaviour.
For a high-impact dependency, run tests around the capabilities the application relies on. A parser update deserves malformed-input and compatibility cases. A cryptography or authentication component needs review appropriate to that domain.
Make exceptions expire
Sometimes a required update cannot be applied immediately because it breaks a supported workflow. Record the affected dependency path, exposure assessment, temporary control, owner and review date.
Do not close an alert permanently because the vulnerable function is not currently called without preserving the reasoning. A later application change can make that path reachable.
Keep rollback tied to a known artifact
Retain the previous approved artifact and its dependency evidence. Rebuilding an old commit against newly resolved dependencies may not reproduce the previous release.
If compromise is suspected, assess build-environment exposure as well as runtime deployment. Rolling back the application does not revoke a credential that may already have been copied. The review should leave a clear picture of what changed, where it ran and what evidence supports releasing it.
Primary sources
npm: clean installSLSA: provenanceOWASP: vulnerable dependency managementReferences checked 11 September 2026.