Armijn raises a valid concern. We’ve avoided dynamic information in the past, but even with version 1.0 you could argue the “Concluded License” could change over time if new information is

Sort of. Security information is even more likely to change after release, EOL for open source components supported by the community may, but much less frequently. Thinking so far, is that this

Steve, Regarding: “I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?” Yes, if a software vendor chooses to list each known

Armijn said: > Current information inside SPDX documents is largely static […] > This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need

I agree: “I would suggest to keep this information "out of band" and not inside SPDX documents” Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector

hello, I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license,

Hi Sandeep, Although the SPDX ID is internal to SPDX documents, you can refer to an SPDX ID in a different document using the SPDX Document identifier as defined in section 6.6. So the statement

Hi Gary, Thanks for reply, then SPDXID will be mostly internal ID and can not be referenced externally, Do you think this might need some change in SPDXID documentation statement ? "Uniquely

Some of you probably know that OpenSSF met with a bunch of US Federal organizations in Washington DC last week to discuss cyber security wrt the open source software supply chain. (our own Kate and

Hi Sandeep – Moving the conversation over to the SPDX-tech mailing list. Unfortunately, adding in a CPE ID or pURL would include characters disallowed in the SPDX ID. Fortunately, there is a

This is how Microsoft has approached this: https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/ The one thing I’d add is

You’re welcome. You will most likely need SPDX V2.3 if you have any “FILE” components that need to specify version info. The new PackagePurpose field supports the version info for “FILE”

Thanks you Dick, This is useful

NTIA Framing document has the mapping you seek: see page 13 https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf However the “EO 14028 NTIA min element list

Hi , Is there any document reference which can be used to see mapping between SPDX tags and NTIA Minimum elements ? Some element names can be easily confused , something like "Author of SBOM Data"

Hi , I have query regarding SPDXID , Can this be expressed along with CPE or pURL something like "SPDXRef-[cpe id]" or "SPDXRef-[pURL]" Any further guidance on this will help. Regards Sandeep

Kate and Sandeep, Our customers are also interested in this information. There are two concepts to consider: Commercial Status: <enumeration value="Available"></enumeration>

Hi Sandeep, There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3. When it comes in, please feel free to review and make sure it's going to

Hi All, We have requirement to specify End Of Life as part of package information in SBoM , Is there way current SPDX format support this ? Regards Sandeep

The video has been posted here: https://www.youtube.com/watch?v=8X5PWa7A6pY&list=PLciqFgcGu7TvR_f3aKZHkozX0WIs-N7vc&index=7 Thanks again to Joshua for sharing with us!