Contents
Introduction
The supply chain series established that cooldown is a time-based gate against “newly published malicious versions.” Meanwhile, yarn npm audit catches known CVEs already present in the dependency tree.
There is one more gap between those two — the moment a developer adds a new dependency via a PR. This article covers how GitHub’s dependency-review-action automates validation at that stage.
What Are the Risks?
When a new dependency is added via a PR, any of the following can happen:
1. Introducing a Package with a Known CVE
When a developer runs yarn add some-cool-lib, that library (or one of its transitive dependencies) may already have a high-severity CVE on record. Without a reviewer manually checking the CVE database every time, it gets merged as-is.
2. Installing a Typosquatting Package by Mistake
yarn add react-doom — a typo. Or a malicious package intentionally named to look like a popular one, already sitting on npm, ready to be installed accidentally.
3. Internal Package Spoofing via Dependency Confusion
A fake package with the same name as an internal private package is uploaded to the public registry, tricking the build system into fetching it. Alex Birsan’s 2021 research demonstrated code execution at over 35 companies including Microsoft, Apple, and Uber using exactly this approach.
4. License Violations
Inadvertently introducing a package with a strong copyleft license like GPL or AGPL into a commercial SaaS creates a company-level legal risk. Manual checking is impractical every time.
5. Maintainer Changes
Even the same package can shift in trustworthiness when its maintainer changes and a new version is released. The 2018 event-stream incident established that a new maintainer intentionally inserted malicious code.
Cooldown can only block some of these (malicious new publishes). The rest require automated validation at the PR stage.
Real-World Cases: Typosquatting and Unintended Risk
crossenv vs. cross-env (2017)
The most frequently cited typosquatting case. Installing crossenv (one character off from the legitimate cross-env) executed malicious code that exfiltrated environment variables and system information. (Official analysis)
Packages like this are typically removed from npm relatively quickly after publication. But if they enter via a PR in the meantime, that is all it takes. Adding Dependency Review Action as a PR gate means an alert fires the moment such a package is added to the dependency graph.
Alex Birsan’s Dependency Confusion (2021)
Alex Birsan achieved code execution in build systems at over 35 companies including Microsoft, Apple, and Uber. The method was simple: guess or collect internal private package names from GitHub, then publish packages with those same names on public npm at a higher version number. Build systems would then fetch the public version by default.
The essence of this attack is a package that should not be there being newly added to the dependency graph. Because Dependency Review Action automatically detects changes to the dependency graph in the PR diff, it is the earliest possible detection point for this kind of novel addition.
How Dependency Review Action Works
actions/dependency-review-action computes the difference in the dependency graph between the PR’s base branch and head branch, then runs the following checks against added or changed dependencies:
- Known CVEs (GitHub Advisory Database matching)
- Severity —
low/moderate/high/critical - Licenses (
allow-licenses/deny-licensesallowlist/blocklist) - (Optional) OpenSSF Scorecard score — maintainer activity, code review frequency, etc.
If any change exceeds the configured threshold, the PR fails and a comment is automatically posted explaining which dependency was blocked and why.
How to Apply It
The simplest workflow looks like this:
# .github/workflows/dependency-review.yml
name: Dependency Review
on: pull_request
permissions:
contents: read
pull-requests: write # post results as a PR comment
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<SHA> # v6
- uses: actions/dependency-review-action@<SHA>
with:
fail-on-severity: high
comment-summary-in-pr: alwaysOption reference:
| Option | Description |
|---|---|
fail-on-severity | Fail the PR if a CVE at this level or above is introduced. Options: low / moderate / high / critical |
comment-summary-in-pr | Set to always to post an automatic summary comment on every PR |
allow-licenses / deny-licenses | Allowlist / blocklist of accepted and rejected licenses |
Recommended Starting Configuration
When first getting started, this combination gives the best return on investment:
fail-on-severity: high
comment-summary-in-pr: alwaysGating only on high and above keeps false positives nearly zero. The automated comment gives reviewers an at-a-glance view of the risk level of any new dependencies. Once stable, you can narrow the threshold to moderate incrementally.
Limitations
- Only catches CVEs registered in the GitHub Advisory Database. Zero-days and malicious packages not yet cataloged require cooldown or a behavioral analysis SaaS like Socket to complement this.
- Only inspects the diff of the new PR. Dependencies already present in the tree are not re-evaluated. New CVEs appearing against already-merged dependencies are caught by
yarn npm audit. - Does not work outside GitHub. On GitLab or Bitbucket, alternatives like Snyk PR Checks are needed.
Conclusion
The PR stage is the last human checkpoint in the supply chain defense pipeline. It is not realistic to expect a reviewer to manually assess the risk level of every dependency change on every PR. Dependency Review Action automates that judgment, freeing reviewers from having to separately investigate “does this PR’s new dependency have a known CVE?” for every change.
One workflow file, two options. The setup cost is minimal, and the range of incidents it can prevent is broad. It makes a natural fourth layer after the three strategies in the supply chain defense series.
References
- GitHub Dependency Review Action official repository
- About Dependency Review (GitHub Docs)
- Alex Birsan, “Dependency Confusion”
- crossenv malware on the npm registry (npm official analysis)
Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!
App promotion
Deku.Deku created the applications with Flutter.If you have interested, please try to download them for free.
