HOW-TO / SARIF 2.1.0 / OCTOBER 2026

Turn GitHub Actions workflow checks into Code Scanning alerts.

A workflow YAML preflight is useful in the terminal. A SARIF report makes its results portable: you can preserve rule IDs, severity and source locations, then optionally display findings in GitHub's Code Scanning interface. This guide uses an open-source, browser-first scanner with a local GitHub Action.

Scope: Workflow Risk Check is a lightweight heuristic static preflight, not a security audit. It checks selected GitHub Actions patterns; it does not execute the workflow, analyze arbitrary dependencies, read organization policies or prove that your CI is safe. Pair it with mature analyzers such as actionlint and zizmor for broader coverage.

1. Decide whether to upload or keep reports local

The scanner can run with just contents: read and writes diagnostics to the GitHub job log and step summary. Its SARIF output is off by default. If you only want a local report, provide sarif_file and keep it on the runner or save it as a build artifact through an appropriately pinned action. You do not need security-events: write merely to generate a file.

For GitHub Code Scanning alerts, however, you need to upload the SARIF file using GitHub's upload-sarif action. GitHub documents this for public repositories and certain organization-owned private repositories with Code Security enabled. The upload step needs security-events: write. Avoid granting that permission to arbitrary execution of untrusted PR code.

2. Copy a minimal workflow

The following workflow runs on push, checks files under .github/workflows, and uploads a local SARIF report. The scanner is separately versioned and uses no hosted scanning service or API key. For production hardening, pin all external Actions—including Workflow Risk Check—to reviewed full commit SHAs instead of mutable version tags.

name: Workflow security preflight
on: [push]

permissions:
  contents: read
  security-events: write # only needed by the upload step

jobs:
  inspect:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Inspect workflow YAML
        uses: livastic-vm2-primary-20260911/workflow-risk-check@v1.2.0
        id: preflight
        with:
          directory: .github/workflows
          fail_level: none
          sarif_file: artifacts/workflow-risk.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@6f2ac81f5cd81fe351a197ba0b00d91d03cd2aee # v4
        if: always()
        with:
          sarif_file: artifacts/workflow-risk.sarif
          category: workflow-risk-check

The scanner version tag above is deliberately readable for illustration. Replace it with a reviewed full commit hash from the v1.2.0 release. The CodeQL upload reference in the example was resolved to a full commit at the guide's publication date, and should still be reviewed before deployment.

3. Read the findings without overclaiming

The scanner currently checks for broad GITHUB_TOKEN write scopes, mutable external action references, selected unsafe pull_request_target trust boundaries, direct shell interpolation of event data, self-hosted runner exposure, and other related patterns. It emits annotations and SARIF v2.1.0 records with the YAML location when identifiable.

Results have high, medium, or note levels. A high finding indicates a potentially dangerous pattern, not a proven compromise. Medium findings require context; not every mutable action tag is an exploit. A clean report only means these selected rules did not find a match.

If you prefer a standalone blocking check, set fail_level: high or medium and omit Code Scanning upload entirely. For a Code Scanning upload job, fail_level: none keeps the job available to upload findings even when high alerts are present. A separate protected branch policy can require the appropriate security review.

4. Keep file paths stable and protect your runner

GitHub matches repeat code scanning results by rule ID, location and fingerprints. This scanner includes stable rule IDs and relative paths. GitHub's upload-sarif action can calculate missing partial fingerprints when source files are present. Use the same category across repeat uploads, and a distinct category if you upload separate analyses for the same commit.

The report writer rejects absolute paths, repository traversal and symlinked output directories. YAML files are parsed locally; the tool does not upload them itself. The external upload-sarif step, if enabled, intentionally transfers the report to GitHub. Review report contents and job permissions under your organization's normal data-handling policies.

TRY IT / NO ACCOUNT REQUIRED

Start with one YAML file.

Paste or select your workflow in the free browser checker. For teams with several workflows and complicated permissions, request a scoped remediation quote before sharing private code.

Free preflight ↗Request fixes →

Official references

Published October 16, 2026. This is independent technical guidance, not an official GitHub support document. Verify current permissions and official guidance before changing a production workflow.