Supply Chain Security: Is an OCI registry enough?

Supply chain security is all about trust—and how easily it can be broken. In the modern development world, we don’t just write code; we assemble it. Every time you run npm install or docker pullYou aren't just inviting one guest into your house; you’re inviting everyone they’ve ever met.

Supply chain security is rapidly becoming the most prominent attack vector after phishing. Why? Because it offers attackers the biggest "bang for their buck." One Attack, Thousands of Victims. The math is simple and terrifying:

• Traditional Attack: Hack one company —> get one company.

• Supply Chain Attack: Hack one dependency —> get everyone using it.

We’ve seen this play out in high-profile disasters like SolarWinds, Log4j, and the cleverly named Shahi Hulud (a "Dune" reference for a serious vulnerability). As the saying goes:

"Software security is only as strong as its weakest link, and in a modern ecosystem, that link is often a library you didn't even know you were using."

Now that we’ve established the "why," let’s look at the "how." How do we defend against an attack surface that feels infinite?

---

The Core Challenges of Supply Chain Security

1. Continuous Scanning: Vulnerabilities Don't Have a Schedule

A vulnerability isn't a "once a week" problem. When a critical CVE (Common Vulnerability and Exposure) is announced, the clock starts ticking. If your artifacts aren't being scanned continuously, you're essentially flying blind. You need to know immediately if a newly discovered flaw affects your production images.

2. The Zero Trust Artifact

Similar to Zero Trust as applied to users and devices, we must apply "never trust, always verify" to our software. We need mechanisms to verify that an artifact is exactly what it claims to be and comes from a trusted source. If an image isn't signed, how do you know a malicious actor didn't swap it out in the middle of your CI/CD pipeline?

3. Metadata: The "Paper Trail" of Software

To secure a supply chain, you need more than just the code. You need metadata: SBOMs (Software Bill of Materials), SLSA attestations (provenance), and VEX (Vulnerability Exploitability eXchange) documents. The challenge is storing and querying this data as easily as you query an API.

---

Enter the Hero: Zot

To solve these challenges, we’re looking at one of the powerful tools: Zot

Zot: The OCI-Native Powerhouse

Zot isn't just another registry; it's a production-ready, OCI-native container image registry. It conforms strictly to OCI Distribution and Image Specifications, making it incredibly lightweight and compatible.

CVE Scanning in Zot

• The Engine: Zot supports scanning CVEs backed by Trivy, relying on the database maintained by Aqua Security.

• The Workflow: As soon as you push an image, Zot provides a neat UI to display the CVEs and their corresponding criticality levels.

• Automation: Zot supports automatic background scanning every 15 minutes (a hardcoded value) and on-demand scanning via its API or UI.

Source Verification Support

Zot supports tools like Cosign and Notation to verify images using public keys or certificates uploaded by the user.

Note: Currently, Zot lacks support for keyless signing. This is worth noting because keyless is the default and encouraged method for Cosign, utilizing OIDC identities instead of static keys.

---

Enter the side-kick GUAC: The Graph for Understanding Artifact Composition

If Zot is where you store your stuff, GUAC is the "brain" that understands how everything is connected.

GUAC doesn't replace your security scanners or your registry (like Zot). Instead, it "ingests" data from them. It pulls in:

• SBOMs

• Vulnerabilities (from OSV)

• Attestations (from Cosign or SLSA)

• Scorecards (from OpenSSF)

GUAC then maps out the relationship between software so that you can fully understand your software security position. It also lets you query the metadata.

CVE Scanning in GUAC

• The Source: GUAC relies on OSV (Open Source Vulnerability), which identifies packages via pURL (Package URL).

• Modes: GUAC supports CVE scanning in both Polling mode (continuous) and Non-Polling mode (by adding vulnerability during SBOM ingestion once)

• GUAC Visualizer: GUAC supports visualizing complex graphs via the GUAC visualizer to make them easier to understand.

  

  Image Source: https://docs.guac.sh/guac/

• The Comparison: While pURL is a modern, clean format, it can sometimes fall short compared to Trivy, used by Zot. Trivy uses different heuristics and deep-fingerprinting that often catch edge cases pURL might miss. However, both tools are extensible, so these aren't "hard" limitations. GUAC is designed to ingest the output of scanners like Trivy and populate its graph.

Source Verification Support

GUAC does not support verifying Artifacts by cosign or Notation.

---

SLSA Attestations and VEX Documents

In the world of supply chain security, an artifact is only as good as the "paperwork" that follows it.

• SLSA Attestations: SLSA (Supply-chain Levels for Software Artifacts) is a security framework. An attestation is a signed document that provides provenance—the definitive answer to the question: "Where did this artifact come from, and how was it built?"

• VEX (Vulnerability Exploitability eXchange): VEX documents are essentially "status updates" for vulnerabilities. They allow a maintainer to say, "Yes, this CVE is technically in my code, but it is not exploitable in this specific product," preventing unnecessary panic and fire drills.

Zot’s Generic Support via OCI Referrers

Zot supports these documents generically using the OCI Referrers API. Zot follows the OCI spec to link "referrers" (like an SBOM or a VEX file) to a "subject" (your container image), and allows for querying the deep metadata relationship.

---

Querying the Supply Chain: GraphQL to the Rescue

Both Zot and GUAC utilize GraphQL APIs because software relationships are rarely "one-to-one." They are many-to-many: one vulnerability can affect thousands of images, and one image can contain hundreds of packages.

How to Query Your Data

• Zot:

  zli (CLI): Best for rapid-fire security checks. You can quickly see which images are "poisoned" by a new CVE: Example: zli cve affected CVE-2024-1234 --config my-registry

  GraphQL Playground: Accessible at http://<zot-host>/v2/_zot/debug/graphql-playground. It provides an interactive IDE with IntelliSense, making it easy to browse the schema and test queries before automating them.

  Predefined vs. Custom: Zot includes high-value built-in queries like CVEListForImage (get all flaws for a specific tag) and DerivedImageList (find every image built on top of a specific base layer)

• GUAC:

  GUAC uses guacone (it’s a CLI tool) and even provides a GraphQL playground (typically on your localhost) where you can interactively explore the graph.

Can I write custom queries? Yes! This is the beauty of GraphQL. You aren't stuck with the "canned" reports provided by the developers. You can write custom queries to answer hyper-specific questions like: "Which images in my 'Production' namespace are using a version of openssl that was built without a SLSA attestation?

Summary Table

Conclusion

Zot is the Warehouse - it’s where your artifacts live securely. It raises the bar for supply chain security with features like querying metadata, which is often a limitation in registries like AWS ECR and other managed registries.

GUAC is the Intelligence Agency - it doesn't care if your artifact is a container image in Zot or a raw binary in an S3 bucket; it consumes the metadata to help you understand your risk. Because GUAC is OCI-agnostic, it can map dependencies for your Go binaries and Python packages just as easily as it does for your Docker images.

So, is the OCI registry enough for supply chain security? Both have taken different approaches to solve some common supply chain security challenges, but they make a good pair together, Zot and GUAC. They turn "blind trust" into "verifiable security."