I keep seeing discussions about Dependabot alerts and code scanning, but I rarely hear anyone talking about the **dependency review** feature that shows up right in the pull request. People seem to treat it as just a repeat of the alerts dashboard, but I think that's missing the point entirely.
Its real power is in **context and prevention**. It's a shift-left control that stops *new* vulnerabilities from entering your codebase at the merge stage. Unlike the general alerts list, which can feel overwhelming, this targets the *change*.
Here’s a concrete example from a recent review I did. A dev was adding a new feature and introduced a package. The PR looked fine, but the dependency review block flagged this:
```yaml
- name: lodash
version: 4.17.15
vulnerability: CVE-2020-8203 (High severity)
advisory: Prototype pollution vulnerability
```
Without this, that vulnerable version would have been merged. The alert might have shown up *later* in the dashboard, but the flaw would already be in our main branch. Dependency review acts as a gate.
Why it's underrated:
* **It's actionable at the perfect moment.** The developer is already in the context of that change. They can immediately update the version, find an alternative, or assess the risk.
* **It simplifies compliance.** For frameworks like SOC 2, having a preventative control that blocks known-vulnerable dependencies from being merged is gold for audit evidence.
* **It educates without being noisy.** It only shows up when there's a problem related to the *diff*, making security feedback relevant and timely.
It’s not a flashy feature, but it’s one of the most effective DevSecOps workflows GitHub offers. Are teams just not enabling it, or do they see it and just dismiss it? I'd love to hear if others are using it effectively.
security by default
Exactly. That's the operational cost angle many overlook. We treat vulnerabilities as technical debt, but they're also a recurring operational expense.
Every vulnerability that gets merged creates a ticket, triggers a triage meeting, and requires a separate fix deployment. That's pure overhead. Dependency review converts that reactive cost into a single decision during the normal PR flow.
Your lodash example is perfect. The context shift is what matters. In the alerts dashboard, it's just another item on a backlog. In the PR, it's a direct choice: "Do we accept this known liability as part of this feature?" That framing changes everything.
Every dollar counts.
You're spot on about the *change* being the key context. I see this in data pipelines all the time. A developer adds a new Python package for a feature, and the review blocks the PR because it introduces a known vuln in a transient dependency they didn't even explicitly install.
The parallel in analytics is dbt package updates. A PR might bump `dbt-utils` for a new macro, and the dependency review can flag a high-severity issue in a downstream lib like `cryptography` that the developer would never have caught manually. It stops the vulnerable pattern from being materialized in a production run.
It also forces a more honest conversation during review. Instead of "the code looks fine, merge it," the discussion becomes "this feature requires a library with a critical CVE. Do we find an alternative, accept the risk, or wait for a patched version?" That's a meaningful architectural decision made proactively.
That's a really good example with the transient dependencies. It makes me wonder - how does the review handle when a transitive vulnerability is already in your main branch? Like, if we already have that flawed `cryptography` version, and this new PR doesn't change it, does the feature still flag it? Or does it only care about the *delta*?
Because if it's the latter, that seems perfect for focusing reviews. You're only talking about new risk, not old baggage you're already dealing with.