What you will put in place
- A browser-local review flow for SARIF 2.1.0 reports.
- A repeatable triage record with scope and ownership.
- A careful comparison of scans without equating disappearance with a fix.
1. Open a report locally
Export SARIF 2.1.0 from your scanner and open the free SARIF viewer linked below. Start with its synthetic demo if you are learning. For your report, record the repository, revision, scanner version, and configuration separately if the export omits them.
The viewer reads selected report files in your browser. Avoid including credentials or customer records in shared exports. It displays report data; it does not execute a scan or determine whether the reported issue is exploitable.
- Open /tools/sarif-viewer and choose a .sarif or JSON file.
- Inspect run and tool information before reading totals.
- Check whether the report includes exclusions, incomplete invocations, or missing locations.
- Keep the original artifact with the scan revision so a reviewer can revisit it.
2. Read one result carefully
Use the rule, message, file, and location to find the corresponding code at the analyzed revision. Inspect any supplied flow or related evidence in the original scanner. A rule identifier describes the check; it does not establish the application’s actual exposure.
SARIF’s error, warning, and note levels are reporting levels. A scanner may provide a separate security score or precision property; neither replaces application-specific review.
| Field | Review question |
|---|---|
| Tool and run | Which scanner, version, configuration, and revision produced this? |
| Rule and message | What behavior does the check report, and what assumptions does it make? |
| Location | Does the path and region match the source at this revision? |
| Level / security severity | Is this a reporting level, or a supplied security score? |
| Fingerprints | Can this tool identify the same result across runs? |
3. Record a decision
Group reports of the same underlying issue while retaining each tool’s evidence. Choose action, further investigation, or dismissal with a rationale. Assign the application owner and a next review date.
Finding / rule: ____________________
Repository + analyzed commit: ______
Evidence reviewed: ________________
Impact and remaining assumptions: __
Decision + reason: ________________
Owner / next action / review date: _
Fix commit + verification evidence: _Keep secrets and personal data out of the record. Link to access-controlled evidence when needed.
4. Compare the next run
Load a second export in the viewer and inspect candidate matches. Fingerprints, rule identifiers, and file paths help track reports, but a changed rule pack or excluded file can change the result list. Different tools use different rules and evidence; raw counts are not a precision benchmark.
When a result disappears, check scan success, coverage, and the remediation commit before calling it fixed. When a result is newly reported, check whether it reflects a new code change or a changed scanner configuration.
- For the same tool, keep the analyzed scope and configuration comparable.
- For different tools, review overlap manually and use the same acceptance criteria.
- Use the downloadable pilot scorecard to track accepted unique findings and reviewer time.
- Preserve unknown and incomplete outcomes in the final readout.
References and approach
This guide combines the referenced security guidance with Winfunc’s practical planning recommendations. The examples are starting points to adapt to your application, release process, and risk owners.