-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
init cdx:maven
taxonomy with existing properties
#69
Conversation
thanks for the feedback: I improved the taxonomy I have one question: I named the taxonomy |
The I am not familiar with maven dependency management, you should gather feedback from your peers :D
I am not familiar with maven dependency management, you should gather feedback from your peers :D |
this way of describing hides if the "package or component" is the output of the build or if it's a dependency (or even a tool)
everything for the moment describes the BOM generation process itself, then it's natural that all go into one single namespace: FYI, here is the current cyclonedx-maven-plugin output gefore mugrating to the official taxonomy that this PR is trying to create https://gist.github.com/hboutemy/e9bed6b890e10450a8410f317e8d6e07 does it describe the package or something else, then how should it be named is my question: I did not try to execute other tools in other technologies to see where they used their
AFAIK, CycloneDX is inheritently against Reproducible Builds (because it expects the build timestamp to be stored): the feature is currently Maven specific, as it drops the usual timestamp (that has no real meaning in that case) For now, I prefer keeping that Maven specific: we'll see later if moving to a more common taxonomy makes sense |
Timestamp is required per NTIA Minimum Elements. The team is not against reproducible builds, although they do very little to increase assurance, especially with Maven and similar ecosystems. This is being demoed at BlackHat this week. We should likely keep We should likely change the following: {
"name" : "maven.scopes",
"value" : "compile,provided,runtime,system"
} to {
"name" : "cdx:maven:package:scope",
"value" : "compile"
}
{
"name" : "cdx:maven:package:scope",
"value" : "provided"
}
{
"name" : "cdx:maven:package:scope",
"value" : "runtime"
}
{
"name" : "cdx:maven:package:scope",
"value" : "system"
} This would automatically form an array for many parsers and implementations would not have to parse |
let's have a boolean property -- some other implementations that can generate “reproducible” BOMs, by omitting time- and random-based values, ordering elements, and so on already exist. they just dont add a property to the BOM, yet.
i wonder where this property should be applied, then. |
yes, once the |
just opened #70 |
cdx/maven.md
Outdated
|
||
| Property | Description | | ||
| -------- | ----------- | | ||
| `cdx:maven:package:goal` | The goal used to generate the SBOM: `makeBom`, `makeAggregateBom` or `makePackageBom`. May appear once. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please help me understand: Would other tools that generate SBOMs from maven use these values, too?
- are these values well-known to maven?
- Is there maybe an online documentation for these values, so people know what they mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this notion of goal is specific to Maven, and well known for any Maven user
the list of goals is in plugins' documentation https://github.com/CycloneDX/cyclonedx-maven-plugin#goals
I'm not convinced adding a link gives great value, but I can add it to the "goal" term in the sentence
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced adding a link gives great value, but I can add it to the "goal" term in the sentence
it does. A SecOps person might not know any maven nor java, but they know SBOM and they would want to know what this value means and where to read about it, so they can judge the value of an SBOM.
[...] well known for any Maven user
for ANY user? Or maybe only for users of cyclonedx-maven-plugin
, since these goals are only available when this plugin is used?
I was unable to find anything regarding these goals/values, outside the context of cyclonedx-maven-plugin. I am not convinced that this property is global/broad enough. I still think it is specific for
cyclonedx-maven-plugin`, and other SBOM tools would not use it nor recognize it at all. Could you help me understand why I am wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, I over-focused on SBOM producer, who is a Maven user, knowing Maven concepts and how to look for this plugin specific details that match usual Maven concepts
but SBOM is much about consumers, and here, the diversity in culture is really wide
Notice that without waiting, I already added the documentation on goals while doing the suggested link to Maven scopes in c9aac68: it's easy to do and maintain, then it's worth the tiny effort :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regarding SBOM generators: is this property specific to cyclonedx-maven-plugin
?
In reverse: would other SBOM generators, something that is not a maven plugin - like trivy
or cdxgen
, also be able to use this property?
If this property is only relevant for users of cyclonedx-maven-plugin
,
then you should document the property in the readme of cyclonedx-maven-plugin
, not here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given other pipenv and poetry existing taxonomies, I'm surprised: AFAIK, they share the same ecosystem, isn't it?
Most python-based ecosystem have https://pypi.org/ as a package source.
Pipenv and poetry have completely own wordings, definitions, workflows.
for npm, composer and maven, it's not clear if it's ecosystem names or build tool names
- NPM: names are directly derived from npm(the CLI tool)-internals
- Composer: names are directly derived from composer(the CLI tool)-internals
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pipenv and poetry have completely own wordings, definitions, workflows.
same for Maven vs Gradle vs sbt vs ... build tools that use the Maven ecosystem (package sources)
the only difference is that "Maven" term is both an ecosystem and a specific build tool
But I don't see how Pipenv and Poetry have "properties documented [] meant to be implementation-independent, ecosystem-oriented."
For npm, it's not clear if it's "npm the ecosystem", that is for example npmjs.com, or npm
the build tool only, ignoring how yarn
, pnpm
, or other build tools that use the same package do their SBOMs
On Composer, I don't know if there are build tools that are built on top of the ecosystem that the original Composer build tool created
I'm really confused: I don't know if I'm loosing my time trying to create this Maven taxonomy or not
What is clear is that all properties that I'm requiring are specific to Maven the build tool, because other tools use the ecosystem in a different way from a dependency management strategy = what the SBOM is much about
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just remove cdx:maven:package:goal
and this PR is done.
additional properties can be added later.
PS: i will not react to all your points, so you are not loosing any time reading them.
I don't know if I'm loosing my time trying to create this Maven taxonomy or not.
If you have a question related to other taxonomies, feel free to create a ticket for them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just remove
cdx:maven:package:goal
and this PR is done.
cdx:maven:package:optional-unused
is very very cyclonedx-maven-plugin
specific: then this is the first to be removed also
cdx:maven:package:scope
is Maven build tool specific: perhaps it's the only one that may make sense in this PR IIUC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then lets keep the general usable property for now.
if any of the others appear to have a common ground, then they can be added back.
How does this sound?
fixes CycloneDX#68 Signed-off-by: Hervé Boutemy <hboutemy@apache.org>
Signed-off-by: Hervé Boutemy <hboutemy@apache.org>
Signed-off-by: Hervé Boutemy <hboutemy@apache.org>
Signed-off-by: Hervé Boutemy <hboutemy@apache.org>
@hboutemy sorry for my very late reply. |
time passed, re-reading the discussions |
fixes #68 with existing properties added in cyclonedx-maven-plugin 2.7.7 and 2.7.9
once this is done, we'll add new properties later