On Wed, Dec 17, 2025 at 9:55 AM Benjamin ROBIN <[email protected]> wrote: > > Hello, > > Thank you for your answer, but this is not exactly what I meant. > > On Tuesday, December 16, 2025 at 9:01 PM, Joshua Watt wrote: > > I think that depending on what you are trying to document, the correct > > thing to do would be to document the properties in either the > > Vulnerability > > (https://spdx.github.io/spdx-spec/v3.0.1/model/Security/Classes/Vulnerabili > > ty/) class (if it's information about the vulnerability itself), or one of > > the Vex Vulnerability relationships (if it's information about how the > > vulnerability affects a package, or how it's dealt with). > > > > Specifically for the database version, I _think_ you would assign an > > external reference > > (https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/ExternalRef > > Type/), but I don't see a type for the vulnerability database. If you have > > an idea of what that might look like, we can propose it be added to the > > spec though. > > Well I really do not want to attach the database version to the vulnerability > object. > > > Hopefully that helps; if you need more clarification, please let me know. > > The goal is to know with which parameters the sbom-cve-check was run: > Which include: the CVE database versions, and the various flags used, for > example the flag for filtering assessment and/or vulnerabilities. > > Ideally the goal is to have all the information needed to run again the CVE > analysis with the same parameters/context to produce the same output. > This is also necessary to audit how the CVE report was generated.
Got it. I'm not sure the exact best way to express that. For starters, your tool should already be assigning itself in the CreationInfo for every SPDX object it creates. That at a minimum allows tracking created objects to the tool, but that doesn't necessarily indicate how the tool was invoked to create that output. I'm not sure if a Build object is actually the best way to do this; the intention of a build is to have input and output Elements, but those are really supposed to be the objects described by the elements, not the elements themselves. I'm not sure this is an exact use case we've thought of yet in SPDX; I've CC'd the SPDX technical mailing list to see if anyone has any ideas. > > An off-topic remark: I spend a couple of hour trying to understand why the > spdx-python-model python library cannot be generated properly from the > sources. If you have any idea because I am stuck: https://github.com/spdx/ > spdx-python-model/issues/12 I'm not sure why that's happening. I'll look into it. Is there a reason you can't use the bindings published on PyPi? > > The https://spdx.github.io/spdx-spec/v3.0.1/rdf/ files changed? > > -- > Benjamin Robin, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#6063): https://lists.spdx.org/g/Spdx-tech/message/6063 Mute This Topic: https://lists.spdx.org/mt/116829251/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
