> The only thing I can think of is if there should be > separate VEX documents for each release.
Could you elaborate on this Brian? Our expectation was to have a single VDR, that is 1. manually updated by the PMC 2. disclosing affected versions (either explicitly or by a version range, etc.) 3. stored at one place (e.g., ` https://logging.apache.org/cyclonedx-vdr.xml`) 4. all SBOMs of all releases point to via `externalReferences` Given the low number of products we offer and vulnerabilities associated with them, I think having a single document will make things more accessible for users and maintainable for the PMC. That said, if there is an established industry best practice, we might indeed gravitate towards that. On Fri, Oct 27, 2023 at 5:26 PM Brian Fox <bri...@infinity.nu> wrote: > On Fri, Oct 27, 2023 at 7:22 AM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > FYI to Logging and Brian, > > > > Over at Apache Commons, I added generating of CycloneDX and SPDX SBOMs > > that we publish along with our artifacts. So I'd be curious if "we're > > doing it wrong" ;-) > > > > My take is that it is still early in the SBOM game and that we're > > getting ahead of the game but just producing these files. > > > > This ^^. > > Hardly anyone is producing SBOMs yet... this is something we've been > trying to change by have Herve work on the plugin and get it > integrated into the Apache Pom so we get them by default. I'm aware of > even fewer doing the VEX publication. I will do some digging on how > the Cyclone team expected those links to be used but I don't see any > red flags. The only thing I can think of is if there should be > separate VEX documents for each release. > > The other thing to be aware of is there is still lack of concensus of > VEX vs VDR. It seems like VDR is gaining more traction > https://owasp.org/blog/2023/02/07/vdr-vex-comparison > > > > > > We are also discussing publishing OSV and/or VEX files. > > > > Gary > > > > On Fri, Oct 27, 2023 at 7:04 AM Piotr P. Karwasz > > <piotr.karw...@gmail.com> wrote: > > > > > > Hi all, > > > > > > On Thu, 19 Oct 2023 at 15:08, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > > We probably also need to fill in other keys in the SBOM: > > > > > > > > As far as I can read from sources, custom "keys" (i.e., "external > > > > references") are not supported by `cyclonedx-maven-plugin`. I am > > > > double-checking this with Hervé Boutemy (`cyclonedx-maven-plugin` > > > > maintainer) as we speak. I might create a ticket (maybe even along > with a > > > > PR) depending on the outcome. > > > > > > We can probably post-process the output of `cyclonedx-maven-plugin` to > > > add additional externalReferences[1] to our artifacts. > > > > > > The main question is: how useful will that be to current and future > > > SBOM processing tools? > > > > > > Brian, do you have any tips on how to make our SBOM available to the > > > largest possible audience? What we are currently planning is: > > > > > > 1. To generate a CycloneDX SBOM for each of our artifacts using > > > `cyclonedx-maven-plugin`, which will add the SBOMs with a classifier > > > of `cyclonedx` and a type of `xml` and `json`. > > > 2. To add to each of our components in the SBOM two external > > > references (that list the vulnerabilities in our own products and how > > > we are affected by known vulnerabilities in our dependencies): > > > > > > <externalReference type="vulnerability-assertion"> > > > <url>https://logging.apache.org/security/vulnerabilities</url> > > > </externalReference> > > > <externalReference type="exploitability-statement"> > > > <url>https://logging.apache.org/security/exploitability</url> > > > </externalReference> > > > > > > The URLs will profit from HTTP content negotiation and will be > > > provided in three formats: > > > > > > * CycloneDX XML, if the client accepts > 'application/vnd.cyclonedx+xml', > > > * CycloneDX JSON, if the client accepts > 'application/vnd.cyclonedx+json', > > > * a plain HTML web page for the 'text/html` format. > > > > > > My questions regarding this procedure are: > > > > > > 1. Are CycloneDX attachments in Maven Central processed by some tools? > > > Unless I am mistaken, at least Sonatype uses them, > > > 2. Are the `vulnerability-assertion` and `exploitability-statement` > > > references the right way to provide users with information about > > > security-related issues? For example if our `foobar` dependency 1.0.0 > > > publishes a vulnerability and we update our VEX file with our > > > recommendations, will this info reach someone? > > > 3. Can we use HTTP content negotiation or should we provide multiple > > > external references for each of the supported formats? > > > > > > Piotr > > > > > > [1] https://cyclonedx.org/docs/1.5/json/#externalReferences >
