The trust layer, not a logger.

You do not need to wrap anything in cosign. Today each detonated package gets an attestation recorded against its installer’s SHA-256, and audit spans are signed with ECDSA P-256 by a key your instance holds. A per-package signed in-toto statement that you can download and verify with standard tooling is being built. Sigstore is an option, not a dependency: you can switch on a Rekor transparency-log entry for each attestation, and it is off by default. Cosign is what we sign our own release images with. The commercial tiers, in design-partner mode through GA, keep the signing key in a Key Vault in your own Azure subscription; HSM-backed custody and air-gapped evidence sync are on the roadmap.

Both exist, and today the audit log is the stronger half. Each detonation records an attestation — the installer’s SHA-256, the SBOM digest and the footprint digest — and the signing event, with those digests, lands in the signed audit log. The signed attestation document itself is not kept yet, so there is no per-package file to verify with one command today; that is being built. The audit trail 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 app installs — winget and Chocolatey today — where the enforcement layer is different. Policy is Cedar: role-based authorization for catalog actions such as attest and promote, plus promotion gates keyed on each version’s attestation tier, and you can simulate a decision against the enforced policy set before relying on it. Writing your own Cedar policies is not available yet.

Both, and that is the point. At ingest, detonation decides what gets attested, and the promotion gate reads that result; in Community Edition you can still promote an unattested version, and the console marks it dev-grade. On the endpoint, the agent accepts only signed desired state and installs only the SHA-256 you approved. 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.

Today, winget: with a detonation host attached, winget ingest is detonation-backed. Chocolatey is managed under the same control plane — inventory, subscribe, ring-deploy — but its packages are not detonated or attested yet; that is the next slice. Scoop is inventoried today; scoop deployment stays off until an operator populates the trusted-bucket allowlist, so we do not count it as a managed manager. npm, pip, .NET tools, PowerShell Gallery, MSI and MSIX are on the roadmap. 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: the signing key sits in a Key Vault in your own Azure subscription instead of a file on the host (HSM-backed custody is on the roadmap), 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 can import the same data as an offline bundle and run the same matcher locally; pin a public key to require a valid signature on the bundle.

You find out, and nothing gets yanked out from under your fleet. Once you switch on the upstream monitor (it ships off, because it needs egress to the public source), 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.