Skip to content

feat(sarif): emit GitHub security-severity so Code Scanning ranks findings by severity#33

Open
dmchaledev wants to merge 1 commit into
mainfrom
claude/amazing-franklin-tdbnul
Open

feat(sarif): emit GitHub security-severity so Code Scanning ranks findings by severity#33
dmchaledev wants to merge 1 commit into
mainfrom
claude/amazing-franklin-tdbnul

Conversation

@dmchaledev

Copy link
Copy Markdown
Contributor

Summary

The headline SARIF feature — "Output SARIF for GitHub Code Scanning" (README) — emits results without the security-severity property that GitHub uses to rank alerts. As a result, every finding collapses to its SARIF level: a CRITICAL NO_AUTH and a HIGH OVERPRIVILEGED_TOOL both serialize as level: "error" and become indistinguishable in the GitHub Security tab. The scanner computes a rich five-level severity model, but none of that severity signal survives into Code Scanning.

GitHub's SARIF support docs state that the Critical/High/Medium/Low badge — and severity-based alert filtering / branch-protection thresholds (e.g. "block merge on critical alerts") — are driven by a numeric security-severity string (0.010.0) in each rule's properties bag, not by the SARIF level. Without it, a "fail on critical" workflow on the GitHub side has nothing to target.

The change

src/sarif.ts: map each Severity to GitHub's documented bands and emit it on every SARIF rule.

Severity security-severity GitHub band
CRITICAL 9.0 >= 9.0 → critical
HIGH 8.0 7.0–8.9 → high
MEDIUM 5.0 4.0–6.9 → medium
LOW 2.0 < 4.0 → low
INFO 0.0

Verified against the built CLI on examples/vulnerable-config.json:

NO_AUTH                    9.0
TOOL_DESC_INJECTION        8.0
UNSAFE_TOOL_OUTPUT_PATH    9.0
WILDCARD_CORS              5.0
VERBOSE_ERRORS             2.0
OVERPRIVILEGED_TOOL        8.0
INSECURE_TRANSPORT         8.0
MISSING_RATE_LIMIT         5.0
DEBUG_MODE_ENABLED         2.0
UNRESTRICTED_FILE_ACCESS   2.0

Scope & safety

  • Localized to src/sarif.ts (one new mapping function + one field on SarifRule); no behavior change to scanning, scoring, or the JSON/table outputs.
  • Additive and backward-compatible: properties is an optional field; existing SARIF consumers ignore unknown properties.
  • npx tsc --noEmit, npm run lint, and npm test all green (120 tests, +2 new covering the property and the full severity→score mapping).

Acceptance criteria

  • Each SARIF rule carries properties["security-severity"].
  • Score follows GitHub's documented bands (critical/high/medium/low).
  • No change to JSON/table output or to findings/scoring.
  • Tests cover the new property and mapping.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DQNF4ehRBdHf8AJxj5vvao


Generated by Claude Code

GitHub Code Scanning reads the `security-severity` property from each
rule's `properties` bag to assign the Critical/High/Medium/Low badge in
the Security tab and to drive severity-based alert filtering and
branch-protection rules. Without it, GitHub can only rank by SARIF
`level`, so CRITICAL and HIGH findings (both `error`) are
indistinguishable and severity gates can't target them — undermining the
headline "Output SARIF for GitHub Code Scanning" feature.

Map each Severity to GitHub's documented bands (9.0+ critical, 7.0-8.9
high, 4.0-6.9 medium, <4.0 low) and emit it on every SARIF rule. Adds
unit tests covering the property and the full severity-to-score mapping.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DQNF4ehRBdHf8AJxj5vvao
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants