Attestree

Attestiertes winget für Windows-Flotten — signierte Provenance beim Ingest

.NETwingetin-toto / SLSASBOM / CycloneDXSigstorePostgreSQLDockerAstro

Privates Repository

Problem

Die meisten Windows-Umgebungen installieren Pakete direkt aus der öffentlichen Quelle und entdecken Probleme erst, wenn Tage später ein Scanner über einen Endpunkt läuft. Bis dahin läuft das Artefakt bereits flottenweit, SBOMs sind ein nachträglicher Gedanke, Attestierungen fehlen, und die Supply-Chain-Story lautet „wir vertrauen dem CDN von Microsoft". Tanium, Defender for Cloud, Snyk und vergleichbare Werkzeuge scannen ausgerollte Binaries im Nachhinein. Niemand prüft die Katalog- und Distributionsschicht, bevor deployt wird.

Ansatz

Attestree dreht die Reihenfolge um: winget install, aber mit Beleg. Jedes Paket wird beim Ingest attestiert, nicht nach der Installation. Die Signatur des Installers und die Kontinuität des Publishers werden geprüft, das Paket wird in einer Sandbox detoniert, aus dem tatsächlichen Installationsverhalten entsteht eine CycloneDX-SBOM, und Policy-as-Code entscheidet. Aufgenommene Artefakte tragen ein signiertes in-toto-Statement mit SLSA-v1-Provenance, das ein Auditor mit einem öffentlichen Schlüssel verifiziert. Endpunkte sind anschliessend auf den eigenen, attestierten winget-Feed des Betreibers eingezäunt und erhalten Pakete über Groups und Rings. Bei der Installation prüft der Agent erneut den exakt freigegebenen Hash.

Architektur

Das System hat zwei Oberflächen. Eine Control Plane mit Endpoint-Agent betreibt Ingest Gate, Attestierung und Deployment. Die öffentliche Eingangstür bilden Marketing-Website und Open-Core Community Edition.

Ingest Gate

Jedes Paket durchläuft Fetch, Prüfung von Installer-Signatur und Publisher-Zertifikat, Sandbox-Detonation, eine beobachtete CycloneDX-1.6-SBOM und eine Policy-as-Code-Entscheidung. Das Ergebnis wird als in-toto-Statement signiert (ECDSA P-256). winget ist live, und Chocolatey wird unter derselben Control Plane verwaltet. MSI/MST-Transforms, Treiber-Rings und weitere Paketmanager stehen auf der Roadmap.

Eingezäunter Feed, Groups × Rings

Endpunkte installieren aus der eigenen, spezifikationskonformen winget-REST-Quelle des Betreibers, gepinnt auf den freigegebenen SHA-256; ein normales winget install erreicht nie das öffentliche Repository. PC-Groups bestimmen, was ein Gerät betreibt; Rings (canary → pilot → broad → all) bestimmen, welche Version. Ein Rollback führt auf jede frühere Version zurück. Ein scheiternder Rollout erzeugt einen Rollback-Vorschlag, den der Operator bestätigt, statt eigenmächtig zu handeln.

Unbeaufsichtigte Updates mit Halt-Queue

Eine optionale Pipeline nimmt neue winget-Versionen auf, detoniert sie und befördert sie Ring für Ring. Sie stoppt zur Prüfung, wenn sich das Signaturzertifikat eines Publishers ändert oder ein Installer unsigniert eintrifft. Genau dieses Signal erzeugt ein gekapertes Release.

Control-Plane-Stack

.NET: Native-AOT-Installer-Shim und ein selbstaktualisierender Endpoint-Agent, ausgerollt über dieselben Rings
Docker + PostgreSQL: Server-Image mit Postgres-Sidecar; Per-Tenant-Scope als erstklassige Invariante
Offene Formate: in-toto, SLSA v1, CycloneDX 1.6 (Syft); Sigstore wird unterstützt, ist aber nicht erforderlich
Flotten-CVE-Index: selbst gehostet, gleicht beobachtetes Inventar mit cvelistV5 und CISA KEV ab, mit Offline-Bundle für Air-Gapped-Hosts

Technische Schlüsselentscheidungen

Beim Ingest attestieren statt nach der Installation scannen

Der strukturelle Wedge: Attestree besitzt die Katalog-/Distributionsschicht und prüft vor dem Deploy. Ohne Pre-Deploy-Attestierung ist „wir inventarisieren es" nur ein schöneres winget list.

Eine beobachtete SBOM, keine deklarierte

Die SBOM entsteht aus dem, was der Installer in der Sandbox tatsächlich getan hat, nicht aus dem Manifest des Publishers. Eine Ingest-SBOM ist eine Beobachtung, und genau das macht sie signierwürdig.

Drei Durchsetzungspunkte

In einer Windows-Flotte ist der Endpunkt der tragende Durchsetzungspunkt. Die Richtlinie ist deshalb keine einzelne Pipeline-Prüfung: Das Ingest Gate blockiert vor dem Katalog, die Reconciliation erkennt Drift gegenüber dem deklarierten Zustand, und der Agent prüft Signatur, Hash und Richtlinie bei der Installation erneut.

Den destruktiven Schritt bestätigt ein Mensch

Die Automatisierung schlägt vor, Menschen genehmigen. Rollback-Vorschläge sind bestätigungspflichtig und standardmässig deaktiviert. Die Update-Pipeline stoppt in einer Review-Queue, statt zu raten, wenn sich die Signaturidentität eines Publishers ändert.

Open-Core mit erzwungener Lizenzgrenze

Der Installer-Shim und sein IPC-Vertrag sind Apache-2.0; die Plattform ist Closed-Source. Die Lizenzgrenze wird mechanisch im Build durchgesetzt, sodass Closed-Source-Code nicht versehentlich umlizenziert werden kann. Die kostenlose Community Edition läuft selbst gehostet auf Docker Compose ohne Cloud-Abhängigkeit, wird als Sigstore-cosign-signierte Images ausgeliefert und bringt Rollen, TOTP-Zwei-Faktor und Betriebs-Runbooks mit.

Öffentliche Website

Die Marketing-Website unter attestree.com ist eine separate, vollständig öffentliche Oberfläche: statischer Astro-Build mit Tailwind + MDX, deployt auf Cloudflare Pages mit Preview-Deploy pro PR. Die Warteliste läuft als Same-Origin Cloudflare Pages Function mit D1 in einer EU-Jurisdiktion und gehärteter Turnstile-Verifikation. Die Website-Texte werden bei jedem Plattform-Release neu abgeglichen, mit expliziter Trennung zwischen ausgeliefert und Roadmap; unbelegte Aussagen werden entfernt statt relativiert. Die Build-Security-Baseline umfasst SHA-gepinnte Actions, least-privilege Token, committetes Lockfile, Dependabot, ein npm audit CI-Gate und security.txt.