Where Attestree enforces: at ingest, at check-in and on the endpoint

This page holds the detail behind the trust page’s three stages: ingest, reconcile and the endpoint.

What gets tested, and what does not

With a detonation host attached, each winget version you ingest is queued for a detonation: one of its installers runs in a sandbox VM cloned from your golden image. Each other installer runs when an endpoint needs it, per architecture and install scope, before any endpoint is served it. An installer no endpoint needs stays unverified. The sandboxes run x64, x86 and architecture-neutral installers, including the MSI and MSIX installers a winget package names, except an MSIX or APPX inside an archive. An x86 installer verified on the x64 sandbox counts for every endpoint that runs it.

A per-user installer runs first as SYSTEM. If that fails and the broker offers an interactive image, it runs again as a signed-in user.

Some installers no sandbox can run: Arm installers, Microsoft Store apps, PWAs, an MSIX or APPX inside an archive, or an installer too large or refused at download. These are not detonated, and Arm installers cannot be verified yet. A version whose run cannot finish waits in a visible state instead: requires interaction, exceeds the detonation budget, or quarantined. Quarantined is not a malware verdict: every failure the platform cannot classify lands there. So does a winget version whose installer reports a different version than its manifest, which means the manifest points at another release’s installer; serving it would install the wrong version. Where the installer gives no usable version, the check reads not assessed rather than failing the run.

What gets served

The attested feed serves a winget installer only once a sandbox verified it, with one exception on Community Edition, below. While a version a sandbox already attested is re-tested, Community Edition keeps serving the installer the earlier run attested; a dedicated instance withholds the version until the new run ends.

Per-box serving is a per-deployment switch, off by default. You turn it on by typed confirmation, after a census preview lists the endpoints that will stop being served and those that keep being served under an acceptance.

• With it off, the feed offers every endpoint in a ring the version’s attested installers, as it always has.
• With it on, the feed offers each endpoint only the one installer the platform named for its architecture and install scope, pinned to its SHA-256, and re-checks it on every request. An endpoint whose installer is not verified yet waits for verification instead: its endpoint page shows why, the sandbox is asked to run that installer, and nothing is uninstalled while it waits. An Arm endpoint waits too, because Arm installers cannot be verified yet; it is not given an x64 installer instead.

A dedicated instance serves only installers a sandbox verified. It has no way to accept an unverified one, so an endpoint that needs one waits.

On Community Edition an operator can record an unverified-installer acceptance for an installer no sandbox can test: per package and architecture, for up to 12 months, bound to the download sources the operator approved, and never for bytes a sandbox rejected. It serves only once per-box serving is on. Every endpoint that has the installer labels it unverified, accepted, and an acceptance that lapses or is revoked stops new serving without removing copies. An accepted installer always downloads from its vendor URL, never from your server’s byte store.

Without a detonation host nothing is verified, so by default no winget version is served. On Community Edition you can instead turn on one deployment-wide acceptance, off by default. With per-box serving on, endpoints are then served the installers of the versions you promote, from the download sources you approved, each labelled unverified, accepted. Enrolling a detonation host makes that acceptance inert.

Chocolatey and Scoop are different, and are covered on their own page.

Roles and policy

Every console user holds one of four roles: admin, catalog author, auditor or read-only. Catalog actions such as attest and promote are authorized by a built-in engine that implements a subset of Cedar. A read-only simulator runs saved test cases against the enforced policy set. You can switch the platform’s own privileges on and off, but writing your own Cedar policies is not available yet.

A promotion gate keyed on each version’s attestation tier ships off. Switched on, it asks for a typed confirmation before a version below attested-signed reaches a ring.

Desired state and the endpoint

The agent acts only on desired state carrying a valid HMAC. The HMAC is keyed by the one-time session secret the agent presented on that check-in. A missing or wrong HMAC rejects the whole response, and the agent runs that cycle as a no-op. This proves the response was not altered after it left the server. It does not prove who sent it, because the server holds the same secret.

The agent checks in every 15 minutes by default, sooner when the server wakes it. At each check-in it reconciles the endpoint toward its desired state.

On each endpoint the agent points winget at your feed and closes the public sources through Group Policy, then re-checks and repairs that fence; each check-in reports whether the endpoint is actually fenced. For winget, a fenced endpoint installs only an installer your feed offered it, pinned to its SHA-256, and winget refuses a file whose hash differs. With per-box serving on, that is the one installer the platform named for the endpoint: verified, or on Community Edition accepted. With it off, it is one of the version’s attested installers. The installer shim refuses --ignore-security-hash.

An endpoint whose fence is not applied, because you left it unfenced or Group Policy did not take, is not held to your feed. The agent still installs and upgrades the version its ring sets, but winget resolves that version from the public winget source, so the SHA-256 it checks is the one the public manifest names, not one your feed pinned. The console shows the endpoint as unfenced, and nothing installed this way reads verified.

A winget install or upgrade that a running app blocks a second time is recorded as deferred and retried later, not as another failure. The first refusal still counts as a failure. Operational detail, such as emergency stop and agent self-update, is on rollout operations.

What an endpoint’s label proves

The console labels each managed winget package on each endpoint with what is proven about the bytes it has. The label reads one of six things:

• verified: the endpoint recorded installing the package’s installer from your feed, and a sandbox verified that installer for its architecture. The label names both architectures, for example an x86 installer verified on the x64 sandbox.
• verified bytes, installer unknown: a byte check verified the bytes on the endpoint, but no install record names the installer they came from.
• unverified, accepted: the endpoint recorded installing an installer no sandbox verified, and an acceptance covers it. The label names who accepted it and until when. An acceptance is a decision, never evidence.
• unverified, not accepted: the same, with no acceptance in force.
• changed outside Attestree: the bytes changed after Attestree placed them, for example when a vendor’s own updater replaced them.
• no installer evidence: no install record names the installer, and no byte check verified the bytes.

An endpoint that waits for verification shows the wait instead.

An install record means one thing: the agent installed or upgraded the package with the installer your feed named for that endpoint, and winget checked its SHA-256. Only installs made with per-box serving on carry one. Installs from before per-box serving have no record, so they read verified bytes or no installer evidence until Attestree next installs or upgrades them.

Sign-in

• Dedicated instance. People sign in with Entra ID SSO. Each takes one of the four roles from the Attestree app role you assign in Entra. Beside Entra there is room for one local break-glass admin with mandatory TOTP. Which local accounts exist is set when the instance is deployed, never from the console.
• Community Edition. Local accounts, the same four roles, and TOTP two-factor with recovery codes, optional there. Entra sign-in is not built for it.

Alongside Intune, ConfigMgr or your RMM

Attestree replaces your third-party app-patching tool and sits beside your device manager. Intune, ConfigMgr or your RMM keep Windows Update, drivers, device settings, compliance and enrollment. Nothing is handed between them.

SIEM

Live forwarding to Sentinel or Splunk is not built. Today you load the signed audit bundle into your SIEM.