Mark components from test scope

[skhokhlov]

CycloneDX npm plugin adds properties for components in SBOM which are dev dependencies of the project.

"properties": [
        {
          "name": "cdx:npm:package:development",
          "value": "true"
        }
]

https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/demo/dev-dependencies/example-results/bare/bom.1.6.json#L187-L188

This data is crucial for risk analysis of vulnerabilities. It would be perfect to add similar property to be able to identify test dependencies in SBOMs collected with maven plugin.

[FloJit]

It could be interesting to add the maven scope (not only test) in each component object.
I'll try to check it how to do that.

[FloJit]

Well, one way could be to add maven scopes in the Component.Scope enum and store the Artifact#getScope instead of to check the Artifact#isOptional.
But that means to modify the core ...

Or maybe one day change the type of the scope as String to let the possibility to set any scope of any plugin (I don't know how Gradle scopes work).

[jackhj000]

Well, one way could be to add maven scopes in the Component.Scope enum and store the Artifact#getScope instead of to check the Artifact#isOptional. But that means to modify the core ...

Or maybe one day change the type of the scope as String to let the possibility to set any scope of any plugin (I don't know how Gradle scopes work).

Hi，how about this feature now？

[ppkarwasz]

Or maybe one day change the type of the scope as String to let the possibility to set any scope of any plugin (I don't know how Gradle scopes work).

Gradle has a configurable set of dependency configurations. Some are well-known, but users can always create custom ones.

Instead of adding all these scope/dependency configurations to the SBOM, it would be probable more useful to encode their meaning, so that non-Java developers can understand them better. It would be useful to explain:

• When the dependencies are used (at compile-time, runtime or during tests). Runtime is of course the most important for dependents, but vulnerable compile-time dependencies can mess-up the build if they contain an annotation processor.
• Whether the dependencies are inherited by dependents or not.

[hboutemy]

Whether the dependencies are inherited by dependents or not.

when people start thinking like that, they are trying to use SBOMs as a way to replace build tools: SBOMs don't replace build tools

the key (and missing) aspect to store in SBOM is: is the dependency embedded or not?
and honestly, if not embedded, I'm not even sure it makes sense to store that data in SBOM, as it starts trying to replace build tools with SBOM

[ppkarwasz]

the key (and missing) aspect to store in SBOM is: is the dependency embedded or not? and honestly, if not embedded, I'm not even sure it makes sense to store that data in SBOM, as it starts trying to replace build tools with SBOM

Yes, the problem on how to mark embedded dependencies is the principal problem to solve.

IMHO, for a Build SBOM the answer is easy: if it is not embedded, it shouldn't be there. For a Source SBOM, I honestly don't know what to expect. The content of such an SBOM should probably depend on how these SBOMs are used.

[hboutemy]

IMHO, for a Build SBOM the answer is easy: if it is not embedded, it shouldn't be there

easy to say and easy to implement (just drop the vast majority of currently generated content)
but not easy to get a consensus on: if we implement that, community reaction will be at least strong surprise, not not say harsher than that

For a Source SBOM

we'll need to discuss what you call "source SBOM" and how it fits in the global picture