Support OCI container image dependency resolution

[absol27]

Background

sbomit handles package registry downloads well. OCI images don't work this way. An image pull produces a manifest request followed by separate blob requests for each layer. Without the manifest, there's no way to know which layer digests belong to which image.

This also splits into two distinct concerns: what witness can see vs. what sbomit can resolve.

What Witness Captures

Signal	When	What it gives us
Network attestor	During build	HTTP exchanges — manifest requests + layer pulls for all base images, including intermediate stages
OCI attestor	Post-build	Layer digests, diff IDs, filesystem changes on the final image tarball

Everything inside a docker build stage is otherwise opaque to witness. The network attestor is our only window into what was consumed during the build itself.

What sbomit Needs to Resolve

To map layer digests to an image identity, sbomit needs the manifest. Two options:

1. Witness records the manifest response payload - sbomit gets it inline. Downside: attestations grow significantly; opt-in vs. default is an open question.
2. sbomit re-fetches the manifest from the URL in the network trace. Breaks entirely for private registries - sbomit won't have the auth tokens from the original build.

Option 1 is more robust. If payload recording is off, sbomit should at minimum flag unresolved image layer downloads.

Proposed Resolution Flow

1. Network attestor captures image pulls during the build (including intermediate stage base images)
2. Post-build, OCI attestor analyzes the final image - layers, diff IDs, per-layer filesystem changes
3. sbomit cross-references layer digests from the network trace against the final image's layer list to establish file-level provenance for unmodified base image content

Use an existing library (go-containerregistry / crane) rather than building custom parsers for OCI Spec and legacy Docker manifest _formats.

Based on input from @jkjell and @Vyom-Yadav

[Vyom-Yadav]

I just did something similar in another project. Here the main thing we need to do is validate the network traffic. I haven't played much with the OCI attestor, need to see what it does. But after parsing the manifest, we need to verify whether those layers with the same size and hash were present in the network trace output. I think that sanity check is quite important to flag something suspicious.

I would also add if there is some layer pulled that does not belong to any manifest downloaded, that's highly suspicious during any build and sbomit should flag that with red alert in some way.

Downside: attestations grow significantly; opt-in vs. default is an open question.

Let me check if there is something in the OCI registry format, etc. that I can use to only selectively record traffic (i.e. only the manifest). That might help establish the perfect middle ground. Or if not, witness can record that layer and add that to the attestation directly rather than adding every bit of data fetched.

[Jaydeep869]

Hi @absol27 , @jkjell , @Vyom-Yadav, and @stupendoussuperpowers, @Marc-cn I think that this is a complex architectural enhancement. Here is my proposed design and phased execution plan:

1. Safe OCI Ingestion via go-containerregistry
Instead of building custom parsers for the OCI Spec and legacy Docker manifests, I propose we natively integrate github.com/google/go-containerregistry. This library will allow us to parse local docker save tarballs and raw OCI layouts to extract the master manifest, configuration blobs, layer digests, and the uncompressed layer DiffIDs. Crucially, retrieving the manifest from the post build artifact offline entirely bypasses the issue of re-fetching manifests from private registries without auth tokens.

2. Evidence Based Layer Correlation (Base vs. App Layers)
We need to separate what was pulled from the network (the base image) from what was built locally. We can achieve this by mathematically mapping the extracted OCI DiffIDs against the layer digests captured in the Witness material and product attestations. Concurrently, by cross referencing the Witness network-trace attestations for registry HTTP GET exchanges, we can definitively isolate unmodified base image content from newly constructed local application layers.

3. Layer File Manifesting (No Virtual Filesystem Required)
Currently, our ecosystem resolvers (like PythonResolver and GoResolver) operate purely on arrays of FileInfo path structures, they do not require physics host disk access. Therefore, for the verified application layers, we do not need to build an expensive in-memory virtual filesystem. Instead, we can dynamically stream the uncompressed v1.Layer tarball headers, extract the file paths and hashes natively, and map them directly into []FileInfo objects. This allows the resolvers to extract package metadata seamlessly from the container layers without any physical extraction.

4. Base Image Resolution via Referrers API & Fallback
For the isolated base layers, the resolver will query the upstream registry using the OCI v1.1.0 Referrers API (utilizing the subject and artifactType fields) to natively fetch existing upstream SBOMs. If a native base SBOM is unavailable, we gracefully fall back to executing Syft against those specific isolated base layers. This dual approach ensures we strictly maintain sbomit's core trust model, where deterministic attestation evidence always overrides scanner inference during merge conflicts.

I would love to get your inputs on this architectural approach. Let me know what you think!

[IITI-tushar]

Hey @absol27 @Vyom-Yadav this is a really interesting issue. I was going through the discussion and I think separating network evidence from post-build OCI artifact evidence is the right direction.

One thing that may help is introducing a clear confidence model in sbomit output, for example:

• Verified -> manifest + layers both matched from attestations
• Partially Verified -> layers seen but manifest unavailable
• Inferred -> fallback methods like Syft/manual resolution
• Suspicious -> pulled layers with no matching manifest or mismatched digests

This may help users understand trust level instead of treating all resolved dependencies equally.
It also seems build time manifest capture is the stronger source of truth, especially for private registries where later re-fetching may fail due to expired credentials, network restrictions or mutable tags returning newer manifests.

I also like the suggestion of using go-containerregistry instead of custom parsing, since it keeps implementation simple & more maintainable.

Happy to explore this issue further and help with implementation/testing if needed.

[Vyom-Yadav]

Please don't completely rely on Claude et. al. go-containerregistry won't work out of the box, it doesn't expose an API for parsing OCI registry URLs, we will have to do that manually. Manifest parsing would be done using something like https://github.com/containers/image.

[Jaydeep869]

Hey @Vyom-Yadav , I will make sure to use less AI for this and will look into manual parsing for OCI registry URLs and explore using containers/image for manifest handling as you suggested.

[Vyom-Yadav]

I'm planning to work on this as I've done fairly similar tasks quite a few times. Also, I need to make some changes to network tracing in witness for this. But yes, AI is good, but make sure you are driving the inputs, not AI.

[Jaydeep869]

I align with your point.
I will make sure I’m driving the approach rather than relying on AI. Looking forward to your changes on the network tracing side.