Compliance with BSI TR-03183 guidelines

[Zuplyx]

Is your feature request related to a problem? Please describe.

The technical guideline BSI TR-03183 by the German Federal Office for Information Security (BSI) describes requirements for SBOMs.
I compared the specification with the SBOMs produced by this plugin and found that the following required component information (see Section 5.2.2) is currently missing:

• Component creator
• File name
• Hash value of the deployable component
• Executable property
• Archive property
• Structured property

Describe the solution you'd like

I would like the plugin to add the missing information, either by default or via a configurable option.

Most of the information can probably easily be added since the information is available in Maven/Gradle metadata. I propose the following mappings:

• File name: This simply maps to the file name of the resolved artifact and would have to be added as a property with the name bsi:component:filename.
• Hash value of the deployable component: The Hashes are already present in the current output. The specification simply requires to also map the SHA-512 hash to an external reference of type distribution.
• Executable property: This maps to a property bsi:component:executable. According to the explanation in section 8.1.4 this property indicates any kind of compiled or interpreted code. Therefore we would set this to executable for Jars and to false for other file types like poms.

The following properties are harder to map since there is no clear equivalent in Gradle/Maven metadata. I propose the following mappings on a best-effort basis:

• Component creator: This should be an E-Mail or alternatively an URL for the component. We can get it from the Maven Metadata if present and map it into the manufacturer.
• Archive property: According to section 8.1.5 this is used to indicate a "combination of multiple components", so for Gradle projects these would be fat Jars. Unfortunately I do not think there is a reliable way to detect fat Jars. Maybe it could be done based on the Gradle Bundling attribute, but this would only work for projects published with Gradle. Ultimately I think it would be best to default this property to no archive and provide a way to override it on a per component basis, maybe similar to the mechanism proposed in Option to choose license #784.
• Structured property: We only need to set this property if we set the archive property. It indicates that the original components can be recovered from the archive, so for the case of a fat jar we would set it to structured.

Describe alternatives you've considered

Some of this information could be added via post-processing of the SBOM, e.g. it would easily be possible to copy the SHA-512 hash to the field expected by the BSI. But ultimately I think it would be best to provide a central implementation in this plugin instead of requiring each user to write their own.

Additional context

The BSI guidelines were created in response to the EU Cyber Resilience Act (CRA) which mandates the creation of an SBOM.
They are also supported by other SBOM related tool, e.g. sbomify or sbomqs.

Contribution

• I am willing to provide an implementation
• I will wait until somebody else implements it