SARIF export and GitHub code scanning integration

Export a completed vetkit audit through its report endpoint with format=sarif, then upload the SARIF 2.1.0 file from your GitHub Actions workflow. Match the audit to the repository and commit being analyzed before uploading. Downloading the report does not itself publish alerts to GitHub; the upload is a separate step you configure.

1. Check prerequisites

• Have the organization ID, audit ID and a vetkit API key with reports:read. An automated workflow that also starts and polls audits needs audits:write and audits:read.
• Confirm the audit’s repository and commit SHA. For CI, request or reuse an audit for the workflow’s exact commit and wait for it to complete before exporting.
• Inspect the JSON report for partial results and the actual scan scope. A valid SARIF document can still represent incomplete analysis.

GitHub supports code scanning for public repositories and eligible organization repositories with GitHub Code Security enabled. Check your repository’s eligibility and write access in GitHub’s SARIF upload documentation.

2. Export the audit

Set the variables below in your local shell or CI environment. VETKIT_API_URL is your vetkit API origin without /v1. Store the key in a secret manager or CI secret, not in the workflow file, repository or shell script. This command requires curl and jq:

$ set -euo pipefail$ : "${VETKIT_API_URL:?Set the API origin}"$ : "${VETKIT_ORG_ID:?Set the organization ID}"$ : "${VETKIT_AUDIT_ID:?Set the completed audit ID}"$ : "${VETKIT_API_KEY:?Set a reports:read key}" $ curl --fail-with-body --silent --show-error --max-time 30 \  "$VETKIT_API_URL/v1/orgs/$VETKIT_ORG_ID/audits/$VETKIT_AUDIT_ID/report?format=sarif" \  -H "Authorization: Bearer $VETKIT_API_KEY" \  -o vetkit.sarif$ jq -e '.version == "2.1.0" and (.runs | type == "array")' vetkit.sarif >/dev/null

The endpoint returns application/sarif+json and an attachment filename based on the audited commit. The command deliberately saves it as vetkit.sarif for the upload step. The jq check is a basic format check, not full schema validation or confirmation of scan completeness. Treat the downloaded report as repository information and control access to it.

3. Upload from your workflow

In a workflow for the scanned repository, check out the matching source, obtain the completed audit and run the download command above. Keep VETKIT_API_KEY in an Actions secret. The following fragment shows permissions and the final upload step; it is not a standalone scan workflow. Add the download between checkout and upload:

permissions:  contents: read  actions: read  security-events: write # Inside the job's steps, after choosing the matching audit:steps:  - uses: actions/checkout@v6    with:      persist-credentials: false  # Insert the authenticated download step here.  - name: Upload vetkit results    uses: github/codeql-action/upload-sarif@v4    with:      sarif_file: vetkit.sarif      category: vetkit

GitHub’s upload action uses sarif_file for the report path and category to distinguish analyses. Reusing a tool/category for the same commit can replace earlier results; use distinct categories for separate analyses. The permissions and action versions above follow GitHub’s example.

vetkit’s repository integration example keeps SARIF upload optional behind VETKIT_UPLOAD_SARIF=true. Its full-scan workflow requests an exact-commit audit and rejects failed, partial or unscored results before the optional upload. That completion check does not impose a finding-severity or score threshold: define your release policy separately. GitHub App checks and a SARIF upload are separate integration paths.

4. Interpret the imported results

vetkit exports one SARIF run with vetkit as the driver. Results include rule IDs, file locations where available, remediation text and vetkit fingerprints. Analyzer versions are recorded as extensions, and repository/commit provenance is included. Severity mapping uses SARIF levels alongside vetkit’s severity properties; those numeric mappings are not independently calculated CVSS scores.

Repository-level findings use a synthetic (repository) location, so they may not point to a real source line. Suppressed findings remain in the export with SARIF suppression metadata. Do not assume that the exported result count equals the number of active alerts shown by GitHub. Keep the original vetkit report for coverage, scoring context and review details.

Troubleshooting

• Download fails: check the API origin, organization and audit IDs, key validity and reports:read scope. Do not print the key while debugging.
• Wrong source locations: compare the audit commit with the workflow commit and checkout. Do not upload an older report as evidence for a newer revision.
• Upload is rejected: check GitHub eligibility, workflow permissions and the upload action’s error output. GitHub applies its own supported SARIF properties and size limits.
• No visible alerts: inspect the file’s results, suppression metadata, selected analysis and original audit coverage. Successful transport does not prove a clean scan.

Sources and limits

Checked on November 1, 2026 against vetkit’s report controller/service, SARIF serializer and repository GitHub Actions integration example. See the API reference and GitHub’s upload requirements for the two sides of the integration. GitHub eligibility and action behavior can change. SARIF export transfers existing findings; it does not run CodeQL, add checks to the original audit or guarantee that every vetkit report detail appears in GitHub’s interface.