The node OS is closed source, so you cannot audit its supply chain by reading a repository. What you can verify instead: every component is pinned by content hash at its source, the build is reproducible down to the root hash your node enforces at boot, and each image ships with an SBOM (software bill of materials, the list of every component and version in the image) that a scanner or an auditor can work from. A swapped source, a tampered build, or a modified image cannot reach a node undetected, and the list below states plainly what is and is not signed or attested. ## Every source is pinned by hash Each component in the image is pinned before the build ever runs. A pin records, at the time the component is chosen: - the version and the exact download URL, - the sha256 of every artifact fetched, - the declared license, - the end-of-life date, where the upstream publishes one, - the CPE identity (Common Platform Enumeration, the name CVE databases use for the component), - the distro source-package aliases (the Debian and Alpine source-package names), so scanners that match by distro package find it too. The build fetches each source and checks it against the pinned sha256. On a mismatch the build fails; there is no fallback fetch and no warning-and-continue path. A registry or mirror that starts serving different bytes for the same version stops the build instead of entering the image. The kernel gets one extra check before its hash is locked. The pin verifies the maintainer's PGP signature on the released tarball first, then records the sha256 of the bytes that signature covered. After that the hash is the gate like everywhere else, but the hash a release locks in is one a real kernel maintainer signed, not whatever a mirror happened to serve that day. Pins move deliberately, not automatically. When a component is held back from the newest upstream release, the hold is recorded on the pin with a reason, a named owner, and an expiry date. An expired hold is a finding, not a silent default, so a hold cannot stay in place after the reason for it is gone. ## The build is reproducible, and the seal proves it The [seal](/docs/hetzner/apalla/concepts/internals/syself-linux) turns the built filesystem into a read-only image plus a dm-verity hash tree (dm-verity is the kernel feature that checks every disk block against a hash before reading it). The build is reproducible: the same inputs produce the same bytes and the same dm-verity root hash. That root hash is the release's fingerprint. You can re-derive it from the released image and compare it to the value your node enforces on its kernel command line; [Verify node integrity](/docs/hetzner/apalla/security/verify-node-integrity) walks through the check. A supply-chain compromise anywhere in the pipeline, a swapped source, a tampered build, a modified image, changes the root hash and fails that comparison. ## Kernel modules carry a per-build signature The kernel runs with module signature enforcement, so it only loads modules signed by the key of its own build. The NVIDIA drivers are where this matters most: both driver branches (the current open-source branch and the legacy proprietary branch) are compiled against the exact shipped kernel tree and signed with that build's module-signing key, so whichever branch matches the detected GPU loads under lockdown. Be precise about what this key proves. It is generated inside the build, signs only the kernel modules, and is thrown away when the build ends. It says "this module came from the same build as this kernel", nothing more. It is not a release signature and not a trust anchor for the image; the image's integrity rests on the dm-verity root hash, not on this key. ## Bootstrap container images are pinned by digest A fresh node needs a set of container images before it can pull anything: the pause container, CoreDNS, the Cilium agent and its proxy on every node, and the control-plane images (kube-apiserver, kube-controller-manager, kube-scheduler, etcd, KubeGate, the cloud-controller-manager, the Cilium operator) on control-plane nodes. Each one is pinned by the sha256 digest of its multi-arch index, never by tag. A tag is mutable: `registry.k8s.io/kube-apiserver:v1.36.3` can serve different bytes tomorrow. The digest is what shipped, so a registry cannot swap the content after the fact; the pinned digest matches the version the cluster deploys, and the images are in the SBOM like every other shipped component. ## The SBOM is your evidence Since you cannot read the source, the SBOM is the artifact you audit. Each release writes one SPDX 3.0.1 document for the node image. The image is one sealed build with every role and hardware part baked in, the control-plane tooling, the GPU driver, and the `secure` VM runtime (see [Node and OS security](/docs/hetzner/apalla/security/node-and-os-security)); a node uses only the parts its role and hardware call for, so one document lists everything a node could run. SPDX is the ISO-standardized SBOM format. Releases ship SPDX 3.0.1 and nothing else: the security profile that carries the CVE triage below exists only in 3.0, and BSI TR-03183-2 accepts SPDX 3.0.1 and not 2.3. If your scanner cannot read 3.0 yet, use the standalone OpenVEX advisory and the clean SBOM in the release bundle rather than a downgraded document. Each component entry carries the identifiers a scanner matches on: the package URL, the CPE, the distro source-package aliases, the sha256 of every pinned artifact, and the declared license. Feeding the SBOM to a scanner such as grype or trivy produces the same findings as Syself's own scan of the pins, which is the point: you do not have to trust the vendor's summary, you can run the scan yourself. The SPDX 3.0.1 document also embeds the security profile: one vulnerability entry per known CVE, with a VEX assessment (Vulnerability Exploitability eXchange, a statement of whether a CVE actually affects this image) per CVE and component. A `not_affected` verdict carries its OpenVEX justification, for example that the vulnerable code path is compiled out of the kernel. A downstream scanner that honors VEX then suppresses the findings Syself already triaged instead of re-flagging them, and every suppression is visible and reviewable rather than silent. The same verdicts are also published as a standalone OpenVEX advisory, so re-triage updates the advisory without reissuing the SBOM. The SBOM covers the node image only; the images your workloads run are outside it. ## What is and is not signed or attested Knowing what is not signed matters as much as knowing what is. - **The OS image is not signed, by design.** The seal is keyless: there is no signing key, no signature, and no key file to trust or forge. Integrity is the kernel's dm-verity check on every block, and authenticity is the pinned root hash you can re-derive from the released image. See [Verify node integrity](/docs/hetzner/apalla/security/verify-node-integrity) for why this is a design choice, not a gap. - **Kernel modules are signed, narrowly.** The per-build module-signing key binds modules to their kernel so lockdown holds. It attests nothing about the release. - **There is no published build attestation.** Syself does not publish SLSA provenance or in-toto attestations for the image build. The reproducible seal is the substitute: instead of trusting a statement about how the image was built, you recompute the root hash from the released image and compare. - **Cached container images are digest-pinned, not signature-verified.** The build pulls them by digest, which fixes the bytes; it does not verify upstream cosign signatures. - **Your workload images are your responsibility.** Nothing in the platform signs or verifies the images your pods run. Enforce that yourself at admission; see [Verify image signatures](/docs/hetzner/apalla/security/verify-image-signatures). ## Related - [Verify node integrity](/docs/hetzner/apalla/security/verify-node-integrity): check the root hash your node enforces against the released image. - [Node and OS security](/docs/hetzner/apalla/security/node-and-os-security): the read-only OS and the full tamper-evidence model. - [Meet compliance requirements](/docs/hetzner/apalla/security/meet-compliance-requirements): how the SBOM and advisories map to audit evidence. - [Verify image signatures](/docs/hetzner/apalla/security/verify-image-signatures): require signed workload images in your clusters.