## System Architecture Diagram: Secure Build Attestation Pipeline ### Overview This image is a technical system architecture diagram illustrating a secure, verifiable software build pipeline. The process uses a Trusted Execution Environment (TEE) and a hardware trust anchor to generate cryptographic attestations linking a built software artifact to its source code commit. The diagram details the flow of control, data, and cryptographic proofs between various components, from build initiation to final verification by an end-user. ### Components/Axes The diagram is organized into several key regions and components: **1. External Entities & Triggers (Outside the main dashed box):** * **Top-Left:** `build trigger` (icon of a person with a wrench). Arrow labeled **1** points to the Instance manager. * **Top-Right:** `Hardware Trust Anchor (e.g., AWS Nitro Card)` (green box). Receives attestation request (arrow **7**). * **Right Side:** `RHP (e.g., GitHub)` (cylinder icon). Source code repository. Arrow **4** shows download of repository. * **Bottom-Left:** `Log` (cylinder icon). Receives published attestation document `AT` (arrow **9**). * **Bottom-Right:** Artifact repository (cylinder icon). Receives published artifact `A` and attestation `AT` (arrow **9**). * **Bottom-Center:** End-user/verifier (icon of a person with checkmark/cross). Performs steps **10** and **11**. **2. Host Instance (Large dashed box labeled `Host instance (e.g., AWS EC2)`):** * **Left Component:** `Instance manager` (vertical rectangle). Orchestrates the build process. * **Central Component:** `TEE (e.g., Nitro Enclave)` (green shaded area). The secure environment where the build occurs. * **TEE Sub-component:** `Enclave client` (vertical rectangle). Manages the build runner. * **TEE Sub-component:** `Sandbox (containerd/gVisor)` (pink shaded area within the green TEE). Isolates the untrusted build process. * **Inside Sandbox:** `Build runner` (white box). Executes the trusted parts of the build. * **Inside Sandbox:** `Untrusted build process` (pink box containing three smaller white boxes connected by arrows). Performs the actual compilation/build steps. **3. Data Elements & Labels:** * **CT:** Commit Hash (reported by Build runner in step **5**). * **A:** Artifact Hash (reported by Untrusted build process in step **6**). * **AT:** Attestation Document (result of step **7**, shared in step **8**, published in step **9**). * **PCR0-2:** Platform Configuration Registers (part of the attestation in step **7**). * **.eif:** File format (likely Enclave Image Format) used to start the enclave (step **2**). ### Detailed Analysis The process flow is explicitly numbered from **1** to **11**: 1. **Build Trigger:** An external trigger initiates the process. 2. **Start Enclave:** The Instance manager starts the Enclave client within the TEE, providing a `.eif` file. 3. **Start Build Runner:** The Enclave client starts the Build runner inside the sandbox. 4. **Download Source:** The Build runner downloads the repository (including build files) from the RHP (e.g., GitHub). 5. **Report Commit Hash (CT):** The Build runner reports the commit hash `CT` back to the Enclave client. 6. **Report Artifact Hash (A):** The Untrusted build process, after completing its steps, reports the final artifact hash `A` to the Enclave client. 7. **Attestation:** The Enclave client requests an attestation from the Hardware Trust Anchor over the set `{PCR0-2, CT, A}`. This results in the creation of a signed attestation document `AT`. 8. **Share Attestation:** The attestation document `AT` is shared from the Enclave client back to the Instance manager and also to the Untrusted build process. 9. **Publish:** The Instance manager publishes `AT` to a Log. The Untrusted build process publishes the final artifact `A` along with its attestation `AT` to an artifact repository. 10. **Download & Claim:** An end-user downloads the artifact `A` and the associated claim: `"A was built using PCR0-2 from CT"`. 11. **Verify Proof:** The end-user requests and verifies the proof for the claim against the Log (and optionally checks for endorsements and revocations). ### Key Observations * **Trust Boundary:** A clear trust boundary is established by the green `TEE` box. The `Untrusted build process` is further isolated within a `Sandbox` inside the TEE. * **Critical Data Flow:** The Enclave client acts as a central hub, collecting `CT` and `A` before requesting the attestation `AT`. The attestation cryptographically binds the hardware state (`PCR0-2`), the source (`CT`), and the output (`A`). * **Dual Publishing:** The attestation `AT` is published to a separate, immutable Log (step **9**, left) for independent verification, while the artifact `A` and its attestation are published together for distribution (step **9**, right). * **Verification Loop:** The process concludes with an external verifier (steps **10 & 11**) who can independently check the claim by retrieving the proof from the Log, completing the chain of trust. ### Interpretation This diagram depicts a **verifiable build system** designed to provide strong cryptographic guarantees about software supply chain integrity. The core innovation is the use of a hardware-backed TEE to create an unforgeable link (`AT`) between the source code commit (`CT`) and the resulting binary (`A`). * **What it demonstrates:** It shows how to solve the "trusted build" problem. Even if the build environment is compromised, the attestation from the hardware trust anchor proves that the specific artifact `A` was generated from the specific source `CT` within a measured, known environment (`PCR0-2`). * **Relationships:** The flow is linear and causal. Each step depends on the successful completion of the previous one. The Instance manager orchestrates, the TEE executes securely, and the external repositories and logs provide persistence and verification points. * **Notable Design Choices:** The separation of the "Build runner" (trusted, reports `CT`) from the "Untrusted build process" (untrusted, reports `A`) within the sandbox is a key security pattern. It acknowledges that parts of the build toolchain may be untrustworthy but contains their impact. Publishing the attestation to a separate log enables transparency and third-party auditing. * **Implication:** This architecture is foundational for high-assurance software distribution, allowing users to verify that the software they are running matches the public source code and was built in a controlled manner, mitigating risks of supply chain attacks.