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.

Drop .sarif or .json onto the textarea.

Local parse only; no source code, paths, or findings leave the browser.

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 results are present in this log.

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 were found.

File	Findings	Error	Warning	Note	Top rules	Copy
{{ row.file }}	{{ row.count }}	{{ row.error }}	{{ row.warning }}	{{ row.note }}	{{ row.topRules }}
No file paths were found in result locations.

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

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Static-analysis reports often arrive as dense SARIF logs just when a team needs a quick release or pull-request decision. SARIF, the Static Analysis Results Interchange Format, can carry scanner runs, rules, result levels, source locations, messages, fingerprints, suppressions, and security scoring hints in one JSON document. That richness helps tools exchange findings, but it can slow down a reviewer who only needs to know which alerts block a gate and where the first remediation pass should start.

Security triage works best when the raw findings stay tied to their evidence. A result level such as error, warning, or note says how the analyzer classified the alert. A rule identifier tells reviewers which detector fired. A physical location gives the file and line that can be assigned. Security severity, precision, baseline state, and fingerprints add context that can separate a new high-confidence security alert from a noisy legacy warning.

Flow diagram from SARIF runs, rules, and results into normalized findings, gate status, and triage views

A SARIF summary should not be read as proof that a project is secure or that every alert is exploitable. It is a review brief for a report that already exists. The decision still needs code ownership, scanner configuration, rule documentation, runtime exposure, and the team's policy for accepted risk or suppressions.

The most useful first pass answers three questions: how many unsuppressed findings meet the chosen gate level, which rules and files concentrate the work, and whether the log includes enough locations and fingerprints to let reviewers follow alerts across changes.

Technical Details:

SARIF 2.1.0 organizes static-analysis output into runs. Each run names the analyzer and can include a rule catalog plus a results array. A result normally points back to a rule, carries a level, stores a message, and may include one or more physical locations. For code-review triage, the first physical location is usually the assignable file and line, while the rule identifier and message explain what detector produced the alert.

Result levels and security severity describe different things. The SARIF level is the analyzer's alert level: error, warning, note, or none. Security severity is a numeric rule or result property used by some security scanners to rank security alerts. Precision describes how often the rule is expected to be true. Baseline state separates new and updated results from unchanged results, and fingerprints make it easier to recognize the same alert after nearby code changes.

Rule Core

The release gate counts unsuppressed findings whose normalized level is at least the selected gate level. The available gate choices are error, warning, and note. Results with unknown or missing levels are treated as warning unless the linked rule supplies a default level.

SARIF gate level rules
Gate setting	Included unsuppressed result levels	Typical use
`Error only`	`error`	Strict release blocking for findings the analyzer marks as errors.
`Warning or error`	`warning`, `error`	Security review where warning-level alerts should stop a merge until triaged.
`Note, warning, or error`	`note`, `warning`, `error`	Backlog grooming or strict policies that count every reported level except `none`.

Security severity is shown as a readable band when the SARIF data provides a numeric score. The displayed band follows the same ranges used by common code-scanning workflows.

Security severity score bands
Displayed security label	Score boundary	Review meaning
Critical	> 9 and <= 10	Handle before lower-scored findings when the rule is relevant to the reviewed code.
High	>= 7 and <= 8.9	Prioritize in security triage, especially when the result is new and high precision.
Medium	>= 4 and <= 6.9	Keep visible for scheduled remediation and owner assignment.
Low	> 0 and <= 3.9	Review when the affected file, rule, or baseline state makes it important.
Unscored	Missing, zero, or outside the displayed ranges	Use level, precision, baseline state, rule context, and message text instead.

Priority is a queue score, not a vulnerability standard. It raises severe, high-security, high-precision, and new findings, then lowers suppressed findings so a reviewer sees likely release work first.

priority = level base + 5 \times security score + precision bonus + baseline bonus - suppression penalty

Priority score components
Component	Values used	Effect on sorting
Level base	`error` 60, `warning` 35, `note` 15, `none` 1	Higher SARIF levels rise ahead of lower levels.
Security score	Numeric `security-severity`, multiplied by 5	Security-scored rules move up within the same result level.
Precision bonus	`low` 1, `medium` 3, `high` 6, `very-high` 8	Higher-confidence rules receive a small lift.
Baseline bonus	`new` 10, `updated` 4	Recent regressions appear before unchanged backlog rows.
Suppression penalty	15 when a result has suppressions	Suppressed rows remain visible but are less likely to lead the queue.

A useful SARIF log needs more than counts. Relative or stable file paths help a code host annotate the right source file. Fingerprints help match alerts across scans. Baseline state helps reviewers distinguish new work from existing debt. Missing fields do not make the log useless, but they reduce confidence in routing, comparison, and release evidence.

Everyday Use & Decision Guide:

Start with a short Scan name that matches the CI job, branch, analyzer, or upload category. That label appears in copied and downloaded evidence, so CodeQL main branch or semgrep pull request 184 is more useful than a generic project name.

Use Gate fails at to mirror the policy being checked. Error only is a narrow release gate. Warning or error fits teams that treat warning-level security alerts as merge blockers. Note, warning, or error is better for full backlog review because it counts nearly every reported level.

Paste SARIF JSON into SARIF JSON, browse for a .sarif or .json file, or load the sample when testing the page. The parser reads one SARIF log with runs, rules, results, levels, locations, baseline states, and rule properties. Files over 5 MiB are rejected before loading, and invalid JSON shows a parse error instead of a partial result.

Finding Ledger is the main row list. It sorts findings by priority and shows level, security label, rule, location, and message.
Rule Hotspots groups repeated findings by rule and shows count, max level, security label, precision, and a representative message.
File Hotspots groups findings by file so ownership routing can begin with the busiest paths.
Triage Brief turns format, gate, security scoring, baseline state, rule concentration, location coverage, and fingerprint coverage into review signals.
SARIF Severity Mix and Rule Hotspot Ranking provide quick chart views for severity distribution and repeated rules.

Set Finding ledger row limit lower for a screenshot or higher for a handoff export. Aggregate counts and charts still use the full parsed result set, so changing the visible row limit does not change the gate status, rule totals, file totals, or chart counts.

A gate passes badge means no unsuppressed finding met the selected level threshold. It does not mean the code is safe, the findings are false positives, or the scanner covered the whole repository. Before attaching evidence to a release, compare the top Finding Ledger rows with Triage Brief signals for version, location coverage, fingerprint coverage, and new baseline results.

Step-by-Step Guide:

Work from the source log to the gate summary before exporting any evidence.

Enter a clear label in Scan name. Confirm the summary line later uses that label with the parsed error, warning, and note counts.
Choose Gate fails at. Use Error only for a narrow gate, Warning or error for normal security blocking, or Note, warning, or error for strict review.
Paste the SARIF text into SARIF JSON, drop a .sarif or .json file onto the field, or use Browse SARIF. The status badge should change from a character count to findings and runs after parsing succeeds.
Use Format JSON when the input is valid but hard to inspect. If the page reports SARIF JSON parse failed, fix the JSON before reading any summary.
Open Finding Ledger and review the highest priority rows first. Copy a row when a ticket needs the exact priority, level, security label, rule, location, and message.
Check Rule Hotspots and File Hotspots before assigning work. Repeated rules may be fixed in one pattern change, while repeated file paths may need an owner-specific review.
Use Triage Brief to verify SARIF version, release gate status, high or critical security scoring, new baseline results, location coverage, and fingerprint coverage.

Finish by checking the summary badges and the first few Finding Ledger rows against the policy you intend to enforce.

Interpreting Results:

The first result to trust is the gate badge. Gate fails means at least one unsuppressed finding is at or above the selected gate level. Gate passes means that specific threshold is clear, not that lower-level findings are harmless or that the scan found every issue.

Priority is best used as a review order. An error-level result with a high security score, high precision, and new baseline state should usually be read before an unchanged note. A suppressed result can still appear, so confirm the suppression reason in the originating scanner or repository process before closing it.

Security labels come from numeric SARIF properties. Unscored does not mean safe; it means no usable security score was available for that row.
Location coverage shows whether findings include physical locations. Low coverage makes owner routing and pull-request annotation weaker.
Fingerprint coverage shows whether alerts include stable identifiers. Weak coverage can lead to duplicate or hard-to-compare alerts across scans.
New baseline rows deserve a closer look because they represent new or changed findings rather than standing backlog.

High security severity does not prove exploitability, and a passing gate does not replace code review. Use the brief to decide where to look first, then verify rule documentation, data flow, reachable code, suppressions, and ownership before treating the scan as resolved.

Worked Examples:

Pull request with one new error

A CodeQL SARIF log for CodeQL main branch contains one error result for js/sql-injection, two warning results, and locations in src/routes/search.js and related files. With Gate fails at set to Error only, the summary shows 1 gate findings and the badge says gate fails. Finding Ledger places the SQL injection row first because its level, security score, precision, and new baseline state all raise its priority.

Warning policy for a security review

A Semgrep report has zero errors but five warnings, including two warnings with high security scores and physical locations under src/auth/. With Gate fails at set to Warning or error, all five unsuppressed warning rows count against the gate. Rule Hotspots shows whether one rule caused most of the rows, and File Hotspots helps route the review to the owner of src/auth/.

Backlog review with weak fingerprints

A nightly SARIF log has 300 note and warning findings but only 40 percent fingerprint coverage. The gate may pass when Error only is selected, but Triage Brief marks fingerprint coverage as weak. That result is still useful for a one-time cleanup list, but it is poor evidence for comparing whether the same alerts persist across future commits.

Invalid or incomplete SARIF

A copied report is missing its closing brace, so the input field reports SARIF JSON parse failed and no result tabs should be trusted. After the JSON is fixed, a second error says no runs[] array was found. Restore the complete SARIF log from the scanner output, then confirm the source badge shows findings and runs before reading Finding Ledger.

FAQ:

Does this run a new security scan?

No. It analyzes SARIF JSON that you paste or load. It does not inspect source code, run a scanner, query a code host, or update rule data.

Which SARIF version works best?

The brief treats version 2.1.0 as ready. Other versions can still parse when the expected runs and results structures are present, but Triage Brief marks the version for review.

Why did a warning fail the gate?

Check Gate fails at. When it is set to Warning or error, every unsuppressed warning and error result counts as a gate finding.

Why is a row marked unscored?

The SARIF rule or result did not provide a usable security-severity score in the displayed ranges. Read the row with its level, precision, baseline state, rule ID, location, and message.

What should I do when the JSON does not parse?

Restore the complete SARIF text from the scanner artifact, then use Format JSON after the parse succeeds. If the next error says no runs[] array was found, the pasted JSON is not a SARIF log.

Is pasted SARIF sent for server-side parsing?

No. Parsing is performed in the browser, and the page text states that source code, paths, and findings do not leave the browser. Handle sensitive scan reports according to your organization's workstation and data-sharing rules.

Glossary:

SARIF: A JSON-based format for exchanging static-analysis results between scanners, code hosts, and review tools.
Result level: The SARIF alert level, such as error, warning, note, or none.
Security severity: A numeric SARIF property used by some security rules to express security impact from low through critical.
Precision: A rule property that describes how often findings from the rule are expected to be true.
Baseline state: A SARIF result value such as new, updated, or unchanged that helps separate regressions from standing findings.
Fingerprint: A stable result identifier that helps match the same alert across scans and code changes.
Suppression: A SARIF marker that indicates a result has been suppressed or accepted by another process.

References:

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