docs: record how dependency alerts are triaged - #5538
Conversation
Both Dependabot auto-triage rules live in the repository's security settings and leave no trace in the source tree, so nothing in the repo explained why some development-scope advisories are dismissed automatically while others stay open. That is the same gap just closed for the frozen Gremlin properties. SECURITY.md now states the principle (triage by where the dependency runs, not by severity alone), lists what each rule covers, and is explicit about what is deliberately NOT auto-dismissed at development scope: path traversal, information disclosure, code injection, and malicious packages. It also points at the E2E audit workflow as the backstop and notes that knowingly carried advisories are recorded in the pom or dependabot config rather than dismissed silently.
|
Tick the box to add this pull request to the merge queue (same as
|
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Coverage variation | ✅ -7.02% coverage variation |
| Diff coverage | ✅ ∅ diff coverage |
Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (5a06925) 146712 109383 74.56% Head commit (31e4e69) 178704 (+31992) 120693 (+11310) 67.54% (-7.02%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>
Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#5538) 0 0 ∅ (not applicable) Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Review: docs: record how dependency alerts are triagedDocumentation-only change (one Markdown file, +44 lines). I focused the review on factual accuracy, since that is the entire value of this section, and on internal consistency with the other in-repo docs it overlaps. Verified against the repo (all correct)
One issue to resolve before mergeThe curated-preset CWE list disagrees with the note already in
Whichever is accurate, they should match, otherwise the next auditor hits exactly the "reads as a bug" confusion this PR is trying to eliminate, just relocated. Please reconcile the two (ideally in this same PR, since it is already the source of truth for this topic) and, if practical, have one point at the other so they cannot drift again. Non-blocking notes
The "Development scope does not mean ignored" paragraph you flagged for attention reads well: it is appropriately narrow (CWE-22, CWE-200, code injection, malicious packages stay in scope) and correctly frames the audit workflow as the runtime-scope backstop. No concerns there. Nice, genuinely useful documentation of an otherwise-invisible constraint. Just the CWE-list reconciliation to sort out. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5538 +/- ##
============================================
- Coverage 65.70% 65.31% -0.39%
+ Complexity 1114 1112 -2
============================================
Files 1748 1748
Lines 146712 146712
Branches 31356 31356
============================================
- Hits 96397 95826 -571
- Misses 37372 37933 +561
- Partials 12943 12953 +10 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
(cherry picked from commit 306125a)
1 participant
What does this PR do?
Adds a How we triage dependency alerts section to
SECURITY.md. One file, 44 added lines, documentation only.It records the triage principle (by where the dependency runs, not by severity alone), what each of the two Dependabot auto-triage rules covers, and - deliberately given equal weight - what is not auto-dismissed.
Motivation
Both auto-triage rules live in the repository's security settings and leave no trace in the source tree. Nothing in the repo explained why one development-scope advisory is dismissed automatically while another, of the same severity against the same package, stays open. Anyone auditing the alert history would have found the pattern inexplicable.
This is the same class of gap just closed in #5536 for the frozen Gremlin properties: a constraint that is real, load-bearing, and invisible to the person who needs it.
The asymmetry is genuinely non-obvious. The GitHub-curated preset dismisses an advisory only when every CWE on it is in the preset's set, so a ReDoS tagged CWE-400 and CWE-407 stays open while the same class of issue tagged CWE-400 alone is dismissed. Without that written down it reads as a bug.
Related issues
Follows the Dependabot hygiene work in #5523, #5534, and #5536. Context for the frozen upstream pins is #5535.
Additional Notes
Reviewer attention is best spent on the "does not mean ignored" paragraph. The section is careful not to read as a blanket exemption for development-scope dependencies. It states explicitly that path traversal (CWE-22), information disclosure (CWE-200), code injection, and malicious or compromised packages are still reviewed at development scope, on the grounds that a build tool able to read or exfiltrate files is a real supply-chain risk whether or not it ships. It also points at
.github/workflows/e2e-dependency-audit.ymlas the backstop that fails on any runtime-scope finding.One dependency on a setting outside this repo. The section describes a custom auto-triage rule for CWE-407 at development scope. If that rule has not been created in Settings -> Advanced Security -> Dependabot -> Auto-triage rules, this PR describes a state that does not exist yet. Either create it before merging, or say so and the custom-rule row plus the paragraph explaining it can be dropped - the rest of the section stands on its own, since the curated preset is demonstrably already active.
Verification:
-consistently with the surrounding text.main:.github/workflows/e2e-dependency-audit.yml,.github/dependabot.yml,gremlin/pom.xml.org.apache.groovy:*majors ignore rule is present in.github/dependabot.yml, and the audit workflow does block onnpm audit --omit=dev --audit-level=high.Checklist
I have run the build using- not applicable and not run. The diff is one Markdown file; no source, no build input.mvn clean packageMy unit tests cover both failure and success scenarios- no unit tests added. Documentation change with no behaviour to test.