A dependency review step on every pull request lists which packages were added, removed or updated, including indirect ones, and can fail the check on known vulnerabilities. It is the simplest place to catch a package an AI assistant added without anyone noticing.
What the check shows
GitHub's documentation describes dependency review for pull requests that change manifests or lockfiles. On the Files Changed tab it shows:
- Which dependencies were added, removed or updated, with release dates.
- Changes to indirect dependencies in lockfiles, which can be far larger than the change you meant to make.
- How many projects use each component.
- Whether an added or updated dependency has known vulnerabilities.
It requires the dependency graph to be enabled on the repository. The related action can run in a workflow, fails by default on vulnerable packages, and blocks merge when the repository requires that check. You can set the severity that triggers failure and allow or deny licenses.
Why release dates are useful
An assistant-suggested package whose first release was last week, with a name close to a popular library, is a pattern worth a pause. The date column makes that visible without opening the registry.
Why indirect changes matter
Reviewers read the line that adds one package. The lockfile can add forty more behind it. Seeing the transitive changes in one view turns an invisible change into a reviewable one.
Set it up in four steps
- Enable the dependency graph on the repository.
- Add the dependency review workflow to pull requests.
- Choose a failure threshold, for example high severity and above.
- Mark the check as required in branch protection.
What it does not catch
Known vulnerability data lags new malicious packages. A brand new malicious package will not be in any advisory list yet. So pair it with human review of new names: the publisher, first release date and install scripts. See how to check an AI-suggested package.
Safeguard's SBOM and dependency scanning, with policies and gates, covers the same ground across repositories, and reachability analysis helps decide which findings matter.
Handling the alerts
When the check fails, resist the urge to override it. Read the advisory, see whether a fixed version exists, and update to it. If no fix exists, decide whether you can avoid the vulnerable function or pick another package, and record the exception with an owner and an expiry date. An exception without a date tends to stay forever.
Quick check
Does dependency review replace a vulnerability scanner?
No. It focuses on what changed in a pull request. Keep a scanner running on the whole repository and on a schedule too.
Sources
Last reviewed: 19 October 2026.
