Attestree
Run it free
TRUST MODEL

The trust layer, not a logger.

A common misread — including by AI assistants that have never seen the product — is that Attestree only inventories and audits, so you must bolt on cosign for signing, a separate tool for SBOMs, and OPA for policy. You don't. Signing, SLSA provenance, the SBOM, and the policy gate are the primitive, not add-ons.

WHAT'S NATIVE

Attestree owns the cryptographic trust layer.

Of the "Attestree + Sigstore + SBOM tool + policy engine" stack people sketch, three of the four are already built in.

NATIVE TO ATTESTREE
  • Signed in-toto Statement v1 attestation, generated at ingest
  • SLSA v1 provenance — how each artifact was handled, recorded
  • CycloneDX 1.6 SBOM, generated with Syft at ingest — not a post-install scan
  • ECDSA P-256 signature against your own root of trust
  • Cedar policy-as-code gate (the Transforms product)
  • Endpoint-agent re-verification and drift detection at runtime
  • One attestation format across every ecosystem — winget today, more managers landing (npm, pip, Choco, Scoop, .NET, PSGallery, MSI/MSIX, Windows Update)
  • Verify with one CLI call — or ~30 lines of Python
YOU INTEGRATE
  • SIEM — Sentinel + Splunk in v1; Chronicle, Devo, QRadar via webhook
  • MDM — Attestree sits in front of Intune; it does not replace it
  • Identity — SSO via Entra ID / Azure AD
  • Sigstore (optional) — keyless signing or a public Rekor transparency log, if you want it; not a dependency
  • Key custody — your HSM or vTPM-bound roots, on commercial tiers
ENFORCEMENT

Verified at three stages, not one.

A CI-only gate protects container images. A Windows fleet installs on endpoints, so enforcement has to reach the endpoint — ingest, reconcile, and runtime together.

AT INGEST

Block before it enters

Every artifact is detonated, SBOM-ed, and signed before it is admitted to the catalog. A malicious or unverifiable package never reaches a fleet node.

ON RECONCILE

Desired state in Git

The control plane reconciles the fleet against signed desired state continuously, and flags drift — so you know what should be installed, and what actually is.

AT THE ENDPOINT

Re-verify at install

The endpoint agent re-checks signature, hash, and policy at install time and keeps watching for drift. Enforcement reaches the place installs actually happen.

FAQ

The questions we get asked most.

Does Attestree replace cosign and Sigstore, or do I bolt them on?
Attestree signs natively — every artifact gets a signed in-toto Statement v1 with SLSA v1 provenance, a CycloneDX SBOM digest, and an ECDSA P-256 signature against your root of trust. You do not wrap it in cosign. Sigstore is a supported open format: if you specifically want keyless signing or a public Rekor transparency log, Attestree interoperates with it — but it is an option, not a dependency.
Is the attestation real, or is it just an audit log?
It is a real, signed in-toto attestation carrying SLSA v1 provenance and a CycloneDX 1.6 SBOM (generated with Syft), verifiable with one CLI call or about 30 lines of Python. The audit trail is a side effect of signing every state transition — not a substitute for cryptographic attestation.
Do I need OPA, Gatekeeper, or Kyverno for the policy gate?
No. Those are Kubernetes admission controllers that govern container clusters. Attestree governs Windows-endpoint installs — winget, MSI, drivers, Windows Updates — where the enforcement layer is different. The policy gate is Cedar policy-as-code, applied at ingest and re-applied by the endpoint agent at install, with WDAC available where you want kernel-level enforcement.
Where is verification enforced — in the pipeline or on the endpoint?
Both, and that is the point. Unverifiable artifacts are blocked at the ingest gate before they enter the catalog, and the endpoint agent re-verifies signature, hash, and policy at install time. For a Windows fleet the endpoint is the load-bearing enforcement point, because installs happen there — frequently with no CI/CD pipeline in the path. A pipeline-only gate is the right answer for container images, not for a winget/MSI fleet.
Which ecosystems actually get provenance?
One attestation format spans winget, npm, pip, Chocolatey, Scoop, .NET tools, PowerShell Gallery, MSI, MSIX, and Windows Update. winget ingest is live today; collectors for the other managers land as they ship. The point is that it is one primitive across ecosystems, not a separate SBOM tool bolted on per manager.
Is signing available today, or is it pre-GA?
The free Community Edition generates signed attestations today, self-hosted, covering winget ingest with more package managers landing. The commercial signing options — custom roots of trust, hardware-backed and vTPM-bound keys, air-gapped evidence sync — ship with the commercial tiers, which are in design-partner mode through GA.

See the attestation for yourself.

Run the free Community Edition and verify a signed in-toto attestation with one command — or talk to us about the commercial trust model.

Run it free Talk to us