How to Read a SARIF Report

SARIF (Static Analysis Results Interchange Format) is the JSON standard that lets different security and code-quality tools produce results in one common shape - which is specifically why GitHub's Security tab can display findings from dozens of unrelated scanners in the same interface. If you've never opened a raw SARIF file, the structure looks more intimidating than it is once you know which four or five fields actually matter.

The Shape of a SARIF File

{
  "version": "2.1.0",
  "runs": [{
    "tool": { "driver": { "name": "Shieldome", "rules": [ /* ... */ ] } },
    "results": [{
      "ruleId": "SQLInjection",
      "level": "error",
      "message": { "text": "SQL injection indicator detected in parameter 'id'" },
      "locations": [{
        "physicalLocation": {
          "artifactLocation": { "uri": "https://yoursite.com/api/users" }
        }
      }]
    }]
  }]
}

One file can contain multiple runs (one per tool, or one per scan), and each run has a results array - one entry per finding. For a web application scanner like Shieldome, artifactLocation.uri holds the actual URL where the issue was found rather than a source file path, which is the main structural difference from SARIF produced by a source-code static analyzer.

The Fields Worth Actually Reading

• ruleId - identifies which specific check fired. Look this up in the tool.driver.rules array for the full description and remediation guidance, not just the short id.
• level - SARIF's own severity scale (error, warning, note, none) - tools map their own severity systems (critical/high/medium/low) onto this smaller set, so two findings both marked error can represent meaningfully different actual severities depending on the tool's own mapping.
• message.text - the human-readable explanation, usually the fastest way to understand what was actually found without cross-referencing the rule definition.
• locations - where it was found. For source-code tools this is a file and line number; for a web scanner, a URL and sometimes a parameter name.
• properties.security-severity - a CVSS-style numeric score (0-10) that GitHub's Security tab uses to sort and color-code findings, when the producing tool includes it.

Where It Actually Shows Up

Uploading a SARIF file via the github/codeql-action/upload-sarif action in a workflow makes those findings appear natively in your repository's Security → Code Scanning tab - alongside CodeQL's own results and anything else your pipeline produces in the same format, all in one triage view instead of separate tool-specific dashboards.

# In a GitHub Actions workflow, after a scan produces results.sarif
- uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: results.sarif
    category: shieldome

Our GitHub Actions integration guide covers the full workflow this fits into, including generating and uploading a real SARIF file from a Shieldome scan.

Common Confusion: Why a Finding "Disappears"

GitHub's Code Scanning UI treats a finding as resolved (and hides it from the default view) once a subsequent scan uploaded under the same category no longer reports that ruleId at that location - not because someone manually dismissed it. If a finding you expect to still be open isn't showing, check whether the underlying issue was actually fixed, or whether the scan that would have re-reported it simply didn't run (a skipped CI job, a scan that failed silently) rather than assuming the tool made a mistake.

Generating SARIF From a Real Scan

Shieldome exports SARIF 2.1 for every scan, ready to upload directly to GitHub's Security tab. Create a free account to generate one from your own site.