Get early access
SPECIFICATIONS SLSA BUILD TYPE

Attestree golden VHDX build type, v1

The SLSA build type for building a golden Windows image for the detonation sandbox. It tells a reader of the image’s SLSA provenance what its parameters and dependencies mean.

TYPE URI
https://attestree.com/build-types/golden-vhdx/v1
KIND
SLSA build type
USED AS
buildDefinition.buildType in the SLSA Provenance v1 statement slsa.in-toto.json, written beside the image by wep-golden-vhdx-sign
SIGNED BY
In an operator build, the provenance file is not signed itself; the image bytes are, with the operator’s ECDSA P-256 key ({vhdx}.sig)
EMITTED SINCE
The golden-image tools from platform 0.240.0
REPLACES
https://wep.dev/build-types/golden-vhdx/v1, the same meaning. Images signed before carry it.
PAGE UPDATED
2026-10-05

What is built

A golden VHDX: a Windows image, built from the operator’s own ISO, that the detonation sandbox boots to install a package. It carries the sandbox agent and the Syft binary. Attestree publishes no golden image; each operator builds one with the golden-image tools kit from a platform release and signs it with a local key. The provenance sits beside a golden-vhdx-build/v1 statement over the same subject.

The provenance

Its one subject is the VHDX, by file name, with the SHA-256 of its bytes.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "<file>.vhdx", "digest": { "sha256": "<SHA-256 of the VHDX bytes>" } }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://attestree.com/build-types/golden-vhdx/v1",
      "externalParameters": { "tag": "…", "ref": "…" },
      "internalParameters": { "runner": "…", "runId": "…" },
      "resolvedDependencies": [
        { "uri": "…", "digest": { "sha256": "…" }, "name": "…" }
      ]
    },
    "runDetails": {
      "builder": { "id": "operator://build-host" },
      "metadata": { "invocationId": "…", "startedOn": "…", "finishedOn": "…" }
    }
  }
}
FieldMeaning under this build type
externalParameters.tagThe image’s release label, for example golden-vhdx-v0.0.1.
externalParameters.refThe source ref the build names, for example refs/tags/golden-vhdx-v0.0.1.
internalParameters.runnerWhere it was built; operator-build-host in an operator build.
internalParameters.runIdThe build run; local in an operator build.
resolvedDependenciesThe pinned inputs the build consumed, each with a uri, a digest.sha256 and a name: the Syft binary, the Windows base image, and the PowerShell SDK. In an operator build the operator supplies this list.
runDetails.builder.idWho built it; operator://build-host in an operator build.
runDetails.metadatainvocationId (the run id), startedOn and finishedOn.

What the signature means

In an operator build the provenance is the operator’s own record, written by the sign tool; it is not signed on its own. The image is: <file>.vhdx.sig is the operator key’s ECDSA P-256 signature over the VHDX’s SHA-256, and the detonation broker checks it against the trust anchor you planted before it uses the image. The provenance’s subject digest ties it to those signed bytes. It does not make the operator’s inputs true; it records them.

A release pipeline that would attest this provenance to a published image with cosign exists but is dormant: no golden image has been published and none is planned.

How to verify

Verify the image signature with the kit’s wep-golden-vhdx-verify --vhdx <file>.vhdx --public-key <base64 SubjectPublicKeyInfo>, then check that the provenance’s subject digest equals the SHA-256 of the same VHDX, and that each dependency’s digest matches the input you hold.