ci(deps): add dependency-review PR gate#983
Conversation
Benchmark Comparison ReportBaseline: Current: Summary
All benchmark results (sec/op)
Threshold: >10% with p < 0.05 | Generated: 2026-05-29 16:58 UTC |
adb1cdf to
4a6ec39
Compare
4a6ec39 to
7fec149
Compare
|
🤖 Claude Code Review Status: Complete Current Review: This PR adds a solid dependency review workflow as a PR gate. The implementation is secure and follows best practices: Strengths:
One observation: The PR description notes that |
SPDX License Identifier CoverageThe deny list uses deprecated short-form SPDX identifiers: deny-licenses: GPL-2.0, GPL-3.0, AGPL-3.0SPDX deprecated these in favour of explicit variants. A dependency declaring Consider expanding to cover all variants: deny-licenses: >-
GPL-2.0-only, GPL-2.0-or-later,
GPL-3.0-only, GPL-3.0-or-later,
AGPL-3.0-only, AGPL-3.0-or-laterWorth verifying whether |
|
@ordishs verified against v5.0.0 Fixed in |
|
ordishs
left a comment
There was a problem hiding this comment.
Approved.
Verified both action pins by SHA: dependency-review-action is exactly v5.0.0 (latest v5 release), and checkout is v4.3.0 — the same SHA already used in docs-deploy.yml / claude-code-review.yml. Least-privilege permissions, correct use of pull_request (not pull_request_target), and the SPDX deny-list comment documents a real gotcha worth keeping.
Two operational notes (not code changes):
- Add
dependency-reviewas a required status check in branch protection, or it runs without blocking (already called out in the description). - Given the fork-based dev workflow,
comment-summary-in-prwon't post on fork PRs (read-only token capspull-requests: write). The gate still enforces via the check status — results just surface in the Checks tab rather than an inline comment. Correct security tradeoff; worth a line in team docs.



What
Adds one blocking CI gate:
dependency-reviewon every PR. Fails a PR that adds a dependency with a ≥ high-severity CVE or a disallowed licence (GPL-2.0/3.0, AGPL-3.0). Diff-scoped — only the PR's added/changed deps, so it never trips on the existing backlog.Native Dependabot alerts notify on vulnerable deps but don't block merges — this enforces. That's the one gap in teranode's enterprise security stack.
Why just this
teranode's enterprise policy already provides, zero-config:
Evaluated and dropped as redundant / low-value:
/vNmodule paths (validated against this repo's deps).Action needed after merge
Add
dependency-reviewas a required status check in branch protection formain(Settings ▸ Branches) — that's what makes it enforce.Notes
dependency-review-actionpinned by commit SHA. The clean-PR run passes; blocking on a bad dep follows the action's standard behaviour (not exercised in this PR).