The trust layer, not a logger.

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 want keyless signing or a public Rekor transparency log, Attestree interoperates with it, as an option rather than a dependency. The free Community Edition signs today, self-hosted. Custom roots of trust, hardware-backed and vTPM-bound keys, and air-gapped evidence sync ship with the commercial tiers, which are in design-partner mode through GA.

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. It is searchable in-product, and the search runs over the signed spans themselves behind a completeness check — so a stalled projection announces itself instead of looking like a clean result.

No. Those are Kubernetes admission controllers for 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, and you can simulate a decision against the exact policy set being enforced before relying on it. WDAC policy generation, for kernel-level enforcement, is on the roadmap rather than shipped today.

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.

One attestation format spans winget, npm, pip, Chocolatey, Scoop, .NET tools, PowerShell Gallery, MSI, MSIX, and Windows Update. winget ingest is live today with detonation-backed attestation. Chocolatey is managed under the same substrate — inventory, subscribe, ring-deploy — with detonation-backed attestation for choco packages as the next slice. Collectors for the other managers land as they ship. It is one primitive across ecosystems, not a separate SBOM tool bolted on per manager.

There is a one-action export. It pages the audit store for the window you ask for, re-verifies every span's signature, writes the spans as canonical JSON — the exact bytes that were hashed — and seals a SHA-256 manifest over the set. The free Community Edition exports too: it signs with a local file-backed key, the bundle is real, and it verifies offline with the same tool; the manifest discloses how the key was held. What the commercial tiers add is custody — HSM-attested keys whose backing a reviewer can check independently, which is what a regulator-facing submission turns on — and the console says so in place. Where no signer is configured at all, the export refuses outright. We would rather refuse than hand you evidence that does not hold.

As long as you say. The window is yours to set and the default is unbounded — nothing is pruned unless you ask for it. That is deliberate: retention is the data controller's decision, and on a self-hosted deployment the controller is you, not us. We would rather ship a configurable window than pick one for you, because a financial-services baseline has no business binding a homelab. When a prune does run it is partition-granular and two-phase, and the prune itself emits a signed record — so removing history is itself evidence, never a silent gap.

That is what the design is for. Agent and operator spans reference a stable identity ref rather than a raw Windows SID or account name, and the SID-to-ref mapping lives in one place you control. Delete every erasable copy and what remains in the ledger links to nothing — erasure without rewriting or re-signing history, which the signature sealing would refuse anyway. Two limits, stated plainly: this is not anonymisation of the ledger, and while you still hold a linkable copy — in Active Directory, on the endpoints, in your fleet tables — the ref is still personal data to you. That is correct: on a self-hosted deployment you are the controller, we never hold the databases, and the decision stays yours.

No, and that is a written product constraint rather than a default someone can flip. The data boundary is point-in-time presence — what is installed, which version, in which scope — because that is what patch and licence management actually need. Run frequency, foreground or dwell time, and per-app usage duration are neither collected nor derived. The one duration-shaped input the agent keeps is a bounded attribution heuristic, used only to decide which profile owns a per-user copy, and never surfaced per user. If you are taking this to a works council or into a DPIA, the line between an install inventory and a usage monitor is the one that matters, and we are deliberately on the inventory side of it.

Because the two answer different questions. The front-line control is the ingest gate; a CVE that surfaces after an artifact is already running is a confession, not a defense. But not everything on a real fleet came through the gate: software predates it, arrives outside it, or sits there as a plain uninstall entry no package manager placed — ScreenConnect during CVE-2024-1709 was exactly that. When a named CVE breaks, or an insurer asks about a KEV entry with a patch SLA, you still have to answer "which endpoints run the affected version, and are they patched?" in minutes. The fleet CVE index answers that retrospective question. It is not what keeps bad software off your fleet; it is what tells the truth about the software already there.

By refusing to show you the whole world, and by saying so when it does not know. It matches the cvelistV5 stream and the CISA KEV catalog against the inventory it actually observes — managed packages and unmanaged uninstall entries alike — and persists only the records that match something on your fleet; the 368,000-record corpus is never stored. The view is KEV-first, because under six percent of CVEs are ever exploited. Every match carries a confidence tier — confident from an operator pin or the shipped seed list, hedged from a token heuristic — and you can pin a mapping either way, including a negative pin. When it cannot evaluate it renders "not evaluated", never "0 affected". A store that disagrees with a live inventory read is a visible fault; a stalled sync or blocked egress shows a staleness banner; an endpoint that drops out of a partial read only clears a finding if it is still gone on the next full pass. Air-gapped deployments import the same data as a signed bundle and run the same matcher locally.

You find out, and nothing gets yanked out from under your fleet. The catalog poller notices a version disappearing upstream, confirms it is a real withdrawal rather than a transient fetch failure, and records per-version withdrawal evidence, so the version is tombstoned against new admission. A version you already attested keeps its status and keeps serving: upstream deleting bytes does not retract a decision you made, and it does not break a rollout mid-flight. You get an alarm when the withdrawn version is the newest attested one or is live in a ring, and a quiet badge otherwise, so this never becomes alert noise. If the publisher republishes, an operator re-ingest resurrects it.

It gets adopted rather than reinstalled. Hand-installed copies are matched against the catalog and brought under management in bulk, keeping their ring credit, so day one is not a fleet-wide uninstall-and-reinstall of software that was already fine. Confidence is tiered and the tiers behave differently: a winget-authoritative match and a collision-resistant product-code match can be adopted, while a name-and-version heuristic is deliberately never offered for adoption, because acting on a guess here means removing something a person actually needs. Adoption is reversible — un-adopting hands the package back without uninstalling it.

Yes, and it is usually the larger number. Everything an endpoint reports is reconciled against your catalog and lands in one of three states: matching a version you admitted, drifting from it, or foreign to it entirely — the copies that arrived by browser download, a vendor updater, or an image you inherited. Foreign rows are counted fleet-wide and drill down to the machines carrying each one. One honest caveat: the fleet-wide count is computed at a coarser grain than the per-endpoint view, so it includes rows we recognise but have not admitted, and is not a count of purely unknown software.