# Ask what changed in the lockfile and where it will execute

A dependency review should connect code origin, capabilities and release evidence. Passing tests answer only part of that question.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Inspect the resolved graph

Compare direct and transitive versions, package sources and integrity metadata with the approved baseline. Investigate unexpected new packages or source locations.

Read the relevant release and migration notes. A patch label is not a substitute for understanding a change that affects the application's critical path.

Confirm the package-manager configuration and runtime version used by CI. Reproducible inputs need more than a committed manifest.

## Review execution and known findings

Identify installation scripts, build plugins and runtime code. Check the authority available at each stage, especially credentials and publish or deployment permissions.

Review advisory results with their affected dependency paths. Any exception should state why exposure is acceptable temporarily, who owns it and when it will be reconsidered.

Do not infer safety from a lack of known vulnerabilities. Consider maintenance changes and relevant source differences for higher-impact dependencies.

## Examine behaviour evidence

Look for tests covering the application's actual use of the updated component, including malformed inputs and error handling where relevant. A broad green suite may not exercise the changed boundary.

Review snapshot differences and generated output rather than accepting them wholesale. Confirm that any changed behaviour is intended or handled by the application.

Check that the candidate artifact contains the reviewed graph and that available provenance identifies the expected build source and process.

## Verify release and recovery

Confirm a bounded rollout plan and a known approved rollback artifact. If persistent formats change, establish the old version's compatibility before relying on rollback.

Ask what response would be needed if the package were later reported malicious. The team should be able to locate affected artifacts and build environments without manually searching every repository.

Approve the update with specific evidence and unresolved decisions. A version bump is reviewable when the team can explain its reach, not merely when the package manager completes successfully.

## Sources

- [SLSA: provenance](https://slsa.dev/spec/v1.2/provenance)
- [OWASP: vulnerable dependency management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)