GitHub Action
veriva-ai/analyze-action@v1 runs the open-source @veriva/engine static analyzer directly inside your GitHub Actions runner. It produces a SARIF report, uploads it to GitHub Code Scanning so findings show up in the repo's Security tab, and can fail the workflow on a configurable trust-score floor or on critical findings.
No API key. No app install.
Install
Add a workflow file at .github/workflows/veriva.yml:
name: Veriva
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
jobs:
scan:
runs-on: ubuntu-latest
permissions:
contents: read
# Required if upload-sarif is true (default).
security-events: write
steps:
- uses: actions/checkout@v4
with:
# Full history is needed so the Action can diff against the PR base.
fetch-depth: 0
- uses: veriva-ai/analyze-action@v1That's the minimum config. Findings appear under Security → Code scanning and the workflow run log shows a per-finding annotation on the changed lines.
Inputs
| Input | Default | Description |
|---|---|---|
sarif-file | veriva-results.sarif | Path the Action writes the SARIF report to. |
upload-sarif | true | Upload the SARIF to GitHub Code Scanning. Requires security-events: write permission on the job. Set to false if you only want the SARIF as a build artifact. |
fail-on-critical | false | Exit non-zero when one or more CRITICAL or HIGH findings are present. Use when you want Veriva to block merge. |
min-score | 0 | Minimum trust score (0–100). The workflow fails if the run scores below this floor. 0 disables the gate. |
Outputs
| Output | Description |
|---|---|
trust-score | 0–100 numeric trust score for the PR diff. |
grade | A–F letter grade derived from the trust score. |
findings-count | Total findings across every severity. |
critical-count | Number of CRITICAL + HIGH findings. |
sarif-file | Path to the written SARIF file (matches the input). |
Reference outputs in later steps:
- uses: veriva-ai/analyze-action@v1
id: veriva
- name: Comment trust score
run: echo "Trust score ${{ steps.veriva.outputs.trust-score }} (${{ steps.veriva.outputs.grade }})"Required permissions
contents: read— to check out the diff.security-events: write— only whenupload-sarifistrue(the default). Without it, the upload step logs a warning and the workflow continues; the SARIF file is still produced as a build artifact path.
What it does and does not do
The Action ships the engine — the Layer-1 static rule pass plus trust-score computation. It deliberately does not run the full ten-stage server pipeline (cross-PR consistency, deep-audit escalation, fix agent, model routing, deny-rule enforcement). Those layers require server state and live in the Veriva GitHub App.
Pick the entry point that matches your need:
- GitHub App — full pipeline, PR comments, check-runs with provenance, agent-identity tracking, A–F trust score in the dashboard. Best for orgs that own the repo.
- This Action (
analyze-action) — engine-only, runs on the runner, writes SARIF, no API key. Best for public forks, OSS projects that want Code Scanning without an app install, and orgs that need findings to live inside the GitHub Security tab.
Self-hosted runners
Works out of the box on self-hosted runners. The Action only needs the GitHub API for the SARIF upload step (via the gh CLI that's already on the runner). For air-gapped runners that can't reach api.github.com, set upload-sarif: false and either commit the SARIF as an artifact or push it to your own SAST aggregator.
Versioning
We follow major-version pinning: veriva-ai/analyze-action@v1 always tracks the latest v1.x.y release and is backwards-compatible. Pin a specific tag (e.g. veriva-ai/analyze-action@v1.2.0) if you need build reproducibility.