Software Supply Chain Architecture Diagram: SBOM, SLSA, and Sigstore (2026)

Software supply chain attacks — where adversaries compromise upstream dependencies, build systems, or artifact registries rather than attacking the final application directly — have become the dominant threat vector for production systems. The SolarWinds, XZ Utils, and 3CX attacks demonstrated that even well-secured applications are vulnerable when the build pipeline or third-party packages are compromised.

A software supply chain architecture diagram maps the full chain from source code through build, test, signing, and deployment — showing where security controls are applied, how artifact integrity is verified at each stage, and where the trust boundaries lie. This guide covers the key components and how to diagram them clearly for your team's security reviews, compliance documentation, and architecture discussions.

The software supply chain: what to diagram

A comprehensive software supply chain architecture diagram covers five layers, each representing a distinct stage where vulnerabilities can be introduced or controls can be applied:

• Source layer — version control (GitHub, GitLab), branch protection rules, signed commits, code owners, and mandatory pull request reviews. This is where developer identity and code authenticity are established
• Build layer — the CI/CD system (GitHub Actions, Jenkins, Tekton), build isolation (ephemeral runners, hermetic builds), build provenance attestation (SLSA), and the artifacts produced (container images, binaries, packages)
• Dependency layer — package managers (npm, pip, Maven, Go modules), private registries or proxies (Artifactory, Nexus), dependency pinning and lock files, and SBOM generation that inventories all transitive dependencies
• Artifact layer — the container registry (ECR, GCR, Docker Hub), artifact signing (Sigstore/Cosign), vulnerability scanning (Trivy, Grype, Snyk), and the admission controllers that enforce image signature verification before deployment
• Deployment layer — the runtime environment (Kubernetes with admission webhooks, OPA Gatekeeper policies), runtime monitoring (Falco, eBPF-based detection), and the policy enforcement points that block unsigned or vulnerable artifacts from reaching production

Key standards and tools to represent

SBOM (Software Bill of Materials)

An SBOM is a structured inventory of all components, libraries, and dependencies in your software. It is the foundation for vulnerability management — you cannot know if you're affected by Log4Shell or XZ Utils without knowing which components your software contains.

In your diagram, show the SBOM generation step as part of the build pipeline — either post-build (scanning the compiled artifact) or during build (capturing dependencies from the lock file). Common SBOM formats are SPDX (Linux Foundation standard, preferred for compliance) and CycloneDX (OWASP standard, preferred for security tooling). Show the SBOM being stored alongside the artifact in the registry and being consumed by the vulnerability scanning and policy enforcement stages.

SLSA (Supply-chain Levels for Software Artifacts)

SLSA (pronounced “salsa”) is a security framework that defines four levels of build integrity assurance. In your diagram, show the SLSA provenance attestation generated by the build system — a signed statement that identifies what produced the artifact (the build system), what inputs were consumed (source commit, build config), and what outputs were produced (artifact digest).

SLSA levels in your diagram context:

• SLSA 1 — provenance exists (most teams can achieve this)
• SLSA 2 — provenance is signed by the build service
• SLSA 3 — build runs on hardened, audited infrastructure
• SLSA 4 — hermetic, reproducible builds (hardest to achieve)

Show the SLSA attestation flowing from the build step to the artifact registry, then being verified by deployment-time admission controllers.

Sigstore and Cosign

Sigstore is an open-source project that provides keyless artifact signing using short-lived certificates backed by OIDC identity. Cosign is the command-line tool for signing and verifying container images. In your diagram, show the Sigstore signing step after the image is built and pushed — the CI system authenticates to Sigstore Fulcio (the certificate authority) using its OIDC token, gets a short-lived signing certificate, signs the image, and records the signature in Rekor (the transparency log).

On the verification side, show Kubernetes admission webhooks (using tools like Sigstore Policy Controller or Kyverno) checking that any image being deployed to production has a valid Sigstore signature matching the expected identity (e.g., must be signed by the GitHub Actions workflow from your organization's repository).

Prompt templates for software supply chain diagrams

Complete supply chain pipeline

Dependency and SBOM management architecture

Compliance frameworks that require supply chain diagrams

Several compliance frameworks now explicitly require software supply chain documentation:

• Executive Order 14028 (US) — requires SBOM for software sold to the US federal government. NIST SP 800-218 (SSDF) provides the secure software development practices
• EU Cyber Resilience Act (CRA) — requires manufacturers of products with digital elements to provide SBOMs and maintain vulnerability disclosure programs. Effective 2027
• NIS2 Directive (EU) — requires supply chain security risk management for critical entities. See the NIS2 architecture diagram guide
• FedRAMP High — US federal cloud systems require SBOM and supply chain risk management as part of the authorization process
• SOC 2 Type II — change management controls often need to demonstrate artifact integrity verification. See SOC 2 architecture diagrams

For each framework, your supply chain architecture diagram serves as the visual evidence of your controls — auditors can verify that each required control (SBOM generation, signing, verification, vulnerability scanning) has a corresponding step in your documented pipeline.

Frequently asked questions about software supply chain architecture

What is a software supply chain architecture diagram?

A software supply chain architecture diagram is a visual map of the processes, tools, and security controls that govern how software is built, packaged, signed, scanned, and deployed. It shows the full chain from source code repository through build system, dependency management, artifact registry, and into the production runtime — with annotations showing where integrity checks, signing, and vulnerability scanning occur at each stage.

What is the difference between SBOM, SLSA, and Sigstore?

They address different parts of supply chain security: SBOM (Software Bill of Materials) answers “what is in this software?” — it inventories all components and dependencies. SLSA (Supply-chain Levels for Software Artifacts) answers “how was this software built?” — it attests to the integrity of the build process and environment. Sigstore answers “who authorized this artifact?” — it provides cryptographic signing and verification of artifacts tied to verifiable identities. All three work together: SBOM provides the inventory, SLSA attests the build, and Sigstore proves the artifact came from a trusted builder.

Which vulnerability scanners should appear in a supply chain diagram?

Common scanners to represent: Trivy (open source, scans container images, filesystems, and SBOMs — most popular in Kubernetes environments), Grype (Anchore's open source scanner, good SBOM integration), Snyk (commercial, strong developer IDE integration and developer-facing UX), DependencyTrack (continuous SBOM monitoring with CVE feed integration — not a scanner itself but consumes SBOM output), and OWASP Dependency-Check (Java/JVM focused, open source). Show which scanners are applied at build time (blocking gates) versus post-deployment (continuous monitoring).

Related guides: DevSecOps architecture diagrams, GitHub Actions architecture diagram, zero trust architecture diagram, and threat modeling diagram.