~ / headless_mode /
$ AI agent governance, security tooling, and mechanical enforcement.

Verify rigscore

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

Verify this tool before you run it. Every rigscore release is signed via Sigstore keyless OIDC and ships with a CycloneDX SBOM. Two commands, no trust required.

A security tool that asks you to trust the author is its own theater problem. Below is the full verification recipe for the current pre-release, v2.1.0-rc1. 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.

You should not have to take any of this on faith. Verify it.

2. Tag signature

1git verify-tag v2.1.0-rc1

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

3. Provenance attestation (the canonical check)

Two commands:

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

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

1scripts/verify-release.sh v2.1.0-rc1

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-rc1, by the workflow .github/workflows/release-provenance.yml, and signed via Sigstore keyless OIDC against the GitHub Actions identity. The Rekor transparency log holds the entry; the certificate’s signer identity binds the artifact to a specific workflow run.

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.

Note on the tarball name. The package version inside package.json is 2.0.0; the release tag is v2.1.0-rc1. The tarball produced by npm pack is therefore rigscore-2.0.0.tgz. Use that filename when calling gh attestation verify.

4. SBOM review

Every release bundles a CycloneDX 1.5 SBOM:

1gh release download v2.1.0-rc1 --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 supply-chain 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-rc1
3nvm use 20      # match the Node version the release workflow used
4npm ci          # package-lock.json is the anchor
5npm pack
6sha256sum rigscore-2.0.0.tgz

For v2.1.0-rc1, the published tarball SHA256 is:

1326722160238a406e026abaac75169c84fe4c9781d3bfb39a20a624957c51da2  rigscore-2.0.0.tgz

Compare against the asset:

1gh release download v2.1.0-rc1 --repo Back-Road-Creative/rigscore --pattern '*.tgz'
2sha256sum rigscore-2.0.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 produce slightly different tar headers. If your local hash differs and the attestation in step 3 verifies, trust the attestation — it ties the bytes to the actual GitHub Actions build. The hash recipe is a sanity check, not the primary signal.

6. Public bypass tests

We publish the cases rigscore intentionally does NOT catch:

These tests are public so you can audit our limits. They lock the current behavior — a future PR that closes one of them deletes the corresponding .skip and adds the positive assertion. Do not assume rigscore catches anything that is not asserted in the test suite. {#known-limits}

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 (Snyk Agent Scan, Semgrep, AgentShield).

If you need a check rigscore does not implement, file an issue with a fixture. The project’s bias is to land characterization tests for known gaps before claiming the gap is closed.

See also

← Back to Home