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 specifically want keyless signing or a public Rekor transparency log, Attestree interoperates with it — but it is an option, not a dependency.

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 also searchable in-product, and the search runs over the signed spans themselves — what you query is what was signed. That searchable view is built behind a transaction-safe horizon, so it never advances past spans still being written, and a completeness checker re-verifies that what is searchable matches what was ingested. If the projection ever stalls, it surfaces as a visible signal — an incomplete audit search should announce itself, not look like a clean result.

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. WDAC policy generation, for kernel-level enforcement, is on the roadmap rather than shipped today. You can also simulate a decision before relying on it: the simulator evaluates against the exact policy set being enforced, through the same engine.

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. The point is that it is one primitive across ecosystems, not a separate SBOM tool bolted on per manager.

There is a one-action export. It pages the whole audit store for the window you ask for, re-verifies every span's signature, writes them as canonical JSON — the exact bytes that were hashed, so a regulator re-canonicalizing a line gets the digest back — takes a SHA-256 over the set, and seals a manifest carrying the bundle id, window, span count, content digest, and signer metadata. The manifest is signed with the same production key. The one thing it will not do is stretch: a dev-signed span aborts the build outright. The free Community Edition signs its audit chain with a local dev-grade key, so it cannot produce a submittable bundle — and it says so in-product, disabling the button rather than serving you a download that would fail an auditor's check. Configure a production signing key and the export is whole. We would rather refuse than hand you evidence that does not hold.

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. But 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 — the cases that actually matter — and a quiet badge otherwise, so this never becomes alert noise. If the publisher republishes, an operator re-ingest resurrects it.

Because the two answer different questions. Our front-line control is the ingest gate — a CVE that surfaces after an artifact is already running on your fleet is, by then, a confession, not a defense, and that is exactly why we move provenance to ingest. 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. And when a named CVE breaks, or an insurer asks about a KEV entry with a patch SLA, you still have to answer "which of my endpoints run the affected version, and are they patched?" in minutes. The fleet CVE index answers that retrospective question honestly. It is not the thing that keeps bad software off your fleet; it is the thing that tells you the truth about the software already there.

By refusing to show you the whole world. It matches the public 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 full 368,000-record corpus is never stored. The exposure view is KEV-first, because under six percent of CVEs are ever exploited and a list that buries the one affecting five hundred machines under five hundred that affect one laptop is worse than no list. Every match carries a confidence tier — confident when it comes from an operator pin or the shipped seed list, hedged when a token heuristic produced it, and a hedged match never presents as definitive. You can pin a package-to-product mapping either way, including a negative pin that says "this is not that product" and suppresses the match. It replaced an older CPE-keyed feed that went structurally blind when NIST stopped enriching most new CVEs; this one keys on the vendor and product data the CVE record carries itself.

It says so, out loud, rather than showing you a reassuring zero. A surface that cannot evaluate renders "not evaluated," never "0 affected" — the specific dishonesty the previous feed committed. If the store and a live inventory read disagree, that is a visible fault, not a silent pass. If sync falls behind or egress is blocked, a staleness banner says the coverage is degraded. An endpoint dropping out of a partial inventory read arms a marker and only clears the finding if it is still gone on the next full pass, so a transient under-report never writes a false "resolved" into the signed history. Connected deployments self-sync; an air-gapped one imports the same data as a signed bundle and runs the same matcher locally, so being offline costs you freshness, not the capability.

It defers, honestly, and that is the default. A machine-scope upgrade blocked by a running app is recorded as "deferred — app in use", not as a failure: it holds its own distinct state, backs off on a cooldown, and is excluded from the install-fail-rate, so one busy laptop cannot make a healthy rollout look like it is failing. Before this, that same case logged a hard failure and re-spawned an elevated installer roughly ninety-six times a day on a single endpoint. Actually closing the app is opt-in and deliberately hard to arm: it takes both a per-package flag and an endpoint group you have marked unattended before anything closes without a person present. On an attended machine the user is notified in-session, with a grace window and the option to defer. If they do click "Close now" and the app ignores it — minimize-to-tray apps treat a close request as "hide" — escalating to a real terminate needs their explicit consent, bound to their own session and re-checked against the process owner at the moment it acts, so it can never reach past their own instance. It refuses outright when it cannot restore what it would close. After the upgrade, the app comes back through its own registered auto-start entry.

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 — so erasure becomes possible without rewriting or re-signing history, which the signature sealing would refuse anyway. Two limits worth stating 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, which is exactly right: it is your data and you are meant to be able to reach it until you erase. On a self-hosted deployment you are the controller and we never hold the databases. We build the capability; the decision stays yours.

As a first-class scope, not an edge case. Whether a package is machine- or user-scope is an attested catalog property — read from the manifest, corroborated by the detonation footprint, operator-overridable. User-scope apps install impersonated in the target user’s own session through the Apache-2.0 shim, never into the SYSTEM profile — so what executes on endpoints stays readable in one open-source component. Each endpoint converges for its primary user (auto-derived, operator-pinnable), or — flagged as a shared device — for every interactive user. A target user who is not signed in shows as an honest "pending logon", not falsely converged, and inventory attributes every per-user install to the user who actually has it.

The free Community Edition generates signed attestations today, self-hosted, covering winget ingest — plus Chocolatey inventory and management — 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.

Through the same machinery it enforces for your packages. Agent updates roll out ring by ring; a health evaluator watches each ring and pauses or aborts the rollout automatically on bad signals; and every endpoint keeps a known-good rollback floor on disk, so a misbehaving update rolls itself back — surviving reboots mid-handoff. An update parked on a pending reboot can even finalize without one, once evidence shows the new version healthy — and endpoints that stall mid-update raise a fleet alarm instead of quietly falling behind. The rollout controls — pause, abort, resume — are in-product in every edition, Community included. We dogfood the ring-and-rollback primitive on our own binary before asking you to trust it with yours.

It happens more than you would think — a stale App Installer package, a SYSTEM context winget was never provisioned for. The agent probes winget health on every endpoint and surfaces broken installations as a fleet-level signal, so "the package manager is down" is a tile you see, not a mystery you debug per machine. A guarded self-heal (repairing the winget installation in place) ships behind an operator flag — default off, never auto-rebooting — so remediation is a decision you make, not a surprise. The repair works on stock endpoints: the agent installer carries the winget PowerShell client and the Microsoft VC++ redistributable it needs, so it can fix a machine that never had them staged. And the enable flag rides inside the signed desired state, so a tampered or injected response can never arm a repair you did not authorize.