Skip to content
BreachVex
guides··4 min read

SARIF Explained: How to Integrate Pentest Results into Your CI/CD Pipeline

SARIF (Static Analysis Results Interchange Format) is an OASIS standard that lets any security tool output findings in a format that GitHub, Azure DevOps, and other CI platforms can natively consume. BreachVex exports SARIF 2.1.0. A single upload-sarif step in your GitHub Actions workflow turns pentest findings into Code Scanning alerts.

What SARIF Is

SARIF (Static Analysis Results Interchange Format) is an OASIS standard — currently at version 2.1.0 — that defines a JSON schema for security and analysis tool output. Its purpose is interoperability: a team running five different security tools should not need five different parsers.

Before SARIF, every security tool had its own output format. Integrating a new scanner into your pipeline meant writing a custom parser, normalizing severity levels across different scales, and building custom dashboards. SARIF solves this at the format level.

The major CI/CD platforms support SARIF to varying degrees. GitHub Code Scanning consumes SARIF natively and renders findings as inline annotations on pull requests, tracking open and resolved issues across commits. Azure DevOps supports SARIF through the SARIF SAST Scans Tab extension. GitLab Ultimate's Vulnerability Reports accept SARIF imports as well, with some caveats around field mapping.

SARIF Structure

A SARIF file is a JSON document with a defined schema. The top-level structure:

{
  "$schema": "https://www.schemastore.org/sarif-2.1.0.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "BreachVex",
          "version": "1.0.0",
          "rules": [
            {
              "id": "BV-IDOR-001",
              "name": "InsecureDirectObjectReference",
              "shortDescription": {
                "text": "Broken Object Level Authorization"
              },
              "helpUri": "https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/",
              "properties": {
                "tags": ["security", "owasp-api-top-10"]
              }
            }
          ]
        }
      },
      "results": [
        {
          "ruleId": "BV-IDOR-001",
          "level": "error",
          "message": {
            "text": "IDOR on /api/users/{id}: User A's token retrieved User B's profile data."
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "https://app.example.com/api/users/8472"
                }
              }
            }
          ],
          "fingerprints": {
            "primaryLocationLineHash/v1": "a1b2c3d4e5f6"
          }
        }
      ]
    }
  ]
}

Key fields:

  • tool.driver.rules — defines the rule catalog, referenced by ruleId in each finding
  • results[].level — error, warning, or note (maps to Critical/High, Medium, Low in most platforms)
  • results[].fingerprints — enables deduplication across runs; findings with matching fingerprints are treated as the same issue
  • locations — for DAST and pentest tools this is a URI rather than a source file line

GitHub Code Scanning Integration

Once you have a SARIF file, integration into GitHub takes three lines of GitHub Actions YAML:

- name: Upload pentest results to GitHub Code Scanning
  uses: github/codeql-action/upload-sarif@v4
  with:
    sarif_file: results/breachvex-results.sarif
    category: pentest

SARIF uploads require the security-events: write permission on the GitHub Actions token. Add the following block to your workflow job:

permissions:
  security-events: write

After upload, findings appear in the repository's Security > Code Scanning tab. They are linked to the commit SHA, so you can track when an issue was introduced and when it was resolved. Pull request checks fail if new error-level findings are introduced.

How BreachVex Exports SARIF

Every BreachVex scan produces a SARIF 2.1.0 export alongside the PDF and JSON reports. The SARIF output includes:

  • One rule entry per vulnerability class detected (IDOR, SQLi, XSS, SSRF, SSTI, and others)
  • Result-level CVSS score in properties — computed the same way as our free CVSS v4.0 calculator, so you can audit any finding's severity by hand
  • The full proof-of-exploit HTTP request and response as relatedLocations
  • Fingerprint hashes for deduplication across scan runs
  • CWE identifiers and OWASP category tags for toolchain filtering

The fingerprinting logic means that if a vulnerability is present in scan run N and still present in run N+1, GitHub Code Scanning treats it as the same open issue rather than creating a duplicate alert.

Why Standardized Format Matters

The practical value of SARIF is not the format itself — it is what the format enables. When all your security tools speak the same language, you can:

  • Aggregate findings from SAST, DAST, and pentest tools in a single dashboard without custom glue code
  • Track remediation over time using the platform's built-in issue management (alert states: open, dismissed, fixed)
  • Gate pull requests on new error-level findings across all tools in one security-events check
  • Export findings to JIRA or Linear using the platform's webhook integration rather than building a custom connector per tool

For teams running multiple security tools across multiple repositories, SARIF eliminates the integration tax that otherwise falls on the security engineering team.