Review a dependency update before merging it
Check the advisory, resolved dependency graph, package source, behavior changes, and actual test results before approving an automated dependency update.
An automated dependency pull request is a proposed change, not a security approval. Review what it resolves, what else it changes, and how the resulting artifact will reach the affected deployment. A merged manifest edit does not establish that every running instance has the corrected package.
Check the proposed resolution
Open the linked advisory and verify the package ecosystem, affected range, and intended fixed version. Inspect all occurrences in the resolved dependency graph. An update to one direct dependency can leave another transitive path on an affected version.
Read the lockfile diff alongside the manifest. Identify unrelated version churn, registry changes, new package identities, and altered integrity information. Check release notes and source changes for migrations, new install scripts, or changed defaults that affect the application's trust boundaries. A familiar package name alone does not explain a change in its distribution source.
Complete a focused review record
Use one record per update or coherent update group. Split unrelated changes when their combined diff prevents a useful review.
- Advisory and affected local occurrences are linked.
- Target version resolves the identified issue according to the reviewed source.
- Remaining vulnerable occurrences are fixed or tracked separately.
- Manifest and lockfile agree under a clean, controlled install.
- Package source and unexpected lifecycle changes have been checked.
- Relevant behavior tests completed on the reviewed revision.
- Build output identifies the intended resolved version.
- Deployment owner and rollback decision are recorded.
Run dependency installation and tests without unnecessary production credentials. Inspect the actual job result: a skipped, canceled, or queued check is not a passing test. Include the application path that uses the changed package, such as token verification, request parsing, or file processing.
Separate compatibility signals from local evidence
GitHub describes Dependabot compatibility scores as results from CI runs in other public repositories. That signal can help prioritize attention, but it does not test your configuration or prove that the update is free of security defects.
If the pull request changes after review, reassess the new diff and run the relevant checks again. Preserve the approved commit and test identifiers. After deployment, verify the installed artifact rather than relying only on the repository alert closing. Keep a rollback plan that acknowledges whether rollback restores the vulnerable version. Close the remediation record when the intended deployment is verified, or state clearly which environments still require action.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.