fix(ci): rampart-gate.js severity precedence — metadata.rampart must win over raw semgrep severity - #25
Merged
Conversation
…win over raw semgrep severity Custom rampart/ rules are authored with severity: ERROR so semgrep never filters them out, and carry the real business severity in metadata.rampart instead. That metadata must win over the raw semgrep severity — otherwise every custom rule (all severity: ERROR by convention) gets promoted to CRITICAL regardless of its own documented rampart severity. Confirmed real impact via Rampart PR Gate run 28587296865 (2026-07-02, which actually failed): 10 rules.rampart.no-localstorage-token findings (metadata.rampart: HIGH) were force-promoted to CRITICAL. Before fix: critical=14 high=80. After fix: critical=4 high=90 (4 genuine CRITICAL findings still correctly block). Same bug + fix as ummeco/praycalc#58.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
🟢 Rampart Security Gate — CLEAN
Totals: 0 critical · 0 high · 0 medium · 0 low Mode: |
…ule) lhci autorun was crashing with "ReferenceError: module is not defined in ES module scope" because web/package.json sets type:"module", so Node parsed the CommonJS module.exports config as ESM. This job is already continue-on-error (ticket TB9-17/P2-E5, CI services not yet wired) so it wasn't blocking, but the config itself was genuinely broken and worth fixing while touching CI.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug
.github/scripts/rampart-gate.jshas a severity-precedence bug in thesemgreptool branch. Custom rules underrules/rampart/*.ymlare all authored withseverity: ERROR(so semgrep itself never filters them out) and carry the real business severity separately inmetadata.rampart. The old logic let raw semgrep severity win before metadata.rampart was checked:Since every custom rule has
rawSev === 'ERROR', this force-promoted every custom-rule finding to CRITICAL regardless of its documented severity. CRITICAL always blocks the Rampart PR Gate, even in warn mode.Fix
metadata.rampartnow wins outright; raw semgrep severity is only a fallback whenmetadata.rampartis absent (built-in semgrep rules, no rampart metadata).Evidence — real CI artifact
Downloaded
semgrep-report.jsonfrom Rampart PR Gate run 28587296865 (2026-07-02), which actually failed CI. It contains 10 real findings ofrules.rampart.no-localstorage-token(severity: ERROR,metadata.rampart: "HIGH").Ran the exact CI invocation (
node .github/scripts/rampart-gate.js semgrep-report.json --tool semgrep) before and after the fix:The 10
no-localstorage-tokenfindings move from critical to high, exactly matching their documentedmetadata.rampart: "HIGH".Same bug + fix as ummeco/praycalc#58.