Coder Legion - Recent posts tagged sarif

What Is SARIF and How Does It Help Security Tools Work Together?

Sat, 04 Jul 2026 16:06:30 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

If you've ever worked with tools like Semgrep, Trivy, Checkov, Gitleaks, or CodeQL, you've probably noticed that each tool produces results in a different format. Some output JSON, some use XML, while others generate plain text reports.

This creates a problem: how do you aggregate multiple tools results from multiple tools into a single platform?

That's where SARIF comes in.

What is SARIF?

SARIF stands for Static Analysis Results Interchange Format.

It is an open standard designed to represent findings from static analysis tools, security scanners, linters, and code quality tools in a common format.

Think of SARIF as a universal translator.

Instead of every tool speaking its own language:

Semgrep -> Semgrep JSON
Trivy -> Trivy JSON
Checkov -> Checkov JSON
Gitleaks -> Gitleaks JSON

SARIF allows all of them to communicate using a shared structure:

Semgrep
Trivy
Checkov
Gitleaks
    ↓
   SARIF

Why Was SARIF Created?

Imagine a company running 20 different scanners in its CI/CD pipeline.

Each scanner reports:

Different severity levels
Different file formats
Different metadata
Different output structures
Different CVE
Different CVSS scores

Building integrations for every tool becomes difficult and expensive.

SARIF solves this problem by providing a standardized schema for:

Rule IDs
Messages
Severity
File locations
Code snippets
Security metadata
Fix suggestions

This allows platforms to consume results from many tools without writing custom integrations for each one.

A Simple Example

Suppose a security scanner finds a vulnerability:

File: app.py
Line: 42
Severity: High
Message: Possible SQL Injection

In SARIF, that information becomes structured JSON that any compatible platform can understand.

The scanner changes, but the format remains the same.

How SARIF Helps Developers

One Format for Many Tools

Instead of handling dozens of output formats:

Tool A -> Format A
Tool B -> Format B
Tool C -> Format C

you can standardize on:

Tool A
Tool B
Tool C
   ↓
 SARIF

Better Tool Interoperability

A SARIF file generated by one tool can be consumed by another platform without modification.

This makes integrations significantly easier.

GitHub Code Scanning Support

One of the biggest reasons SARIF became popular is GitHub Code Scanning.

GitHub accepts SARIF uploads and automatically displays:

Security findings
Code quality issues
Vulnerabilities
File-level annotations

directly inside pull requests and repositories.

Easier Aggregation

Organizations often run multiple scanners:

Semgrep
Trivy
Checkov
Gitleaks
Bandit

SARIF makes it possible to combine all findings into a single report.

Conclusion

SARIF is a common language that allows tools to exchange findings in a standard way.

As the number of security and code analysis tools continues to grow, standards like SARIF help reduce integration complexity and make tool ecosystems work together more effectively.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

Running OpenAPI Validation in GitHub Actions and Showing Findings in Pull Requests

Sat, 04 Jul 2026 00:49:15 +0000

In a previous article, I explained what SARIF is and why many security and quality tools use it as a common reporting format.

In this article, we'll focus on a practical example: validating an OpenAPI specification in GitHub Actions and displaying findings directly inside GitHub Pull Requests.

By the end, you'll have a workflow that:

Lints your OpenAPI specification
Generates a SARIF report
Uploads results to GitHub Code Scanning
Shows annotations directly in Pull Requests

Sample OpenAPI Specification

Let's start with a simple OpenAPI file that contains a deliberate issue.

openapi: 3.0.3

info:
  title: User API
  version: 1.0.0

paths:
  /users/{id}:
    get:
      operationId: getUserById

      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: string

      responses:
        "200":
          description: User found

Notice that the path is:

/users/{id}

but the parameter is named:

userId

The parameter name should match the path placeholder (id).

We'll use this mistake to verify that our workflow correctly reports findings.

Installing Spectral

For this example, we'll use Spectral, one of the most popular OpenAPI linting tools.

npm install -g @stoplight/spectral-cli

Run it locally:

spectral lint openapi.yaml

You should see an error related to the path parameter mismatch.

Generating a SARIF Report

Instead of printing results to the console, we can generate a SARIF report:

spectral lint openapi.yaml \
  --format sarif \
  --output results.sarif

This produces:

results.sarif

which GitHub can consume directly.

GitHub Actions Workflow

Create:

.github/workflows/openapi.yml

name: OpenAPI Validation

on:
  pull_request:

permissions:
  contents: read
  security-events: write

jobs:
  openapi:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install Spectral
        run: npm install -g @stoplight/spectral-cli

      - name: Generate SARIF Report
        run: |
          spectral lint openapi.yaml \
            --format sarif \
            --output results.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: results.sarif

How It Works

The workflow performs four simple steps:

Checks out the repository
Installs Spectral
Generates a SARIF report
Uploads the SARIF report to GitHub

The upload step is handled by GitHub's official SARIF uploader:

- uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: results.sarif

Once uploaded, GitHub automatically processes the findings.

Viewing Results in Pull Requests

After opening a Pull Request, GitHub analyzes the uploaded SARIF report and associates findings with the corresponding files and lines.

For our example, GitHub highlights the parameter definition and reports something similar to:

Path parameter "id" is not defined.
Expected parameter name "id" but found "userId".

Developers can review the issue directly from the Pull Request without searching through GitHub Action logs.

Why I Prefer This Approach

Many teams fail OpenAPI validation jobs and require developers to inspect CI logs.

While this works, it doesn't scale well when repositories contain multiple specifications or many validation rules.

Uploading SARIF results provides:

Inline annotations
Better visibility during code review
Centralized findings in GitHub Code Scanning
Consistent reporting across different tools

The same workflow can later be extended to include security scanners, secret scanners, IaC scanners, and custom validation tools.

Conclusion

Integrating OpenAPI validation into GitHub Actions is straightforward. With Spectral generating SARIF output and GitHub handling the presentation layer, developers receive feedback exactly where they are already reviewing code: inside the Pull Request.

If your organization already uses SARIF for other security or quality tools, OpenAPI validation can fit naturally into the same workflow with only a few lines of configuration.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub