Back to Projects

Attestree

Supply-chain provenance for Windows fleets — SBOM at ingest

.NETwingetSBOM / CycloneDXSigstoreSLSAWDACDockerAstro

Private Repository

Problem

Most Windows shops install packages straight from the public source and discover problems only after a scanner runs against an endpoint days later. By then the artifact is on a thousand machines, SBOMs are an afterthought, attestations are missing, and the supply-chain story is "we trust Microsoft's CDN." Tanium, Defender for Cloud, Snyk, and their peers scan deployed binaries after the fact — nobody inspects the catalog and distribution layer before deploy.

Approach

Attestree inverts the order: provenance is verified at ingest, not after install. Every package fetched from a source is checked against policy — provenance, SBOM, SLSA level, CVE severity, license — before it reaches a fleet node. Rejected artifacts never make it to canary; admitted artifacts carry signed receipts an auditor can verify with a public key. Layered on top: ring-promoted deployment with auto-rollback, and a unified attested inventory across every package manager.

Package Sources winget · MSI/MST · npm · pip · drivers · firmware INGEST GATE — POLICY EVALUATION Provenance · SBOM · SLSA level CVE severity · License allow-list Rejected admit SIGNED ATTESTATION Verifiable receipt · provenance record RING PROMOTION Canary → Pilot → Broad → All · auto-rollback WINDOWS FLEET ENDPOINTS Agent + installer shim (OSS, Apache-2.0) ATTESTED INVENTORY Cross-package- manager rollup CVE matrix vs NVD / OSV / MSRC Signed export for auditors CONTROL PLANE .NET · PostgreSQL Community Edition (Docker) Marketing site (Astro · CF Pages)

Architecture

The system has two surfaces — a control plane with an agent for the ingest gate, attestation, and deployment, and a public front door of marketing site plus an open-core community edition.

Ingest Gate

Packages pass through a policy gate: fetch, provenance check against trusted roots, SBOM verification (CycloneDX), policy evaluation (minimum SLSA level, CVE ceiling, license allow-list), and finally the admit/reject decision.

Ring-Promoted Deployment

Admitted artifacts roll out through promotion rings — canary, pilot, broad, all — rather than fleet-wide at once, with operator-editable soak floors and auto-rollback on a failure signal. A bad package's blast radius stays small.

Control Plane Stack

  • .NET / Windows — AOT-compiled agent and installer shim; server on Windows Server 2025
  • PostgreSQL — operational store with per-tenant scope as a first-class invariant
  • OCI registries — distribution layer for artifacts

Key Technical Decisions

SBOM at ingest, not post-install scan

The structural wedge: Attestree owns the catalog/distribution layer and verifies before deploy. Without pre-deploy attestation, "we inventory it" is just a fancier winget list.

Signed, verifiable receipts

Every admission produces evidence: a receipt recording verified provenance, the attached SBOM, and the SLSA level, verifiable against a public key. That makes it possible to answer, months later, who approved an artifact and on what basis. Managed signing keys today, Sigstore-rooted verification on the roadmap.

Cross-package-manager inventory

A unified, attested inventory instead of reconciling per-tool outputs, keyed by canonical artifact identity, with a CVE matrix against NVD / OSV / MSRC and a signed export the auditor reads independently.

Open-core with an enforced license boundary

The installer shim and its IPC contract are Apache-2.0; the platform is closed-source. The license boundary is enforced mechanically in the build — closed-source code cannot be relicensed by accident. A cosign-signed community edition ships as a Docker image for self-hosting.

Public Site

The marketing site at attestree.com is a separate, fully public surface: a static Astro build with Tailwind + MDX, deployed to Cloudflare Pages with a preview deploy per PR. The waitlist runs as a same-origin Cloudflare Pages Function backed by D1 in an EU jurisdiction with Turnstile bot defense. The build-security baseline covers SHA-pinned actions, least-privilege tokens, a committed lockfile, Dependabot, and an npm audit CI gate.