Skip to content

Security: Nil06/cargo-attest

Security

SECURITY.md

Security Policy

cargo-attest is a supply-chain verification tool, so security reports matter even while the project is early.

Supported Versions

Security fixes will target the main branch until versioned releases begin on crates.io.

Reporting a Vulnerability

Please do not open a public issue for a vulnerability.

Report security issues through GitHub private vulnerability reporting if it is enabled on the repository. If it is not enabled yet, contact the maintainer directly through the GitHub profile listed on the repository.

Useful details include:

  • affected command and version or commit;
  • exact input release/crate if public;
  • expected verdict vs actual verdict;
  • whether the issue can cause a false TRUSTED, hide a MISMATCH, or execute untrusted content.

Current Guarantees

cargo-attest does not execute downloaded release assets. It downloads artifacts, hashes them, and compares metadata/proofs.

Cryptographic Verification

  • GitHub artifact attestations — DSSE envelope signature (ECDSA P-384), Fulcio X.509 certificate chain to bundled root CA, in-toto subject digest matching.
  • Rekor SET verification — Signed Entry Timestamp verified against the bundled Rekor ECDSA P-256 public key. Proves the attestation was observed by the transparency log at a specific time.
  • Cosign detached signatures — ECDSA P-256 and P-384 signature verification, Fulcio certificate chain validation.
  • SHA-256 checksums — constant-time hex comparison (hash::eq_hex).
  • Certificate expiry — Fulcio signing certificates are checked for validity period (Fulcio issues short-lived certs with ~10-minute validity windows).

Rekor Trust Model

Rekor verification addresses a specific threat: a compromised Fulcio key could forge attestations retroactively. The Rekor Signed Entry Timestamp (SET) proves the attestation existed at a specific point in time, recorded in a public, append-only transparency log.

  • Bundled key — the Rekor ECDSA P-256 public key is bundled at compile time via include_str!("roots/rekor-root.pem"), preventing runtime substitution.
  • Source of truth — the key is sourced from the Sigstore TUF repository (GET https://rekor.sigstore.dev/api/v1/log/publicKey) and pinned at a known-good version.
  • Graceful degradation — missing or unverifiable Rekor entries produce a Skip check, not a failure. Use --require-rekor to hard-require Rekor verification in CI policies.
  • Compromise impact — if Rekor's signing key were compromised, all SETs would become unreliable. This is a systemic Sigstore risk, not specific to cargo-attest. Future TUF key rotation support (planned for v1.1) would mitigate this.

Cache Security

The local cache ($CARGO_HOME/attest/cache/) follows these security practices:

  • Content-addressed by SHA-256 — artifact cache keys are cryptographic hashes of artifact content. Substituting a different artifact produces a different key, making cache poisoning impossible.
  • Owner-only permissions — cache directories are created with 0700 on Unix. No other users on the system can read or write cache entries.
  • No secrets stored — the cache contains only public artifacts (.crate files, release binaries) and public API responses (release metadata, attestation bundles). No authentication tokens, private keys, or credentials are cached.
  • Atomic writes — files are written to a temp file then atomically renamed, preventing torn reads if two cargo-attest processes run concurrently.
  • TTL-based metadata — API responses have a configurable TTL (default 10 minutes), preventing stale cached data from being used indefinitely.
  • Corruption tolerance — cache read failures are never fatal. The tool logs a warning and falls back to network fetch.

--strict Mode

The --strict flag promotes any Skip check to Fail, causing exit code 2 (MISMATCH). This guarantees that every verification path was both applicable and successful. Use --strict when:

  • You want to ensure Rekor verification executed (combined with --require-rekor for maximum coverage).
  • You're running in a CI pipeline that requires maximum verification coverage.
  • You want to detect when a check silently degrades (e.g., attestation API becomes unavailable).

Without --strict, a skipped Rekor check produces UNVERIFIED (exit code 1) — the artifact is still accessible, just not fully trusted.

Compile-Time Root Certificates

  • Fulcio root CAsrc/roots/fulcio-root.pem (bundled via include_str!)
  • Rekor public keysrc/roots/rekor-root.pem (bundled via include_str!)

Both are pinned at known-good versions and verified in CI. Runtime override of these roots is not supported in v1.0. If the Sigstore infrastructure rotates these keys, cargo-attest must be rebuilt with updated PEM files. See CONTRIBUTING.md for the update procedure.

Supply Chain of cargo-attest Itself

  • Cargo.lock is committed to the repository, ensuring reproducible builds.
  • All dependencies are pure Rust — no C FFI, no OpenSSL.
  • HTTP/TLS via reqwest + rustls-tls with vendored webpki roots.
  • cargo audit is run before each release to check for known vulnerabilities.

Out of Scope (Current Release)

  • Merkle inclusion proof verification (deferred to v1.1).
  • TUF key rotation (deferred to v1.1).
  • CRL/OCSP revocation checking (low value with Fulcio short-lived certs).
  • SLSA provenance verification (separate concern per project scope).

There aren't any published security advisories