SARIF Security Findings Analyzer

SARIF Security Triage

Scan name:

Use the analyzer, pipeline, branch, or upload category you want to see in exports.

Gate fails at:

Choose the SARIF result level that should count as a release-blocking finding.

SARIF JSON:

Paste one SARIF log with runs, rules, results, levels, locations, baseline states, and rule properties.

{{ sourceMeta }}. Drop .sarif or .json onto the textarea; parsing stays browser-side.

Finding ledger row limit:

Use a compact value for screenshots or a larger value for handoff exports.

rows

Priority	Level	Security	Rule	Location	Message	Copy
{{ row.priority }}	{{ row.level }}	{{ row.securityLabel }}	{{ row.ruleId }}	{{ row.location }}	{{ row.message }}
No SARIF findings found This log parsed successfully, but its runs do not contain result entries for the finding ledger.

Rule	Count	Max level	Security	Precision	Top message	Copy
{{ row.ruleId }}	{{ row.count }}	{{ row.maxLevel }}	{{ row.securityLabel }}	{{ row.precision \|\| 'n/a' }}	{{ row.message }}
No rule hotspots available Add SARIF result rows with rule identifiers to populate the hotspot ledger.

File	Findings	Error	Warning	Note	Top rules	Copy
{{ row.file }}	{{ row.count }}	{{ row.error }}	{{ row.warning }}	{{ row.note }}	{{ row.topRules }}
No file hotspots available The parsed findings do not expose physical file locations for ownership routing.

Signal	Status	Evidence	Next action	Copy
{{ row.signal }}	{{ row.status }}	{{ row.evidence }}	{{ row.action }}

No severity mix to chart

Add SARIF results with levels to populate the severity mix chart.

No rule ranking to chart

Add SARIF results with rule identifiers to populate the hotspot ranking chart.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Static analysis results are easier to review when scanners speak the same format. SARIF gives code-scanning, linting, dependency, and infrastructure tools a common JSON structure for runs, rules, results, locations, messages, levels, suppressions, baseline state, and tracking clues. That common shape lets a security review compare findings without treating every scanner export as a separate reporting language.

The useful question is not only how many findings exist. A release review needs to know which findings are new, which ones are suppressed, which rules repeat, which files concentrate work, and whether the log includes enough location and fingerprint data to compare one scan with the next. A noisy legacy backlog can look worse than a small number of fresh blockers when the report is read as a flat count.

Run: One execution of a scanner or scanner category, usually tied to a branch, language, product area, or CI job.
Rule: The check that detected the problem, including stable identifiers and optional metadata such as precision and security severity.
Result: One reported alert from a rule, with a level, message, source location, baseline state, suppressions, and optional fingerprints.
Fingerprint: A stable identity clue that helps systems recognize the same alert after files move or lines change.

SARIF triage works best when level, security severity, precision, and baseline state are read together. A new warning with high security severity and high precision can deserve faster review than an unchanged note. A suppressed error should not fail a gate if the suppression is still intentional, but it still belongs in the record because suppressions can become stale after code, rule, or policy changes.

A SARIF log is scanner evidence, not proof of exploitability. Rule documentation, source review, reachable attack paths, business context, and accepted-risk policy decide whether a finding is fixed, suppressed, deferred, or closed as a false positive.

How to Use This Tool:

Analyze one SARIF log at a time so the gate count, hotspots, and exported rows stay tied to the scan name you enter.

Enter a Scan name such as the scanner, branch, language group, or release job being reviewed.
Paste SARIF JSON into SARIF JSON, drop a .sarif or .json file onto the textarea, or use Browse SARIF. Files over 5 MiB are rejected before parsing.
Choose Gate fails at: Error only, Warning or error, or Note, warning, or error. This changes the release-gate count without hiding lower-priority findings.
Use Format JSON if pasted content is hard to read. If parsing fails, the status message names the JSON error or says when no runs array was found.
Set Finding ledger row limit when you need a shorter visible ledger. Aggregate counts, hotspots, charts, and the Triage Brief still use the full parsed result set.
Read Triage Brief for SARIF version, release gate, security scoring, baseline state, rule concentration, location coverage, and fingerprint coverage before assigning work.
Use Finding Ledger for row-by-row review, Rule Hotspots for repeated rules, File Hotspots for owner routing, and the chart tabs for severity mix and top rule ranking.

A valid SARIF log with runs but no result entries will parse, but the Finding Ledger and hotspot views will be empty until the scanner emits result objects.

Interpreting Results:

The release gate counts unsuppressed findings whose normalized level is at or above the selected gate. A failing gate means the log violates that selected policy threshold. It does not prove that every row is exploitable, and it does not prove that every suppressed row is still safe to ignore.

SARIF analyzer views and interpretation cues
View or signal	What matters first	Check before acting
Finding Ledger	Priority, Level, Security, Rule, Location, and Message.	Open the scanner rule and source location before assigning a fix.
Rule Hotspots	Rules with the highest counts, strongest levels, security scores, and precision labels.	Decide whether repeated rows share one code pattern or several unrelated causes.
File Hotspots	Files with concentrated error, warning, note, and none counts.	Confirm location coverage before routing work to file owners.
Triage Brief	Gate status, new baseline rows, location coverage, and fingerprint coverage.	Fix weak scan output before using the report for trend comparison.
SARIF Severity Mix	The balance of error, warning, note, and none result levels.	Compare only scans with similar rule sets and scanner configuration.

High priority usually reflects a strong result level, a higher security score, better precision, and a new or updated baseline state. Low fingerprint coverage can create false confidence because the same alert may be harder to match across commits, branches, or refactors.

Technical Details:

SARIF separates scanner metadata from individual findings. Rule metadata can declare a default level, precision, tags, and security severity, while each result can override the level, attach a message, point to physical locations, declare a baseline state, include suppressions, and provide fingerprints. That split matters because two results may reference the same rule but land in different files, carry different baseline states, or have different suppression histories.

Normalization turns every result into a comparable triage row. Missing result levels fall back to the linked rule default, then to warning when neither field exists. The first physical location is used for file routing. Rule and file hotspots are grouped after normalization so repeated findings can be reviewed as patterns instead of isolated rows.

Formula Core

The priority score combines level weight, security severity, precision, baseline state, and suppression status. Scores are clipped at zero so suppressed low-signal rows do not become negative.

priority = \max (0, L_{w} + 5 \times S_{score} + P_{w} + B_{w} - U_{w})

Lw is the result-level weight, Sscore is the numeric security severity, Pw is the precision weight, Bw is the baseline boost, and Uw is the suppression penalty.

SARIF priority score mappings
Signal	Mapping	Effect on triage
Level	`error` 60, `warning` 35, `note` 15, `none` 1.	Primary queue order and gate eligibility.
Security severity	Numeric score multiplied by 5.	Moves security-significant findings ahead of generic quality findings.
Precision	`very-high` 8, `high` 6, `medium` 3, `low` 1.	Raises findings that are expected to be more actionable.
Baseline state	`new` adds 10, `updated` adds 4, other states add 0.	Highlights regressions and changed findings before stable backlog.
Suppression	Any suppression subtracts 15.	Keeps accepted or muted findings lower and out of gate-failure counts.

Gate and Severity Rules

The gate rule uses an ordered level scale. A finding fails only when it is not suppressed and its level rank is greater than or equal to the selected gate rank.

gate failure = not suppressed \land {level}_{rank} \geq {gate}_{rank}

SARIF security severity buckets and coverage checks
Rule or check	Boundary	Interpretation
Critical security	`> 9.0` to `10.0`	Highest security-severity findings should be reviewed before lower-scored rows.
High security	`7.0` to `8.9`	Often release-sensitive when paired with an error or warning level.
Medium security	`4.0` to `6.9`	Useful for backlog order and owner review.
Low security	`0.1` to `3.9`	Usually lower queue priority unless the rule repeats widely.
Unscored	`0`, missing, or outside range	Do not assume low risk; check the rule and scanner documentation.
Location coverage	`>= 95%` is Complete	Lower coverage weakens file-owner routing.
Fingerprint coverage	`>= 80%` is Trackable	Lower coverage weakens baseline and duplicate-alert comparison.

The result is a deterministic reading of the SARIF fields in the pasted or selected log. It does not validate scanner correctness, inspect source code, prove reachability, or decide accepted-risk policy.

Limitations and Privacy Notes:

SARIF findings can contain source paths, code snippets, branch identifiers, and internal rule names. Treat the report as security-sensitive even when it is only scanner output.

Pasted and selected SARIF content is parsed in the browser; the analyzer does not need repository source code to create its tables and charts.
The parser reads one log at a time and rejects files larger than 5 MiB, so very large scans should be trimmed or split before review.
Only the first physical location is used for file routing, even when a SARIF result contains more related locations or code flows.
Gate status depends on the selected level threshold and suppressions. It is a release-policy signal, not a vulnerability confirmation.

Worked Examples:

Pull-request blocker

A CodeQL scan has two unsuppressed error results, six warnings, and Gate fails at set to Error only. Summary shows 2 gate findings, Triage Brief marks Release gate as Fails, and Finding Ledger should be read from the highest Priority rows before the merge decision.

Legacy backlog review

A branch report has 18 findings, but Triage Brief shows 0 new baseline results and 18 unchanged results. The gate may still fail under Warning or error, but Rule Hotspots is the better starting view for reducing repeated rule patterns.

Weak scan output

A log parses with Location coverage at 62.5% and Fingerprint coverage at 40.0%. File Hotspots may not route all work correctly, and trend comparison should wait until the scanner emits more complete locations and fingerprints.

FAQ:

Does a failing gate mean the release is unsafe?

No. It means the SARIF log contains unsuppressed findings at or above the selected Gate fails at level. Review the rule, source location, exploitability, and suppression history before making a security decision.

Why do suppressed findings still appear?

Suppressed findings stay visible for context and exports, but they do not count as gate failures. Recheck them when scanner rules, code paths, or accepted-risk dates change.

Why is my SARIF file rejected before parsing?

The browser reader rejects files over 5 MiB. For larger scans, export a smaller SARIF sample, split by language or scanner category, or review the raw report in the producing platform first.

What does weak fingerprint coverage mean?

Fingerprints help match the same alert across commits and branches. When Triage Brief marks Fingerprint coverage as Weak, deduplication and baseline comparison may be less reliable.

Why did a valid SARIF log show no findings?

The log may contain a valid runs array but no result entries. Check that the scanner emitted results and that you pasted the SARIF log rather than a summary wrapper.

Glossary:

SARIF: Static Analysis Results Interchange Format, a JSON format for static-analysis runs, rules, and results.
Result level: The finding level used for gate checks, usually error, warning, note, or none.
Security severity: A numeric rule score used to group security findings into critical, high, medium, low, or unscored buckets.
Baseline state: A result label that helps separate new, updated, unchanged, and other findings between scans.
Suppression: A SARIF marker showing that a finding has been muted or accepted for a stated reason.
Fingerprint: A stable identity clue used to compare the same finding across revisions.

References:

Static Analysis Results Interchange Format (SARIF) Version 2.1.0, OASIS Open, 23 July 2019.
SARIF support for code scanning, GitHub Docs.