The lockfile is part of the change
A one-line manifest edit can introduce a large transitive graph. Review the lockfile as a dependency decision, not generated noise: identify newly added packages, unexpected maintainers, release age, known vulnerabilities, and license changes.
Automated dependency review can compare the pull request with its base and fail when newly introduced versions cross a chosen severity threshold. Make the check required if it is expected to protect the merge boundary.
Use policy without freezing delivery
Blocking every low-severity advisory can train teams to bypass the control. Choose a threshold that reflects product exposure, and define an exception format with owner, rationale, compensating control, and expiry.
Review provenance and necessity as well as CVEs. A dependency without a published advisory can still be risky if it is abandoned, newly transferred, typo-squatted, or unnecessary for the problem.
- Pin workflow actions and protect the workflow file itself.
- Inspect direct and transitive additions in every pull request.
- Define incompatible licenses as policy, not reviewer memory.
- Group routine updates while keeping security-critical changes visible.
Separate prevention from remediation
Dependency review protects new changes; continuous alerts find risk that emerges in the existing graph. Both are necessary because a safe package today may receive an advisory tomorrow.
The most useful workflow tells a developer what changed, why it is risky, which version fixes it, and how to request a time-bounded exception. Security becomes part of the code review instead of a separate queue.