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

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

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.