Yes, if you can show it is switched on, running and respected. A check that reviews dependency changes in each pull request shows prevention, not just detection, which is what investors and acquirers want to see. Show the configuration, a few example runs, and the record of any overrides.
What dependency review is
GitHub describes dependency review as a way to catch insecure dependencies before you introduce them to your environment, and says it provides information on license, dependents and age of dependencies. Its documentation lists availability for public repositories on GitHub.com and for organisation owned repositories on a Team plan with GitHub Code Security enabled, so check what applies to you. The same idea exists in other tools: compare the dependency manifest in the pull request to the base branch and report what was added, with known advisories and license data.
Detection versus prevention
| Control | When it acts | What it shows a buyer |
|---|---|---|
| Scheduled scan of main | After code is merged | You find problems |
| Dependency check on pull request | Before code is merged | You stop problems entering |
| Required check with blocking rule | Before merge, enforced | You cannot skip it casually |
The third row is the strongest. A check that just comments can be ignored. A required check that blocks the merge needs a recorded override to bypass.
The evidence pack
- A screenshot of the repository rules showing the dependency check as required.
- The workflow or policy file, with the failure threshold, for example block high severity and unapproved licenses.
- Three pull requests where the check failed and what was done: dependency replaced, version bumped or exception approved.
- The exception log with approver and expiry.
- A sentence stating which repositories are covered and which are not yet.
Choosing thresholds
Start by failing on known critical vulnerabilities and disallowed licenses. Adding every severity at once creates noise and people learn to override. Tighten over a few releases. Record the thresholds and the date you changed them, since buyers like to see a program that matures.
Limits to state honestly
The check sees changes to declared dependencies. It does not catch code copied in by hand, packages installed at build time that no manifest lists, or vulnerabilities disclosed after merge. Say that a scheduled rescan covers the last part. Overclaiming here is the easiest way to lose a buyer's trust.
Running it for a young repository
With a small team, begin with warn-only mode for two weeks to see volume, then switch to blocking. Keep a notes file about what you learned. It becomes a short story for the data room: "we introduced the check in September, fixed twelve flagged additions in the first month and set a block rule in October."
Try it yourself
Click through it at your own pace, or open it full screen.
Try making the gate fail on a risky change, then see what the developer sees and what it takes to pass.
Safeguard provides policies, gates and guardrails for pull requests, with SBOM and dependency scanning behind them. A free scan shows findings for a repository before you set any gate.
Quick check
Do I need a paid plan for this?
For GitHub's own feature, availability depends on repository type and plan, as its documentation lists. Other tools offer similar checks.
What about bot pull requests?
Run the same check on them. A bot is a source of change like anyone else.
Sources
Last reviewed: 19 October 2026.
