support for `maven-shade-plugin`

[raboof]

When using maven-shade-plugin, the sbom should likely somehow encode which dependencies are 'embedded' in the jar, and which are 'regular' dependencies.

AFAIK there is no convention on how to express this difference yet in CycloneDX. Likely it would make sense to make use of the assembly concept?

I have a test/demo project for this at https://github.com/raboof/maven-shade-sbom/

[stevespringett]

Yes, using a CycloneDX assembly would be the correct way to represent this.

[prabhu]

evidence.identity can also be used to describe the technique and confidence.

[ppkarwasz]

@stevespringett,

By assembly do you mean components.components or something else?

[stevespringett]

Correct @ppkarwasz

[raboof]

Yes, using a CycloneDX assembly would be the correct way to represent this.

This makes sense embedded dependencies of dependencies, but I'm having trouble understanding how it works for embedded dependencies of the 'current' project: to take the example in https://github.com/raboof/maven-shade-sbom/, mvn install produces a maven-shaded-sbom-1.0-SNAPSHOT.pom that defines a dependency on org.apache.commons:commons-email:1.6.0, and a maven-shaded-sbom-1.0-SNAPSHOT.jar that contains the classes from org.apache.commons:commons-compress:1.26.0 (and some others).

The current generated SBOM comes down to (removed some details)

{
  "bomFormat" : "CycloneDX",
  "specVersion" : "1.6",
  "serialNumber" : "urn:uuid:e458a584-6054-38cb-bf05-b4c8095ee27d",
  "version" : 1,
  "metadata" : {
    "component" : {
      "type" : "library",
      "bom-ref" : "pkg:maven/net.bzzt/maven-shaded-sbom@1.0-SNAPSHOT?type=jar",
    },
    ...
  },
  "components" : [
    {
        "type" : "library",
        "bom-ref" : "pkg:maven/org.apache.commons/commons-email@1.6.0?type=jar"
        ...
    },
    {
        "type" : "library",
        "bom-ref" : "pkg:maven/org.apache.commons/commons-compress@1.26.0?type=jar",
    },
    ...
  ],
  "dependencies" : ...

I can see how if some project would depend on maven-shaded-sbom, we could express the fact that commons-compress is embedded into maven-shaded-sbom in that projects' SBOM like this:

{
  "bomFormat" : "CycloneDX",
  "specVersion" : "1.6",
  "serialNumber" : "urn:uuid:e458a584-6054-38cb-bf05-b4c8095ee27d",
  "version" : 1,
  "metadata" : {
    "component" : {
      "type" : "library",
      "bom-ref" : "pkg:maven/net.bzzt/maven-depending-sbom@1.0-SNAPSHOT?type=jar",
    },
    ...
  },
  "components" : [
    {
        "type" : "library",
        "bom-ref" : "pkg:maven/net.bzzt/maven-shaded-sbom@1.0-SNAPSHOT?type=jar",
        "components " : [
          {
            "type" : "library",
            "bom-ref" : "pkg:maven/org.apache.commons/commons-compress@1.26.0?type=jar",
            ...
          },
          ...
        ]
    },
    {
        "type" : "library",
        "bom-ref" : "pkg:maven/org.apache.commons/commons-email@1.6.0?type=jar",
        ...
    },
    ...
  ],
  "dependencies" : ...

To be able to construct this SBOM we need to know that commons-compress is embedded into maven-shaded-sbom, rather than just listed as a dependency. That information seems missing from the maven-shaded-sbom SBOM above. How would we encode this information into the SBOM for maven-shaded-sbom? Or should we discover this some other way while generating the SBOM for maven-depending-sbom?

[ppkarwasz]

We were just talking about this the other days with @hboutemy and the solution might be to introduce a property that says if a dependency is dynamically linked or _statically linked, or whatever couple of adjectives makes sense for the ecosystem.

For the Java ecosystem:

• dynamically linked dependencies would be the external dependencies of a JAR file. The precise version of that dependency is just a recommendation and will be resolved at runtime or when the JAR file is used in an application.
• statically linked dependencies would be all those embedded in a WAR file, shaded JAR or Spring Boot executable JAR. Security scanners can do their analysis on those.

[hboutemy]

"the solution": sadly it's not the full solution but only one key step, as we'll have other aspects to sort out too, like how to deal with a Maven module that produces both the "naked" artifact ("naked" => dynamic dependencies) AND the shaded one (=> a few static dependencies)

IMHO, these 2 topics are the key aspects to be solved before trying to implement the feature

[raboof]

the solution might be to introduce a property that says if a dependency is dynamically linked or statically linked, or whatever couple of adjectives makes sense for the ecosystem

OK. For the Maven ecosystem, the adjectives 'dynamically linked' and 'statically linked' seems a bit foreign. I think a boolean attribute named maven.embedded or maven.shaded would make sense?

how to deal with a Maven module that produces both the "naked" artifact ("naked" => dynamic dependencies) AND the shaded one (=> a few static dependencies)

That might be a topic for a different issue, or do you think it interacts with this issue strongly? I filed this as #574 - so far I think each artifact having 'their own' SBOM sounds most convenient? That also seems to work well for this use case, as then you don't have issues with how to tag a component that is embedded in one of the artifacts and a 'regular' dependency in the other: we can tag it as 'maven.embedded=true' for the shaded jar and 'maven.embedded=false' for the regular one.

[hboutemy]

For the Maven ecosystem, the adjectives 'dynamically linked' and 'statically linked' seems a bit foreign

I know people are not used to this "dynamically linked" term, but they'll have to learn: in a library, a dependency is not not really a strict dependency, the consumer will have conflict resolution that will try to use the library's preferred version, but may finally select another

dependencies in Java, given classpath conflict resolution, are always (and implicitely) "dynamic" = the effective version from a consumer perspective won't necessarily be the asked version

On static vs embedded vs shaded, this is really the case where the dependency is really there, not "virtual", or "soft referenced", or many other terms like "dynamically linked"

[raboof]

OK. I think embedded describes the difference that is relevant for the SBOM best: shading also somewhat suggests that the package paths inside the pom were changed, which may or may not be the case, and static doesn't do justice to the fact that the classloader still has some freedom.

[hboutemy]

in java (or JVM languages), I suppose we can say default is "not embedded" and exception is "embedded"
in containers, default is embedded (not sure "not embedded" does have a meaning for containers)
I don't know for Python or JavaScript

we need IMHO to clarify SBOM semantics more widely than what is implicit in JVM. And define in which CycloneDX field put the resulting info
@stevespringett WDYT?