What matters first
- Review lockfile changes as part of a dependency update.
- Integrity data addresses artifact consistency, not whether the artifact is benign.
- Connect the resolved graph to the artifact actually deployed.
Understand the record the lockfile provides
npm documents package-lock.json as a description of the dependency tree and information used to reproduce installations. Other package managers have their own formats and behaviors. Review the selected versions, transitive dependencies, sources, and the install mode your pipeline uses.
A manifest range expresses what versions may be acceptable; the lockfile describes a particular resolution. Keeping them consistent makes changes more understandable. Treat an unexpected large lockfile diff as something to explain, rather than approving it only because the top-level dependency update looked small.
References: [1] npm
Review sources and integrity in context
Inspect changed package identities, resolved sources, transitive additions, and installation behavior. Integrity metadata can help detect an artifact that does not match its recorded content. It does not decide whether a newly recorded artifact contains malicious code or an unwanted installation step.
Consider how private registries, mirrors, and caches participate in installation. Record which source is authoritative and how the pipeline prevents unreviewed resolution changes. A repeatable install is useful only if the inputs being repeated are the ones the team intentionally approved.
Check the build environment and lifecycle scripts
Dependencies can affect a system during installation, code generation, testing, packaging, or runtime. Review which stages can execute package-supplied behavior and what credentials those stages receive. The Axios malicious-release incident illustrates why install-time execution can matter independently of deployed application behavior.
Choose package-manager and CI controls appropriate to the project rather than applying an untested blanket switch. Verify the legitimate build after tightening installation behavior. Document approved exceptions so a future engineer understands why a package needs a particular lifecycle operation.
References: [3] Axios maintainer, [4] GitHub
Verify the release dependency graph
Record the resolved graph and the build artifact used for deployment. Check whether production packaging installs again, substitutes a base image, or fetches additional components later. A successful local installation does not establish that the final runtime contains the same software.
Retain the lockfile and release evidence needed for advisory triage. After a security update, verify the affected component in the final artifact and address relevant older images or rollback paths. The goal is traceable dependency intent and delivery, alongside the rest of the security review.
References: [5] GitHub, [6] npm
Your next steps
- Review manifest and lockfile changes together, including transitive additions.
- Check source, integrity, and installation behavior for sensitive changes.
- Verify the pipeline’s repeatable install mode and approved exceptions.
- Discuss a dependency and release-exposure review for your application.
Questions teams ask
Does a committed lockfile prevent all supply chain attacks?
No. A malicious package can be deliberately or accidentally accepted into the recorded graph. Review of the selected inputs is still necessary.
Are integrity hashes a safety score?
No. They support consistency with expected content. They do not determine whether that content is trustworthy or appropriate.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .