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: https://github.com/canonical/chisel-releases/pull/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 :+1:

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

• https://github.com/canonical/chisel/pull/144
• https://github.com/canonical/chisel/pull/143
• https://github.com/canonical/chisel/pull/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.