The Software Supply Chain: Everything That Affects How Code Runs
The software supply chain is everything that influences how software behaves. That spans direct library dependencies, transitive dependencies, build tools, containers, and the OS beneath them. In modern applications, that dependency tree runs deep. A vulnerability in a package three levels down still affects the software above it. Shipping software with no known vulnerabilities is the goal but not achievable, since CVEs surface after release. Describing the supply chain accurately gives consumers what they need to react when new disclosures hit.
Four Attestation Types Producers Should Provide
Leong breaks the producer’s job into four artifact types. Signatures are the floor: a cryptographic proof via cosign that the software came from the declared source and was not tampered with. Buoyant uses OIDC keyless signing and plans to migrate to Notary for finer key control. SBOMs list every dependency and version, in SPDX or CycloneDX format, generated with Syft or Snyk. Build attestations (SLSA provenance documents) record step-by-step how the artifact was built, which matters for FIPS compliance audits. VEX documents let producers declare a CVE affects a dependency but is not exploitable in their software.
OCI Referers: Immutable Images, Mutable Metadata
Bundling attestations inside the OCI image index creates a problem: adding a VEX document forces re-signing the entire package, making it appear the images changed. OCI v1.1 introduced referers to fix this. Attestations live in the registry as separate objects with a subject field pointing to the image they describe. The image index stays immutable. Consumers query the registry API to retrieve every referer for a given image, getting SBOMs, SLSA docs, and signatures in one call. Buoyant wrote a custom tool to repack OCI layouts, extracting bundled attestations and converting them into referers.
How Consumers Act on Supply Chain Data
Once attestations live in the registry, three consumer workflows activate. First, cosign verifies signatures, confirming the image came from the declared producer and was not modified. Second, grype takes the SBOM and cross-references every dependency against CVE databases. Run nightly, it flags newly disclosed vulnerabilities as they appear. Third, Kyverno enforces admission policies: a rule can require that any image from Buoyant carries a valid signature and a signed SPDX SBOM. Images that fail the check are blocked at pod creation. Buoyant publishes pre-built Kyverno policies in their docs to reduce setup effort for consumers.
Q&A
Consumers drop verification when a CLI command exceeds 3 lines. How do producers reduce friction? Leong recommends good documentation and pre-built Kyverno policies that consumers drop in without writing their own. ▶ 26:06
Are there GUI tools that summarize supply chain attestations for non-technical stakeholders? Leong is not aware of any, but says runtime policies reduce manual inspection by enforcing requirements automatically at admission. ▶ 27:17
When building on a public base image, does SBOM coverage include the base layers? Yes. SBOM tools pick up dependencies from all layers including the base, and SLSA build attestations record what layers the image built on top of. ▶ 28:05
Is Buoyant producing VEX documents today? Not yet. Leong says VEX generation is an area for future exploration. SBOMs are generated on every build and stored alongside the image in the registry as referers. ▶ 30:43
Notable Quotes
all this is just communication, right? Alex Leong · ▶ 23:00
it’s too suspicious too fishy something Alex Leong · ▶ 22:21
they get upset and they don’t do it Attendee · ▶ 25:48
Key Takeaways
- Sign every container with cosign as a baseline; unsigned images give consumers nothing to verify.
- SBOMs in SPDX format let consumers run continuous vulnerability scans with tools like grype.
- OCI v1.1 referers keep image digests stable when adding new attestations like VEX documents.
- Kyverno admission policies block pods from running if images lack required signatures or SBOMs.
About the Speaker(s)
Alex Leong is a software engineer at Buoyant and core maintainer of Linkerd, the open source service mesh for cloud native applications. Prior to Buoyant, she worked at Twitter on core API infrastructure. She enjoys roller derby, woodworking, and type safety.