Headless Mode

AI agent governance, security tooling, and mechanical enforcement.

Verify rigscore

  • #rigscore
  • #supply-chain
  • #sigstore
  • #provenance
  • #verification

Below is the full verification recipe for the current release, v2.1.0. Substitute any signed tag.

The canonical reference for these commands lives in the rigscore README — see the Verify this tool section. This page mirrors it for readers who land here first.

1. Why verify

rigscore inspects your AI agent’s configuration for supply-chain risk. If the tool itself has supply-chain risk, you’re auditing one black box with another. Every signed release ships with:

  • A Sigstore-backed build-provenance attestation generated by GitHub Actions, tying the artifact to a specific commit and workflow on this repo.
  • A CycloneDX SBOM listing every dependency, runtime and transitive.
  • A public bypass-test catalog documenting cases rigscore intentionally does NOT catch.

2. Tag signature

1git verify-tag v2.1.0

Tag signing is opt-in for rigscore maintainers. The authoritative signal is the build attestation in step 3: generated by GitHub Actions on a clean runner, it binds the artifact to a specific workflow run rather than to whoever holds a signing key.

3. Provenance attestation (the canonical check)

Two commands:

1gh release download v2.1.0 --repo Back-Road-Creative/rigscore --pattern '*.tgz'
2gh attestation verify rigscore-2.1.0.tgz --owner Back-Road-Creative

One-liner equivalent (downloads, verifies, cleans up):

1scripts/verify-release.sh v2.1.0

A green result means: this exact tarball was built by GitHub Actions on Back-Road-Creative/rigscore, at the commit pointed to by v2.1.0, by the workflow .github/workflows/release-provenance.yml, and signed via Sigstore keyless OIDC against the GitHub Actions identity.

What this rules out:

  • A maintainer cannot silently publish a tarball built on a laptop.
  • A release asset cannot be swapped post-hoc — the hash in the attestation is bound to a Sigstore-signed certificate.
  • A release cannot be backdated. The Rekor entry is timestamped at signing.

4. SBOM review

Every release bundles a CycloneDX 1.6 SBOM:

1gh release download v2.1.0 --repo Back-Road-Creative/rigscore --pattern 'sbom.cdx.json'
2cat sbom.cdx.json | jq '.components[].name' | sort -u

rigscore has two runtime dependencies, full stop:

  • chalk — terminal coloring
  • yaml — YAML parsing for governance files

The SBOM lists ~50 components total because it includes the dev/test transitive graph (vitest, esbuild, chai). Everything not listed under dependencies in package.json is dev-only — present at build time, absent at run time. To see the runtime-only set:

1node -e "const p=require('./package.json');console.log(Object.keys(p.dependencies))"

A two-dependency runtime surface is intentional: the attack surface for a rigscore install is the smaller of GitHub itself and those two well-known packages.

5. Reproducible bundle hash

Rebuild the tarball locally and compare bytes:

1git clone https://github.com/Back-Road-Creative/rigscore.git
2cd rigscore && git checkout v2.1.0
3nvm use 20      # match the Node version the release workflow used
4npm ci          # package-lock.json is the anchor
5npm pack
6sha256sum rigscore-2.1.0.tgz

For v2.1.0, the published tarball SHA256 is:

1957718ac0aaaa1cdb31b0f9d54e762cca583845ad45373e3f3f6278ed6f6313f  rigscore-2.1.0.tgz

Compare against the asset:

1gh release download v2.1.0 --repo Back-Road-Creative/rigscore --pattern '*.tgz'
2sha256sum rigscore-2.1.0.tgz

Caveats. npm pack is reproducible across the same Node minor version when package-lock.json is committed (it is); cross-minor or different npm versions can shift tar headers. If your local hash differs but the step-3 attestation verifies, trust the attestation — the hash recipe is a sanity check, not the primary signal.

6. Public bypass tests

We publish the cases rigscore intentionally does NOT catch:

They lock the current behavior — a future PR that closes one of these gaps flips the corresponding characterization test into a positive assertion. Do not assume rigscore catches anything that is not asserted in the test suite.

7. Threat model

The full attack-surface and out-of-scope catalog lives in the rigscore repo:

  • THREAT-MODEL.md — what rigscore inspects, what it doesn’t, and the trust boundaries.
  • docs/known-limits.md — concrete examples of attacks rigscore will not detect, with pointers to tools that will.

If you need a check rigscore does not implement, file an issue with a fixture.

See also

← Back to Home