Snyk Code is a static application security testing (SAST) engine that finds vulnerabilities directly in source code, while GitHub Advanced Security (GHAS) provides the code scanning surface — the Security tab, pull request checks, and alert lifecycle management — inside GitHub itself. The two products don't talk to each other natively; they're connected by SARIF (Static Analysis Results Interchange Format), an OASIS-standardized JSON schema that GitHub adopted as its universal ingestion format for third-party scanners. When Snyk Code runs, it doesn't push results into GitHub directly — it writes a SARIF file, and a separate upload step hands that file to GitHub's code scanning API. Understanding this handoff — how the file is structured, how it's transmitted, and how GitHub interprets it — explains both why the integration works reliably across languages and CI systems, and where teams commonly hit friction. This post walks through that mechanism end to end, using the publicly documented SARIF 2.1.0 spec and GitHub's code scanning API.
What is SARIF, and why do Snyk and GitHub both use it?
SARIF is a vendor-neutral, JSON-based format for describing the output of static analysis tools, standardized by OASIS with the current version, SARIF 2.1.0, ratified in March 2020. Rather than every scanner shipping a proprietary results format and every consumer building a custom parser for each one, SARIF defines a common schema for runs, rules, results, locations, and code flows. GitHub built its code scanning feature around SARIF specifically so it could accept output from any compliant tool — CodeQL, Snyk Code, Semgrep, ESLint with a SARIF formatter, and dozens of others — through a single ingestion pipeline. For a company like Snyk, this means one output format serves every SARIF-consuming platform (GitHub, GitLab, Azure DevOps) rather than a bespoke integration per platform. A SARIF file's top-level structure includes a runs array, where each run has a tool.driver object identifying the scanner (for Snyk Code this is typically reported as SnykCode), a rules array defining each finding type, and a results array containing the actual matches.
How does Snyk Code actually generate the SARIF file?
Snyk Code produces SARIF output through the Snyk CLI's test command using the --sarif-file-output flag — for example, snyk code test --sarif-file-output=snyk-code.sarif — or through Snyk's official GitHub Action, which wraps the same CLI call inside a workflow step. Each vulnerability Snyk Code identifies (say, a hardcoded credential, a path traversal, or an SQL injection sink) is mapped to a result entry referencing a ruleId, such as javascript/NoHardcodedCredentials or python/SqlInjection, with a level of error, warning, or note depending on severity. Because Snyk Code performs data-flow analysis rather than simple pattern matching, many results include a codeFlows object that traces the vulnerable data path from source to sink across multiple file locations — for instance, showing how untrusted input from an Express route handler flows unsanitized into a database query several function calls later. This code-flow detail is what lets a GitHub reviewer click through a single alert and see the exact multi-step path, rather than just a flagged line.
How does the SARIF file get from the CLI into GitHub's Security tab?
The generated SARIF file is uploaded to GitHub through the github/codeql-action/upload-sarif action, which is a thin wrapper around a POST request to the /repos/{owner}/{repo}/code-scanning/sarifs REST endpoint. The action gzip-compresses and base64-encodes the file before transmission, and GitHub documents a hard cap on this upload — the SARIF payload must be under 10 MB after gzip compression, which is why very large monorepo scans sometimes need to be split by directory or language. A typical workflow step looks like:
- name: Run Snyk Code
run: snyk code test --sarif-file-output=snyk-code.sarif
continue-on-error: true
- name: Upload SARIF to GitHub
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: snyk-code.sarif
The continue-on-error: true step is a deliberate pattern: Snyk Code's CLI exits with a non-zero status when it finds vulnerabilities, which would otherwise halt the workflow before the SARIF file is ever uploaded. Once GitHub receives the payload, results populate under the repository's Security tab as Code scanning alerts, and if the workflow ran on a pull request event, matching alerts also surface as annotations directly on the diff.
How does GitHub avoid re-flagging the same issue on every commit?
GitHub deduplicates and tracks alerts across commits using a fingerprinting mechanism keyed on the partialFingerprints field that scanners populate in their SARIF output, combined with GitHub's own fallback fingerprinting when that field is absent. The fingerprint is derived from a combination of the rule ID, file path, and a hash of the surrounding code context, which allows GitHub to recognize that a finding on line 42 of a file is the "same" alert even after an unrelated edit shifts it to line 47. This is what makes an alert's state (open, dismissed, fixed) persist meaningfully across a repository's history instead of resetting on every push. It also means that if a developer dismisses a Snyk Code finding as a false positive, that dismissal survives subsequent scans as long as the surrounding code context stays reasonably stable — a substantial change to the function often breaks the fingerprint match and can cause the alert to reappear as "new."
What operational limits and configuration details actually matter?
Two details determine whether this integration behaves correctly in a multi-tool or multi-language repository: the category field and workflow permissions. When more than one SARIF upload targets the same commit — for example, Snyk Code scanning JavaScript and a separate job scanning Python — each upload needs a distinct category value in the upload-sarif step, or GitHub will treat the later upload as replacing the earlier one rather than as a separate result set. Separately, the workflow's GITHUB_TOKEN needs security-events: write permission (and actions: read for private repositories) for the upload step to succeed; without it, the action fails silently in some CI configurations or returns a 403 from the code scanning API. It's also worth noting that Code scanning alerts populated via third-party SARIF, including Snyk Code, are a GitHub Advanced Security feature — free and unrestricted on public repositories, but requiring a GHAS license to appear on private repositories, which is a common point of confusion for teams testing the integration on an internal repo for the first time.
How Safeguard Helps
Snyk Code's SARIF output is a solid, standards-based signal — but in most organizations it's one of several: CodeQL results, container scans, IaC findings, and SBOM-derived dependency alerts all land in overlapping but disconnected places, and SARIF's per-tool, per-repo structure doesn't by itself answer "which of these findings sit on a component actually shipping to production, and where did that component come from." Safeguard ingests SARIF and other scanner outputs — including Snyk Code results — alongside SBOM and build-provenance data, correlating a given finding to the specific artifact, build, and dependency path it affects across your software supply chain. That means a Snyk Code alert on a data-flow path isn't just a line in the GitHub Security tab; it's tied to the package version, the pipeline that built it, and any downstream services consuming it, so security and platform teams can prioritize by actual exposure rather than triaging each tool's output in isolation. For teams already relying on Snyk Code and GHAS, Safeguard is a layer that adds supply chain context on top of the SARIF signal you're already generating, without requiring a change to the scanning tools themselves.