Howdy, team. In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s really hard for

Sandeep, A good example of a VEX advisory is provided by Siemens in their log4j advisory: https://cert-portal.siemens.com/productcert/csaf/ssa-661247.json NOTE: VEX’s are vulnerability

Hi Sandeep, To add to Rose’s comments… For version 2.3, the new Advisory identifier (F.2.3) is a catch-all that will enable linking to any VEX information, e.g., as contained within OSV or

Hoping this is recorded – I have another unmovable meeting at this time! Ria

It was not recorded and I don’t think we’ve ever really done that for general meetings specifically nor for other meetings for the most part (not to say we can’t, but that has been and is the

Sandeep, NIST also recommends that vendors and consumers “Maintain vendor vulnerability disclosure reports at the SBOM component level.” See 5/5

Hi Sandeep, The SPDX Defects working group announced security enhancements to theExternalReference section of the spec as well as an explanatory Annex about how to include security information in

Will the meeting be recorded? I have a conflict, but would love to listen to the updates. Thanks.

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for

Hi , Is there any roadmap to integrate VEX to with SPDX ? Or is there already way in current SPDX specification to integrate vulnerability information ? Regards Sandeep

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