{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
SARIF 2.1.0 provides the strongest compatibility; runs, rules, results, locations, suppressions, baseline states, and partial fingerprints are retained where present.
{{ sourceStatus }}
Use a label that will still make sense in a release review or security ticket.
The local release gate is locally defined; SARIF levels remain visible in every evidence artifact.
The neutral default of 500 includes every finding retained by this bounded browser parser.
rows
{{ gateHeading }}

{{ gateSummary }}

  • {{ item }}
PriorityLevelSecurityRuleLocationMessageCopy
{{ row.priority }}{{ row.level }}{{ row.security }}{{ row.rule_id }}{{ row.location }}{{ row.message }}
No result rows are available in this SARIF log.
TypeTargetFindingsMax levelSignalEvidenceCopy
{{ row.type }}{{ row.target }}{{ row.count }}{{ row.max_level }}{{ row.signal }}{{ row.evidence }}
{{ chartError }}

Correct the SARIF input to view the chart.

SBOM Component Risk Analyzer Review SBOM components with a transparent risk score and separate queues for vulnerabilities, licenses, and incomplete package identity.
Container Security Scan Analyzer Normalize container scan reports, apply critical and high release limits, and rank fixable findings for a focused remediation queue.
npm Audit Summary Analyzer Analyze npm audit JSON or terminal output into a severity-weighted release gate and prioritized remediation queue with local processing.
CI Failure Log Analyzer Find actionable clues in a failed CI log, map them to pipeline stages, and mask common secret patterns before sharing the evidence.

Static analysis tools often describe the same kind of code problem in different native formats. The Static Analysis Results Interchange Format (SARIF) gives those scanners a shared JSON structure for runs, rules, findings, locations, messages, suppressions, baseline states, and tracking fingerprints. That common structure makes findings easier to review across branches and scanning products without making the scanners themselves equivalent.

A useful security review separates signal from urgency. SARIF level expresses a result as error, warning, note, or none. Some producers also attach a numeric security severity, a precision estimate, and a baseline state such as new or unchanged. File locations help assign ownership, while fingerprints help follow the same finding after code moves. Missing fields reduce confidence even when the finding count is unchanged.

  • Release gate: a local policy that counts unsuppressed findings at or above a chosen SARIF level.
  • Priority: a triage score that combines level, security severity, precision, baseline state, and suppression.
  • Hotspot: a rule or file with repeated findings that may need shared remediation or ownership.
  • Coverage: the share of findings that contain a physical location or tracking fingerprint.

None of these fields proves exploitability. A high-scoring result may be unreachable in the deployed application, and a low-level result may reveal a serious issue once data flow and business context are understood. Suppression also means a finding has been handled by policy, not that the underlying code is necessarily safe.

SARIF is an interchange record, so its quality depends on the producer. Review scanner identity, rule documentation, scan scope, branch, configuration, and baseline before comparing two logs. A missing run or location can be a reporting problem rather than a clean scan.

How to Use This Tool:

Load one SARIF log, choose the local release boundary, and keep the scan label specific enough for a security handoff.

  1. Paste SARIF JSON or load a SARIF or JSON file, then set Scan label to the scanner, branch, pipeline, or upload represented by the log. Version 2.1.0 provides the strongest compatibility.
  2. Choose Gate fails at. Error only is the narrowest gate; Warning or error and Note, warning, or error count progressively more unsuppressed results.
  3. Read Gate brief for the decision, then inspect the highest-priority rows, repeated hotspots, and location or fingerprint coverage before assigning owners. Increase Finding ledger rows only when more of the priority-sorted list must be visible.

Interpreting Results:

The gate fails when at least one unsuppressed finding has a level equal to or higher than the selected gate level. Suppressed results remain in counts and evidence tables but do not fail the gate. A passing gate therefore means the selected local rule found no blocker, not that the codebase has no vulnerabilities.

  • Start with high priority, a security severity of 7.0 or more, and a new baseline state, then verify the source location and rule guidance.
  • Location coverage below 95% weakens ownership handoff. Fingerprint coverage below 80% weakens cross-commit tracking.
  • A hotspot count shows concentration, not root cause. Several results from one rule may share a fix, or they may be unrelated occurrences that need separate review.

Technical Details:

Each SARIF run can declare rules by identifier or index and then attach results to those declarations. Result fields override or supplement rule defaults where available. Missing or unknown result levels are treated as warnings for triage, while an absent or invalid security-severity value remains unscored.

Formula Core:

The priority score is a local ordering aid. It is rounded to the nearest whole number and cannot fall below zero.

P=max(0,round(L+5S+Q+B−U))

L is the level weight, S is security severity from 0 to 10, Q is the precision weight, B is the baseline adjustment, and U is the suppression penalty. The score ranks rows within this report; it is not part of the SARIF standard or a replacement for scanner severity.

Factor Exact values
Level weight None 1; note 15; warning 35; error 60.
Precision weight Low 1; medium 3; high 6; very high 8; unknown 0.
Baseline adjustment New +10; updated +4; every other state +0.
Suppression penalty 15 points when at least one suppression is present; otherwise 0.

Rule Core:

Result Rule
Gate failure count Count unsuppressed rows whose level rank is greater than or equal to the selected level rank.
Security label Critical at 9.0 to 10.0; high at 7.0 to under 9.0; medium at 4.0 to under 7.0; low above 0 to under 4.0; otherwise unscored.
High-security count Security severity ≥ 7.0, whether suppressed or not.
Coverage Rows with the field divided by all findings, multiplied by 100 and rounded to one decimal place. An empty log reports 100%.

Rule hotspots are ordered by finding count and then rule identifier. File hotspots use the same count-first ordering. Finding rows are ordered by descending priority, descending level, and then rule identifier. The visible finding limit of 5 to 500 rows does not change totals, hotspot groups, coverage, or the gate.

Input must be valid JSON with a non-empty runs array and no more than 5 MiB of text. Up to 500 rule and file hotspot rows are retained. Messages are shortened for the ledger, so the original SARIF log remains the authoritative record for full text and producer-specific properties.

Limitations and Privacy Notes:

SARIF text and loaded files are parsed in the current browser and are not uploaded for analysis.

  • The release gate and priority score are local review rules, not OASIS-defined security ratings.
  • Only the first physical location is used for the compact finding row.
  • Confirm scanner configuration, scan scope, source revision, and rule documentation before comparing logs or accepting a suppression.

Worked Examples:

New high-severity error

An unsuppressed error with security severity 8.8, high precision, and a new baseline receives 120 points: 60 + 44 + 6 + 10. An error-only gate fails on that row. Before blocking the release, verify the location, data flow, rule documentation, and whether the scanned revision is the one being shipped.

References: