syft icon indicating copy to clipboard operation
syft copied to clipboard

Make it discoverable if Native Image contains no embedded SBOM

Open rudsberg opened this issue 9 months ago • 3 comments

What would you like to be added: It should be easy for users to detect if syft encounters a Native Image without an embedded SBOM. This is important for security critical environments where it's required to enforce that Native Images contain embedded SBOMs to ensure vulnerability scanning remains functional. If a Native Image is created without an embedded SBOM, any vulnerable components will go undetected in vulnerability scanning.

Currently, the only possible way to get an indication of the problematic situation of a Native Image without an embedded SBOM is by running syft in debug mode -vv and looking for the Trace message

unable to extract SBOM from possible java native-image

This is not sufficient for two reasons:

  • It's hidden in the debug logs.
  • It doesn't differentiate between a Native Image without an embedded SBOM and any other executable file. The message will be the same for any other non-Native Image ELF, Mach-O, and PE file.

Why is this needed: To clearly signal to syft users of a potentially dangerous configuration of their Native Images.

Additional context: No comments.

rudsberg avatar Mar 14 '25 10:03 rudsberg

Hey @rudsberg -- we now support "unknowns" in Syft, which are errors that occur during cataloging that we think are useful to surface to end users. It looks like this particular error definitely should be raised up as an unknown error. These show up on file objects in the "unknowns" section. The solution here is to bubble the error up to the top-level catalog function here and then create an unknown error with the location unknown.New; any "unknown" errors are automatically associated with the referenced file in the Syft SBOM.

kzantow avatar Mar 19 '25 14:03 kzantow

Hi @kzantow . Can you assign me this issue? I can work on this.

sathiya06 avatar Apr 10 '25 17:04 sathiya06

I've had to revert the change that closed this issue. The reason is it did not identify an executable as a graalvm executable, but was returning incorrect unknown information for all executables that didn't have an SBOM, not just graalvm executables, which is not correct. In order to restore this, we will need to figure out how to accurately identify executables as graalvm before identifying them as missing an SBOM.

kzantow avatar May 30 '25 00:05 kzantow