Chiseled image scanning strategy: in-image metadata *and* registry-attached SBOMs

[richlander]

We are in the process of deciding what to do with chisel manifests. We should make chisel manifests work well for existing workflows (image scanning) and also consider additional workflows (registry-attached SBOM scanning).

Context:

• Update Chisel to v1.0.0 #5973
• Attach SBOMs to images in the container registry #5515
• Support Ubuntu Chisel manifests as an sbom input microsoft/sbom-tool#811

In general, we try to provide uniform experiences for the images we publish. If a user moves from Alpine to Ubuntu (or vice versa), then the only thing that changes should be the OS. There is significant benefit to this model. In this context, the way that users scan images shouldn't need to change as they adopt Ubuntu chiseled images.

At present, the chiseled images we produce satisfy this model. However, the proposal to switch to registry-attached SBOMs for chiseled image scanning would break that. At the same time, the in-image data we currently include is a temporary measure.

Proposal:

• Include package data (in APT format), derived from the chisel manifest
• Publish registry-attached SBOMs, derived from the chisel manifest

I think two things are important:

• Maintain uniform scenarios across image types
• Generate all scanning-related assets (for Ubuntu chiseled) from chisel manifests ("the one true source") with the intent that the results are always identical.

[lbussell]

The way I see this is:

1. Publishing SBOMs for our images and supporting it as the official vulnerability scanning approach should be the end-goal.
2. We currently use chisel-wrapper to create the dpkg status file (what you refer to as package data or in-image metadata).
3. We should be able to continue using chisel-wrapper to create dpkg status file at the same time as publishing SBOMs.
4. Publishing SBOMs and generating the dpkg status file should only be an intermediate state, for compatibility with scanning tools that don't yet support SBOMs.

Since we already have a solution for producing dpkg status files, it doesn't make sense for us (.NET) to invest in another approach for translating Chisel manifests to dpkg status files. If the output of (chisel-wrapper -> dpkg status) is different from (chisel manifest -> dpkg status), that's an issue with chisel-wrapper then.

Maintain uniform scenarios across image types

This could be the SBOM.

[richlander]

My assumption is that registry-attached SBOMs do not cover all customer workflows. Are you operating under another assumption of I'm missing something?

[lbussell]

My assumption is that registry-attached SBOMs do not cover all customer workflows. Are you operating under another assumption of I'm missing something?

I'm not sure. I assumed that vulnerability scanning was the only/primary scenario under consideration. It sounds like we would need to compile a list of other scenarios we'd like to support then.

[lbussell]

[Triage]

After some more discussion, we decided:

1. We should always maintain an in-image descriptor of the image's contents.
2. The format of this is currently the dpkg cache. We could be change it to the Chisel manifest or SBOM in the future if chisel-wrapper becomes unsupported in the future, or one of the other options has better support from other tooling in the future.

The next step should be to determine chisel-wrapper's long-term support plans, and then we can decide from there whether or not we'd need new tooling to convert chisel manifest to dpkg cache.

[mthalman]

After a discussion with Canonical, here's a summary of things:

• The long-term goal is for there to be broad ecosystem support of the Chisel manifest.
• The use of SBOMs is a short-term goal that can be used as an already supported target by tools until better support exists for the Chisel manifest.
• Canonical is committed to supporting the Chisel wrapper script during this period.

Based on that, we can continue to use the Chisel wrapper to generate the dpkg status file and have that contained in the image. Whether the Chisel manifest will be stored in the image is an open question. Given the long-term goal for Chiseled image scanning does not involve SBOMs and we have a short-term story for tools via the dpkg status file, the discussion around producing SBOMs is separate from chiseled containers and can be continued at #5515.

[richlander]

Thanks for that summary. Quite useful.