top level component hashes are missing

CycloneDX / cyclonedx-maven-plugin

Creates CycloneDX Software Bill of Materials (SBOM) from Maven projects

https://cyclonedx.org/

Apache License 2.0

297 stars 85 forks source link

top level component hashes are missing #57

Open emilgenchev opened 4 years ago

emilgenchev commented 4 years ago

Is it possible to include as well hashes for the top level component. for example if I execute: mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

against following pom.xml: https://repo1.maven.org/maven2/org/apache/tomcat/tomcat-websocket/9.0.0.M13/tomcat-websocket-9.0.0.M13.pom

I get dependency hashes only into the bom and not the top level component which in this case is:

    "component": {
      "type": "library",
      "bom-ref": "pkg:maven/org.apache.tomcat/tomcat-websocket@9.0.0.M13",
      "group": "org.apache.tomcat",
      "name": "tomcat-websocket",
      "version": "9.0.0.M13",
      "licenses": [{"license": {"id": "Apache-2.0"}}],
      "purl": "pkg:maven/org.apache.tomcat/tomcat-websocket@9.0.0.M13"
    }

stevespringett commented 4 years ago

The output of a Maven build can produce more than one artifact, so there will need to be a way to specify which one to hash. We also need to take into consideration use of the Maven Assembly plugin as builds can modify the artifact or create entirely new ones. I'm not sure how to handle those scenarios.

stevespringett commented 4 years ago

One way to solve the multiple artifact issue would be to:

If project only has one attached artifact, creates hashes from the artifact and add the hash values to the top level component.
If the project has multiple attached artifacts, create child 'file' components under the top level component. Each file component would contain its own hash values and metadata specific to the type of artifact produced.

I think that would solve the majority of use cases. However, how should use of the assembly plugin be handled?

emilgenchev commented 4 years ago

would it make sense to introduce additional (optional) assembly section as part of the bom schema and describe the assembly related data?

coderpatros commented 4 years ago

I really like this idea.

But, I think this would be better handled as a separate step. It might not be the same in this ecosystem. But with .NET, for example, SBOM generation is basically a part of a standard build process. Distribution/release of the output can be quite different.

It could be a nuget package, a zip of the build artifact, executable installer, etc. That would be pretty tricky to handle outside of a separate invocation to "hash this package and add it to the top level of this SBOM".

Just thinking, what is the simplest way to introduce a hash for the top level component. Including hashes for all included files would be good too. But it would be simpler to just have a hash of the package. And easier to consume too.