*Software Supply Chain Risk Matrix* for netboot.xyz-provided installations

[Zeor-Xain]

I would like to suggest adding a Software Supply Chain Risk Matrix to the netboot.xyz documentation for the operating system installations provided through the netboot.xyz menus, although the explicit recommendation for self-hosting is the rule to provide security.

The project already provides several important security mechanisms, including signed menu chaining when sigs_enabled is enabled. However, from a supply-chain perspective, there are different levels of trust depending not only on how a particular installation is delivered, but also how artifacts are transported and validated in transit.

For example, there is an important distinction between:

• an installation where netboot.xyz directly chains to an upstream distribution's official kernel/initrd;
• an installation where netboot.xyz downloads, extracts, modifies, or repackages upstream artifacts, and if this is entirely done within the GitHub pipeline;
• an installation where artifacts are generated by one of the netboot.xyz build pipelines and subsequently served by netboot.xyz infrastructure.

In addition to this, the transport layer itself (DNS, TLS, HTTP, and iPXE fetching mechanisms) is a critical part of the trust model and could be explicitly represented in the documentation.

It would therefore be useful if the documentation explicitly described the full trust chain for each installation option, including artifact provenance, transformation, and transport security.

---

Proposed matrix

Something along the following lines could be included for each supported installation:

Installation	Artifact	Original producer	Build/repackaging by netboot.xyz	Distribution source	Transport (DNS/TLS/HTTP)	Signature verification	Additional trusted parties
Example	Kernel	Upstream project	No	Upstream	HTTPS (upstream mirror)	Upstream signature	DNS provider, CA
Example	Initrd	Upstream project	Yes/No	Upstream/netboot.xyz	HTTP/HTTPS (varies)	Upstream/netboot.xyz	DNS provider, CA, GitHub
Example	ISO	Upstream project	Yes/No	Upstream/netboot.xyz	HTTPS (netboot.xyz infra)	Optional/varies	netboot.xyz infra, DNS, CA

---

The matrix could also identify:

1. Who produces the original artifact
2. Who builds or modifies it
3. Where it is hosted
4. Whether netboot.xyz modifies or repackages it
5. What signature/provenance verification is performed
6. How the artifact is transported (DNS resolution, TLS termination, HTTP/HTTPS, iPXE fetch behavior)
7. Which additional infrastructure or organizations must be trusted (including certificate authorities)
8. Whether the artifact can instead be obtained directly from the upstream project

---

Why this would be useful

This would not necessarily indicate that an installation is unsafe. Rather, it would make the security boundary and trust assumptions explicit across the entire delivery chain, including both provenance and transport.

For security-conscious users the important question is not only:

"Is this installation supported by netboot.xyz?"

but also:

"Which parties do I have to trust to obtain this particular installation, including during transport?"

The existing documentation already contains much of the information needed to answer this. For example, AGENTS.md documents signed menu chaining:

chain ${menu}.ipxe || goto error. Signature verification gates chaining when sigs_enabled is true.

The ubuntu-squash and build-pipelines projects also document parts of the artifact-generation process.

However, the transport layer (DNS resolution, TLS validation, HTTP fetching via iPXE, and potential redirection points) is not typically consolidated into the same trust model view, even though it is part of the effective attack surface.

A documented Software Supply Chain Risk Matrix would bring all of these elements together into a single, user-facing view of the trust relationships.

I believe this would be a valuable addition because netboot.xyz is often used precisely at the point where a machine transitions from an unconfigured state to running trusted software. Making the complete trust chain visible at that point would significantly improve the project's security documentation.

This could initially be a relatively small documentation page and expanded as additional installation methods are documented.