cargo-attest is a supply-chain verification tool, so security reports matter even while the project is early.
Security fixes will target the main branch until versioned releases begin on crates.io.
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 aMISMATCH, or execute untrusted content.
cargo-attest does not execute downloaded release assets. It downloads artifacts, hashes them, and compares metadata/proofs.
- 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 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
Skipcheck, not a failure. Use--require-rekorto 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.
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
0700on Unix. No other users on the system can read or write cache entries. - No secrets stored — the cache contains only public artifacts (
.cratefiles, 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-attestprocesses 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.
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-rekorfor 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.
- Fulcio root CA —
src/roots/fulcio-root.pem(bundled viainclude_str!) - Rekor public key —
src/roots/rekor-root.pem(bundled viainclude_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.
Cargo.lockis committed to the repository, ensuring reproducible builds.- All dependencies are pure Rust — no C FFI, no OpenSSL.
- HTTP/TLS via
reqwest+rustls-tlswith vendored webpki roots. cargo auditis run before each release to check for known vulnerabilities.
- 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).