Concerns about the validity of vulnerability scan results with slices/partial packages

[lbussell]

We are using Chisel along with chisel-wrapper to create Ubuntu Chiseled images with support for vulnerability scanning.

Recently, many packages in the Chisel slices repo had slice dependencies added for copyright info - for example, libgcc-s1 has an essential dependency on the gcc-14-base_copyright slice: canonical/chisel-releases#168

This new slice, gcc-14-base_copyright, tripped up our package scanner (Syft) even though it doesn't contain any functionality, just copyright documentation.

When using chisel-wrapper to generate a dpkg status file, it seems vulnerability scanning tools cannot detect the difference between including a "functional" package slice and a "non-functional" package slice, or which parts of packages are installed by slices - they always think that the full package has been installed.

Setting aside the relationship between libgcc-s1 and gcc-14-base from the example. If slice A depends on some non-functional part of slice B, slice B will still show up in image scans and could cause false positive vulnerability reports.

Will the potential for false-positive vulnerability reports be addressed in the upcoming work for the Chisel DB? Is the intention for Ubuntu or vulnerability databases to maintain slice-level vulnerability information?

[cjdcordeiro]

Hi @lbussell

well noted. This is precisely why we've been working on the Chisel DB.

IMO this is the fault of scanners who rely on CPE to identify a piece of sw as a whole, without actually checking if the reported vulnerability is present in the system.

With the chisel DB, we will be able to provide file-level integrity, cataloguing all the chiselled contents and their provenance.

Once the Chisel DB is in, we'll still need the CVE scanners to do some work, as they are the ones who need to implement the ability to recognize a CVE by the respective files/functionality and not the enclosing package.

[lbussell]

@cjdcordeiro, great, thanks. It sounds like you intend for Chisel to provide the right amount of granularity to allow scanners/users to determine whether their images are vulnerable. Sounds good. Thanks for the clarification.

Feel free to close this issue when appropriate, or when the Chisel DB feature is released 👍

[cjdcordeiro]

Cool 👍

Linking the remaining DB (aka "manifest") PRs here for future reference, and closing:

• feat: internal manifest package #144
• feat: parse generate property in sdf #143
• feat: create manifest.wall #142

[ahachete]

Hi @lbussell Given that you re using Syft, I guess you are using Grype for vulnerability scanning. If so, wouldn't it be better @cjdcordeiro to instead of creating Chisel DB (or in addition to) focus on generating proper SBOMs? Most vulnerability scanning tools (and definitely Grype) support, to my understanding, using such SBOMs, instead of package databases, to perform the scanning. Plus SBOMs provide additional value outside of vulnerability scanning.

[cjdcordeiro]

@ahachete Yes, that is precisely our goal. The Chisel DB (now renamed to "Manifest") will have the necessary information for creating an SBOM.

Initially, that is how we suggest scanning chiselled images. Eventually, we expect upstream tools to start supporting the Chisel Manifest format, but until then, indeed the SBOM will be the way to go.

[norrisjeremy]

Is anyone aware of (or working on) a utility that can transform a Chisel Manifest into a CycloneDX and/or SPDX SBOM?

[lbussell]

We filed this issue for adding support to Microsoft's SBOM generator tool: Support Ubuntu Chisel manifests as an sbom input (microsoft/sbom-tool#811). But I don't know of any tools that support this today. Interested to know if Canonical folks know of any.

[HadrienPatte]

Is anyone aware of (or working on) a utility that can transform a Chisel Manifest into a CycloneDX and/or SPDX SBOM?

I have a proof of concept for adding support in trivy to generate SBOMs out of a chisel manifest here but I'm waiting for an answer on #177 before moving forward with an upstream PR to trivy.

[norrisjeremy]

I'm sort of curious to better understand the reasoning of inventing yet another format, instead of using either the CycloneDX or SPDX SBOM formats?

The decision to use a bespoke format seems a bit odd, as it only seems to just make users' lives more complicated, by either having to construct their own tools to parse said bespoke format, or they have to chase down & convince existing tools + scanners in the industry into supporting it.

[cjdcordeiro]

Awesome work in aquasecurity/trivy@main...HadrienPatte:trivy:chisel @HadrienPatte !

I've replied to #177 (comment)

wrt to the jsonwall format @norrisjeremy , we believe that the Chisel manifest and an SBOM, although contextually similar, differ in scope. I'd say the Chisel manifest, in nature, would be closer to a dpkg/status, but we needed a new format because 1) we're not actually using dpkg or APT, 2) we wanted to be more granular and introduce the notion of paths and slices, and 3) we wanted a more self-contained and efficient file for parsing. We foresee that, in most cases, slices will be a part of a wider filesystem that is composed of software coming from other sources (e.g. python packages, snaps, git, etc.) - so in reality, the Chisel manifest doesn't reflect the SBOM of the final artifact, but rather only the software that was cut by Chisel.