You are viewing a plain text version of this content. The canonical link for it is here.
Posted to security-discuss@community.apache.org by Brandon Lum <lu...@google.com.INVALID> on 2022/08/01 20:36:38 UTC
Re: SBOM Generation
Regardless of format, equally important is the process and use of SBOMs
within the ecosystem - integrating them into inventory/CMDB and mapping it
to vulnerabilities and VEX type documents. I look forward to joining
the discussions and helping to figure this out. As part of Google Open
Source Team (GOSST), we are working on the missing pieces (around
sharing/mapping/discoverability and resolving vulnerabilities with OSV/VEX).
From a format perspective, we are actively engaged in SPDX.
On Fri, Jul 22, 2022 at 2:05 AM Mark J Cox <mj...@apache.org> wrote:
> Hi Matt;
>
> Regarding OpenSSF participation, they are expecting us to turn up at some
> point to that working group, so you just need to hop on one of their future
> zoom calls. There's no need for us or you to do anything to join the
> organisation or pre-notify them, the working groups are open. I expect
> they're going to be working on producing simple advice and are looking for
> our input as much as anything to help them figure out what advice is useful
> for them to give, so maybe it's a little chicken-and-egg. I''m hoping that
> advice is useful to us, but we've certainly not made any decisions on if
> we'll adopt it at this early stage.
>
> I hadn't realised SBOMs like CycloneDX could include vulnerability lists,
> because I see SBOM as being immutable; and a brief glance shows they're
> thinking of vulnerabilities in dependencies known at build time (although
> perhaps our guidance really ought to be to not ship builds with
> dependencies with known security issues!). There's other formats for
> disclosing later-found-vulnerabilities, this isn't in the scope of SBOM.
>
> (Also, all, please do update
> https://cwiki.apache.org/confluence/display/COMDEV/SBOM to capture any ASF
> work or thinking on SBOM or links to OpenSSF work in progress etc)
>
> Regards, Mark
>
>
> On Fri, Jul 22, 2022 at 3:52 AM Matt Juntunen <ma...@gmail.com>
> wrote:
>
> > Hello all,
> >
> > Continuing the conversation here...
> >
> > Gary, I wouldn't say that an SBOM is an XML transformation of a POM.
> > CycloneDX, for example, can contain information not in a POM, such as
> > license information, service relationships, and vulnerabilities [1].
> > The component identifiers used are also different in that they
> > describe the component uniquely across the entire software space
> > (different languages, packaging schemes, etc.) and not just in the
> > Maven ecosystem. However, for the purposes of Apache Commons, I expect
> > that there will be a good amount of overlap between the information in
> > the POM and that in the SBOM.
> >
> > Mark, can you provide an more details on how we should interact with
> > OpenSSF? Do we simply show up in the Zoom meeting or is there some
> > sort of protocol we need to follow? Are you picturing us following
> > their lead on SBOM recommendations?
> >
> > Regards,
> > Matt J
> >
> > [1] https://cyclonedx.org/specification/overview/
> >
> > On Thu, Jul 21, 2022 at 12:51 PM David Nalley <da...@gnsa.us> wrote:
> > >
> > > I hesitate to weigh in because I am not going to be doing any of the
> > work,
> > > but I think it's useful to consider what you're trying to accomplish
> with
> > > SBOM. I used to spend a lot of time in the SBOM space.
> > >
> > > If it's license compliance, SPDX makes a lot of sense. It was built
> from
> > > the ground up to be a license compliance data exchange format.
> > > Folks are aggressively working on SPDX 3.0 and adding some uses cases
> > > around security and to address some of the gaps that SBOM advocates
> have
> > > called out.
> > >
> > > CycloneDX was built from the ground up as a SBOM and security tool.
> > What's
> > > really telling for me is that there are already a lot of tools for
> > sharing,
> > > querying, and managing BoMs in the CycloneDX format. Just generating
> the
> > > BoM may be all that we do, but for it to be useful to our users they
> need
> > > tools that can ingest, and do something with the BoM. That's improving
> by
> > > the day with SPDX, but great tooling exists already for CycloneDX.
> > >
> > > --David
> > >
> > >
> > >
> > > On Mon, Jul 18, 2022 at 8:18 AM Steve Springett
> > > <st...@owasp.org.invalid> wrote:
> > >
> > > > There may be value in supporting both formats. Most security vendors
> > > > support the CycloneDX standard since its from OWASP and was
> > purpose-built
> > > > for security use cases. Some security vendors support SPDX as well.
> > OpenSSF
> > > > has publicly stated that they will only support SPDX due to both
> > OpenSSF
> > > > and SPDX being Linux Foundation projects. Unfortunately, this view is
> > > > contrary to the adoption we’re seeing in the global security
> community.
> > > >
> > > > Sonatype, the stewards of Maven Central, have been a big supporter of
> > > > CycloneDX since 2019 and have recommitted to favoring it going
> forward.
> > > >
> > > >
> >
> https://www.sonatype.com/press-releases/sonatype-embraces-cyclonedx-standard-for-integrating-software-bills-of-materials-sboms
> > > >
> > > > Regardless, the end goal is to have authoritative SBOMs published to
> > Maven
> > > > Central similar to what DropWizard is doing.
> > > >
> > > > https://repo1.maven.org/maven2/io/dropwizard/dropwizard-core/2.1.1/
> > > >
> > > > Non-authorative SBOMs may be on the roadmap for Maven Central.
> > > >
> > > >
> > > > —Steve
> > > >
> > > >
> > > > On 2022/07/17 16:11:28 Matt Juntunen wrote:
> > > > > Hello,
> > > > >
> > > > > The Apache Commons project recently received a PR [1] for our
> parent
> > > > > POM that includes the generation of software bill of materials
> (SBOM)
> > > > > artifacts during the build. During the following discussion [2] on
> > our
> > > > > dev mailing list, it was suggested that this mailing list would be
> > the
> > > > > appropriate place to discuss this topic. In short, we are trying to
> > > > > answer the following questions:
> > > > >
> > > > > 1. Should our projects include SBOM artifacts?
> > > > > 2. If so, what format should we use (e.g., SPDX [3] or CycloneDX
> > [4])?
> > > > >
> > > > > I am of the opinion that the ASF in general (and Apache Commons in
> > > > > particular) should provide these artifacts when appropriate as they
> > 1)
> > > > > are useful when performing vulnerability and software supply chain
> > > > > analysis and 2) promote good cybersecurity practices in the
> > community.
> > > > >
> > > > > What guidance does the ASF provide on this issue? What, if any,
> > > > > standards have been adopted?
> > > > >
> > > > > Regards,
> > > > > Matt J
> > > > >
> > > > > [1] https://github.com/apache/commons-parent/pull/122
> > > > > [2]
> https://lists.apache.org/thread/kvdz39t5wndojbtqqn84smm51rt89fnx
> > > > > [3] https://spdx.dev/
> > > > > [4] https://cyclonedx.org/
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > security-discuss-unsubscribe@community.apache.org
> > > > > For additional commands, e-mail:
> > > > security-discuss-help@community.apache.org
> > > > >
> > > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > security-discuss-unsubscribe@community.apache.org
> > > > For additional commands, e-mail:
> > > > security-discuss-help@community.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail:
> > security-discuss-help@community.apache.org
> >
> >
>
Re: SBOM Generation
Posted by Jarek Potiuk <ja...@potiuk.com>.
Question - did anyone here talk about Python SPDX/CycloneDX integration? I
know there are tools for both out there, and I would be happy to test them
in Airflow (we have > 600 dependencies including transitive ones and we
actually keep a very good track of those including versions for - basically
every PR but they are not exposed in a standard way.
Did anyone here try it for Python or is it a green-field?
Are there any plans to make those SBOM reports a requirement or even a
recommendation for all ASF projects? Because if we are thinking of that -
we need to think more than Maven only (happy to test and provide some
Python recommendations there if we do something like that).
J.
On Thu, Aug 4, 2022 at 7:14 AM Gary O'Neall <ga...@sourceauditor.com> wrote:
> Greetings all – just catching up on the thread.
>
>
>
> I’m not a member of the security-discuss Apache email list, so be sure to
> cc me if you would like any follow-up on the SPDX maven plugin.
>
>
>
> I developed and currently maintain an SPDX maven plugin for SPDX – the
> repo is at https://github.com/spdx/spdx-maven-plugin
>
>
>
> I use the plugin myself for adding SPDX documents to the SPDX library and
> other open source projects.
>
>
>
> I’m working on a rather significant update to the plugin to support the
> upcoming SPDX 2.3 spec release along with adding support for producing a
> more compact JSON format. If you want to see the work in progress, visit
> the v23 branch <https://github.com/spdx/spdx-maven-plugin/tree/v23> in
> the repo.
>
>
>
> Feedback and collaboration on the plugin is very much welcome – especially
> over the next couple weeks as I’m updating the plugin.
>
>
>
> A few other random notes on the longer thread:
>
> * Agree with Steve’s comment on supporting both SPDX and CycloneDX.
> I personally think both formats will be around for a while and will have
> their own communities (with some overlap). SPDX has gained some
> significant adoption in the commercial software world and CycloneDX had
> gained a lot of traction in the security space (as Steve noted).
> * I’ve been working with members of the CycloneDX community to make
> the 2 formats more interoperable. We’re working on tools and spec
> improvements to make it easier for folks to support both formats. For
> example, the upcoming SPDX 2.3 has a couple of specific enhancement to
> enable higher fidelity transformations between the formats.
>
>
>
> If you have any questions on the plugin or SPDX in general, don’t hesitate
> to ask me, post an issue to the maven repo, or join the SPDX tech email
> list: spdx-tech@lists.spdx.org <ma...@lists.spdx.org>
>
>
>
> Best regards,
> Gary O’Neall
>
>
>
> From: Brandon Lum <lu...@google.com>
> Sent: Wednesday, August 3, 2022 2:04 PM
> To: security-discuss@community.apache.org
> Cc: Matt Juntunen <ma...@gmail.com>; Gary O'Neall <
> gary@sourceauditor.com>
> Subject: Re: SBOM Generation
>
>
>
> Gary O'Neall maintains the java library
> https://github.com/spdx/Spdx-Java-Library, which is used to build some of
> the tooling: https://github.com/spdx/tools-java. Those repos would be
> preferred.
>
>
>
> I'm not too familiar with the Java ecosystem so going to defer to Gary
> O'neall (+CC)
>
>
>
> On Tue, Aug 2, 2022 at 6:57 AM Gary Gregory <garydgregory@gmail.com
> <ma...@gmail.com> > wrote:
>
> Hi Brandon,
>
> Is there a Maven plugin that is preferred for SPDX?
>
> Gary
>
> On Mon, Aug 1, 2022, 16:36 Brandon Lum <lumb@google.com.invalid <mailto:
> lumb@google.com.invalid> > wrote:
>
> > Regardless of format, equally important is the process and use of SBOMs
> > within the ecosystem - integrating them into inventory/CMDB and mapping
> it
> > to vulnerabilities and VEX type documents. I look forward to joining
> > the discussions and helping to figure this out. As part of Google Open
> > Source Team (GOSST), we are working on the missing pieces (around
> > sharing/mapping/discoverability and resolving vulnerabilities with
> > OSV/VEX).
> >
> > From a format perspective, we are actively engaged in SPDX.
> >
> > On Fri, Jul 22, 2022 at 2:05 AM Mark J Cox <mjc@apache.org <mailto:
> mjc@apache.org> > wrote:
> >
> > > Hi Matt;
> > >
> > > Regarding OpenSSF participation, they are expecting us to turn up at
> some
> > > point to that working group, so you just need to hop on one of their
> > future
> > > zoom calls. There's no need for us or you to do anything to join the
> > > organisation or pre-notify them, the working groups are open. I expect
> > > they're going to be working on producing simple advice and are looking
> > for
> > > our input as much as anything to help them figure out what advice is
> > useful
> > > for them to give, so maybe it's a little chicken-and-egg. I''m hoping
> > that
> > > advice is useful to us, but we've certainly not made any decisions on
> if
> > > we'll adopt it at this early stage.
> > >
> > > I hadn't realised SBOMs like CycloneDX could include vulnerability
> lists,
> > > because I see SBOM as being immutable; and a brief glance shows they're
> > > thinking of vulnerabilities in dependencies known at build time
> (although
> > > perhaps our guidance really ought to be to not ship builds with
> > > dependencies with known security issues!). There's other formats for
> > > disclosing later-found-vulnerabilities, this isn't in the scope of
> SBOM.
> > >
> > > (Also, all, please do update
> > > https://cwiki.apache.org/confluence/display/COMDEV/SBOM to capture any
> > ASF
> > > work or thinking on SBOM or links to OpenSSF work in progress etc)
> > >
> > > Regards, Mark
> > >
> > >
> > > On Fri, Jul 22, 2022 at 3:52 AM Matt Juntunen <
> matt.a.juntunen@gmail.com <ma...@gmail.com>
> > >
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > Continuing the conversation here...
> > > >
> > > > Gary, I wouldn't say that an SBOM is an XML transformation of a POM.
> > > > CycloneDX, for example, can contain information not in a POM, such as
> > > > license information, service relationships, and vulnerabilities [1].
> > > > The component identifiers used are also different in that they
> > > > describe the component uniquely across the entire software space
> > > > (different languages, packaging schemes, etc.) and not just in the
> > > > Maven ecosystem. However, for the purposes of Apache Commons, I
> expect
> > > > that there will be a good amount of overlap between the information
> in
> > > > the POM and that in the SBOM.
> > > >
> > > > Mark, can you provide an more details on how we should interact with
> > > > OpenSSF? Do we simply show up in the Zoom meeting or is there some
> > > > sort of protocol we need to follow? Are you picturing us following
> > > > their lead on SBOM recommendations?
> > > >
> > > > Regards,
> > > > Matt J
> > > >
> > > > [1] https://cyclonedx.org/specification/overview/
> > > >
> > > > On Thu, Jul 21, 2022 at 12:51 PM David Nalley <david@gnsa.us
> <ma...@gnsa.us> > wrote:
> > > > >
> > > > > I hesitate to weigh in because I am not going to be doing any of
> the
> > > > work,
> > > > > but I think it's useful to consider what you're trying to
> accomplish
> > > with
> > > > > SBOM. I used to spend a lot of time in the SBOM space.
> > > > >
> > > > > If it's license compliance, SPDX makes a lot of sense. It was built
> > > from
> > > > > the ground up to be a license compliance data exchange format.
> > > > > Folks are aggressively working on SPDX 3.0 and adding some uses
> cases
> > > > > around security and to address some of the gaps that SBOM advocates
> > > have
> > > > > called out.
> > > > >
> > > > > CycloneDX was built from the ground up as a SBOM and security tool.
> > > > What's
> > > > > really telling for me is that there are already a lot of tools for
> > > > sharing,
> > > > > querying, and managing BoMs in the CycloneDX format. Just
> generating
> > > the
> > > > > BoM may be all that we do, but for it to be useful to our users
> they
> > > need
> > > > > tools that can ingest, and do something with the BoM. That's
> > improving
> > > by
> > > > > the day with SPDX, but great tooling exists already for CycloneDX.
> > > > >
> > > > > --David
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jul 18, 2022 at 8:18 AM Steve Springett
> > > > > <steve.springett@owasp.org <ma...@owasp.org>
> .invalid> wrote:
> > > > >
> > > > > > There may be value in supporting both formats. Most security
> > vendors
> > > > > > support the CycloneDX standard since its from OWASP and was
> > > > purpose-built
> > > > > > for security use cases. Some security vendors support SPDX as
> well.
> > > > OpenSSF
> > > > > > has publicly stated that they will only support SPDX due to both
> > > > OpenSSF
> > > > > > and SPDX being Linux Foundation projects. Unfortunately, this
> view
> > is
> > > > > > contrary to the adoption we’re seeing in the global security
> > > community.
> > > > > >
> > > > > > Sonatype, the stewards of Maven Central, have been a big
> supporter
> > of
> > > > > > CycloneDX since 2019 and have recommitted to favoring it going
> > > forward.
> > > > > >
> > > > > >
> > > >
> > >
> >
> https://www.sonatype.com/press-releases/sonatype-embraces-cyclonedx-standard-for-integrating-software-bills-of-materials-sboms
> > > > > >
> > > > > > Regardless, the end goal is to have authoritative SBOMs published
> > to
> > > > Maven
> > > > > > Central similar to what DropWizard is doing.
> > > > > >
> > > > > >
> > https://repo1.maven.org/maven2/io/dropwizard/dropwizard-core/2.1.1/
> > > > > >
> > > > > > Non-authorative SBOMs may be on the roadmap for Maven Central.
> > > > > >
> > > > > >
> > > > > > —Steve
> > > > > >
> > > > > >
> > > > > > On 2022/07/17 16:11:28 Matt Juntunen wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > The Apache Commons project recently received a PR [1] for our
> > > parent
> > > > > > > POM that includes the generation of software bill of materials
> > > (SBOM)
> > > > > > > artifacts during the build. During the following discussion [2]
> > on
> > > > our
> > > > > > > dev mailing list, it was suggested that this mailing list would
> > be
> > > > the
> > > > > > > appropriate place to discuss this topic. In short, we are
> trying
> > to
> > > > > > > answer the following questions:
> > > > > > >
> > > > > > > 1. Should our projects include SBOM artifacts?
> > > > > > > 2. If so, what format should we use (e.g., SPDX [3] or
> CycloneDX
> > > > [4])?
> > > > > > >
> > > > > > > I am of the opinion that the ASF in general (and Apache Commons
> > in
> > > > > > > particular) should provide these artifacts when appropriate as
> > they
> > > > 1)
> > > > > > > are useful when performing vulnerability and software supply
> > chain
> > > > > > > analysis and 2) promote good cybersecurity practices in the
> > > > community.
> > > > > > >
> > > > > > > What guidance does the ASF provide on this issue? What, if any,
> > > > > > > standards have been adopted?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Matt J
> > > > > > >
> > > > > > > [1] https://github.com/apache/commons-parent/pull/122
> > > > > > > [2]
> > > https://lists.apache.org/thread/kvdz39t5wndojbtqqn84smm51rt89fnx
> > > > > > > [3] https://spdx.dev/
> > > > > > > [4] https://cyclonedx.org/
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > > > > security-discuss-unsubscribe@community.apache.org <mailto:
> security-discuss-unsubscribe@community.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > security-discuss-help@community.apache.org <mailto:
> security-discuss-help@community.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > security-discuss-unsubscribe@community.apache.org <mailto:
> security-discuss-unsubscribe@community.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > > security-discuss-help@community.apache.org <mailto:
> security-discuss-help@community.apache.org>
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > security-discuss-unsubscribe@community.apache.org <mailto:
> security-discuss-unsubscribe@community.apache.org>
> > > > For additional commands, e-mail:
> > > > security-discuss-help@community.apache.org <mailto:
> security-discuss-help@community.apache.org>
> > > >
> > > >
> > >
> >
>
>
RE: SBOM Generation
Posted by Gary O'Neall <ga...@sourceauditor.com>.
Greetings all – just catching up on the thread.
I’m not a member of the security-discuss Apache email list, so be sure to cc me if you would like any follow-up on the SPDX maven plugin.
I developed and currently maintain an SPDX maven plugin for SPDX – the repo is at https://github.com/spdx/spdx-maven-plugin
I use the plugin myself for adding SPDX documents to the SPDX library and other open source projects.
I’m working on a rather significant update to the plugin to support the upcoming SPDX 2.3 spec release along with adding support for producing a more compact JSON format. If you want to see the work in progress, visit the v23 branch <https://github.com/spdx/spdx-maven-plugin/tree/v23> in the repo.
Feedback and collaboration on the plugin is very much welcome – especially over the next couple weeks as I’m updating the plugin.
A few other random notes on the longer thread:
* Agree with Steve’s comment on supporting both SPDX and CycloneDX. I personally think both formats will be around for a while and will have their own communities (with some overlap). SPDX has gained some significant adoption in the commercial software world and CycloneDX had gained a lot of traction in the security space (as Steve noted).
* I’ve been working with members of the CycloneDX community to make the 2 formats more interoperable. We’re working on tools and spec improvements to make it easier for folks to support both formats. For example, the upcoming SPDX 2.3 has a couple of specific enhancement to enable higher fidelity transformations between the formats.
If you have any questions on the plugin or SPDX in general, don’t hesitate to ask me, post an issue to the maven repo, or join the SPDX tech email list: spdx-tech@lists.spdx.org <ma...@lists.spdx.org>
Best regards,
Gary O’Neall
From: Brandon Lum <lu...@google.com>
Sent: Wednesday, August 3, 2022 2:04 PM
To: security-discuss@community.apache.org
Cc: Matt Juntunen <ma...@gmail.com>; Gary O'Neall <ga...@sourceauditor.com>
Subject: Re: SBOM Generation
Gary O'Neall maintains the java library https://github.com/spdx/Spdx-Java-Library, which is used to build some of the tooling: https://github.com/spdx/tools-java. Those repos would be preferred.
I'm not too familiar with the Java ecosystem so going to defer to Gary O'neall (+CC)
On Tue, Aug 2, 2022 at 6:57 AM Gary Gregory <garydgregory@gmail.com <ma...@gmail.com> > wrote:
Hi Brandon,
Is there a Maven plugin that is preferred for SPDX?
Gary
On Mon, Aug 1, 2022, 16:36 Brandon Lum <lumb@google.com.invalid <ma...@google.com.invalid> > wrote:
> Regardless of format, equally important is the process and use of SBOMs
> within the ecosystem - integrating them into inventory/CMDB and mapping it
> to vulnerabilities and VEX type documents. I look forward to joining
> the discussions and helping to figure this out. As part of Google Open
> Source Team (GOSST), we are working on the missing pieces (around
> sharing/mapping/discoverability and resolving vulnerabilities with
> OSV/VEX).
>
> From a format perspective, we are actively engaged in SPDX.
>
> On Fri, Jul 22, 2022 at 2:05 AM Mark J Cox <mjc@apache.org <ma...@apache.org> > wrote:
>
> > Hi Matt;
> >
> > Regarding OpenSSF participation, they are expecting us to turn up at some
> > point to that working group, so you just need to hop on one of their
> future
> > zoom calls. There's no need for us or you to do anything to join the
> > organisation or pre-notify them, the working groups are open. I expect
> > they're going to be working on producing simple advice and are looking
> for
> > our input as much as anything to help them figure out what advice is
> useful
> > for them to give, so maybe it's a little chicken-and-egg. I''m hoping
> that
> > advice is useful to us, but we've certainly not made any decisions on if
> > we'll adopt it at this early stage.
> >
> > I hadn't realised SBOMs like CycloneDX could include vulnerability lists,
> > because I see SBOM as being immutable; and a brief glance shows they're
> > thinking of vulnerabilities in dependencies known at build time (although
> > perhaps our guidance really ought to be to not ship builds with
> > dependencies with known security issues!). There's other formats for
> > disclosing later-found-vulnerabilities, this isn't in the scope of SBOM.
> >
> > (Also, all, please do update
> > https://cwiki.apache.org/confluence/display/COMDEV/SBOM to capture any
> ASF
> > work or thinking on SBOM or links to OpenSSF work in progress etc)
> >
> > Regards, Mark
> >
> >
> > On Fri, Jul 22, 2022 at 3:52 AM Matt Juntunen <matt.a.juntunen@gmail.com <ma...@gmail.com>
> >
> > wrote:
> >
> > > Hello all,
> > >
> > > Continuing the conversation here...
> > >
> > > Gary, I wouldn't say that an SBOM is an XML transformation of a POM.
> > > CycloneDX, for example, can contain information not in a POM, such as
> > > license information, service relationships, and vulnerabilities [1].
> > > The component identifiers used are also different in that they
> > > describe the component uniquely across the entire software space
> > > (different languages, packaging schemes, etc.) and not just in the
> > > Maven ecosystem. However, for the purposes of Apache Commons, I expect
> > > that there will be a good amount of overlap between the information in
> > > the POM and that in the SBOM.
> > >
> > > Mark, can you provide an more details on how we should interact with
> > > OpenSSF? Do we simply show up in the Zoom meeting or is there some
> > > sort of protocol we need to follow? Are you picturing us following
> > > their lead on SBOM recommendations?
> > >
> > > Regards,
> > > Matt J
> > >
> > > [1] https://cyclonedx.org/specification/overview/
> > >
> > > On Thu, Jul 21, 2022 at 12:51 PM David Nalley <david@gnsa.us <ma...@gnsa.us> > wrote:
> > > >
> > > > I hesitate to weigh in because I am not going to be doing any of the
> > > work,
> > > > but I think it's useful to consider what you're trying to accomplish
> > with
> > > > SBOM. I used to spend a lot of time in the SBOM space.
> > > >
> > > > If it's license compliance, SPDX makes a lot of sense. It was built
> > from
> > > > the ground up to be a license compliance data exchange format.
> > > > Folks are aggressively working on SPDX 3.0 and adding some uses cases
> > > > around security and to address some of the gaps that SBOM advocates
> > have
> > > > called out.
> > > >
> > > > CycloneDX was built from the ground up as a SBOM and security tool.
> > > What's
> > > > really telling for me is that there are already a lot of tools for
> > > sharing,
> > > > querying, and managing BoMs in the CycloneDX format. Just generating
> > the
> > > > BoM may be all that we do, but for it to be useful to our users they
> > need
> > > > tools that can ingest, and do something with the BoM. That's
> improving
> > by
> > > > the day with SPDX, but great tooling exists already for CycloneDX.
> > > >
> > > > --David
> > > >
> > > >
> > > >
> > > > On Mon, Jul 18, 2022 at 8:18 AM Steve Springett
> > > > <steve.springett@owasp.org <ma...@owasp.org> .invalid> wrote:
> > > >
> > > > > There may be value in supporting both formats. Most security
> vendors
> > > > > support the CycloneDX standard since its from OWASP and was
> > > purpose-built
> > > > > for security use cases. Some security vendors support SPDX as well.
> > > OpenSSF
> > > > > has publicly stated that they will only support SPDX due to both
> > > OpenSSF
> > > > > and SPDX being Linux Foundation projects. Unfortunately, this view
> is
> > > > > contrary to the adoption we’re seeing in the global security
> > community.
> > > > >
> > > > > Sonatype, the stewards of Maven Central, have been a big supporter
> of
> > > > > CycloneDX since 2019 and have recommitted to favoring it going
> > forward.
> > > > >
> > > > >
> > >
> >
> https://www.sonatype.com/press-releases/sonatype-embraces-cyclonedx-standard-for-integrating-software-bills-of-materials-sboms
> > > > >
> > > > > Regardless, the end goal is to have authoritative SBOMs published
> to
> > > Maven
> > > > > Central similar to what DropWizard is doing.
> > > > >
> > > > >
> https://repo1.maven.org/maven2/io/dropwizard/dropwizard-core/2.1.1/
> > > > >
> > > > > Non-authorative SBOMs may be on the roadmap for Maven Central.
> > > > >
> > > > >
> > > > > —Steve
> > > > >
> > > > >
> > > > > On 2022/07/17 16:11:28 Matt Juntunen wrote:
> > > > > > Hello,
> > > > > >
> > > > > > The Apache Commons project recently received a PR [1] for our
> > parent
> > > > > > POM that includes the generation of software bill of materials
> > (SBOM)
> > > > > > artifacts during the build. During the following discussion [2]
> on
> > > our
> > > > > > dev mailing list, it was suggested that this mailing list would
> be
> > > the
> > > > > > appropriate place to discuss this topic. In short, we are trying
> to
> > > > > > answer the following questions:
> > > > > >
> > > > > > 1. Should our projects include SBOM artifacts?
> > > > > > 2. If so, what format should we use (e.g., SPDX [3] or CycloneDX
> > > [4])?
> > > > > >
> > > > > > I am of the opinion that the ASF in general (and Apache Commons
> in
> > > > > > particular) should provide these artifacts when appropriate as
> they
> > > 1)
> > > > > > are useful when performing vulnerability and software supply
> chain
> > > > > > analysis and 2) promote good cybersecurity practices in the
> > > community.
> > > > > >
> > > > > > What guidance does the ASF provide on this issue? What, if any,
> > > > > > standards have been adopted?
> > > > > >
> > > > > > Regards,
> > > > > > Matt J
> > > > > >
> > > > > > [1] https://github.com/apache/commons-parent/pull/122
> > > > > > [2]
> > https://lists.apache.org/thread/kvdz39t5wndojbtqqn84smm51rt89fnx
> > > > > > [3] https://spdx.dev/
> > > > > > [4] https://cyclonedx.org/
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > > security-discuss-unsubscribe@community.apache.org <ma...@community.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > security-discuss-help@community.apache.org <ma...@community.apache.org>
> > > > > >
> > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > security-discuss-unsubscribe@community.apache.org <ma...@community.apache.org>
> > > > > For additional commands, e-mail:
> > > > > security-discuss-help@community.apache.org <ma...@community.apache.org>
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > security-discuss-unsubscribe@community.apache.org <ma...@community.apache.org>
> > > For additional commands, e-mail:
> > > security-discuss-help@community.apache.org <ma...@community.apache.org>
> > >
> > >
> >
>
Re: SBOM Generation
Posted by Brandon Lum <lu...@google.com.INVALID>.
Gary O'Neall maintains the java library
https://github.com/spdx/Spdx-Java-Library, which is used to build some of
the tooling: https://github.com/spdx/tools-java. Those repos would be
preferred.
I'm not too familiar with the Java ecosystem so going to defer to Gary
O'neall (+CC)
On Tue, Aug 2, 2022 at 6:57 AM Gary Gregory <ga...@gmail.com> wrote:
> Hi Brandon,
>
> Is there a Maven plugin that is preferred for SPDX?
>
> Gary
>
> On Mon, Aug 1, 2022, 16:36 Brandon Lum <lu...@google.com.invalid> wrote:
>
> > Regardless of format, equally important is the process and use of SBOMs
> > within the ecosystem - integrating them into inventory/CMDB and mapping
> it
> > to vulnerabilities and VEX type documents. I look forward to joining
> > the discussions and helping to figure this out. As part of Google Open
> > Source Team (GOSST), we are working on the missing pieces (around
> > sharing/mapping/discoverability and resolving vulnerabilities with
> > OSV/VEX).
> >
> > From a format perspective, we are actively engaged in SPDX.
> >
> > On Fri, Jul 22, 2022 at 2:05 AM Mark J Cox <mj...@apache.org> wrote:
> >
> > > Hi Matt;
> > >
> > > Regarding OpenSSF participation, they are expecting us to turn up at
> some
> > > point to that working group, so you just need to hop on one of their
> > future
> > > zoom calls. There's no need for us or you to do anything to join the
> > > organisation or pre-notify them, the working groups are open. I expect
> > > they're going to be working on producing simple advice and are looking
> > for
> > > our input as much as anything to help them figure out what advice is
> > useful
> > > for them to give, so maybe it's a little chicken-and-egg. I''m hoping
> > that
> > > advice is useful to us, but we've certainly not made any decisions on
> if
> > > we'll adopt it at this early stage.
> > >
> > > I hadn't realised SBOMs like CycloneDX could include vulnerability
> lists,
> > > because I see SBOM as being immutable; and a brief glance shows they're
> > > thinking of vulnerabilities in dependencies known at build time
> (although
> > > perhaps our guidance really ought to be to not ship builds with
> > > dependencies with known security issues!). There's other formats for
> > > disclosing later-found-vulnerabilities, this isn't in the scope of
> SBOM.
> > >
> > > (Also, all, please do update
> > > https://cwiki.apache.org/confluence/display/COMDEV/SBOM to capture any
> > ASF
> > > work or thinking on SBOM or links to OpenSSF work in progress etc)
> > >
> > > Regards, Mark
> > >
> > >
> > > On Fri, Jul 22, 2022 at 3:52 AM Matt Juntunen <
> matt.a.juntunen@gmail.com
> > >
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > Continuing the conversation here...
> > > >
> > > > Gary, I wouldn't say that an SBOM is an XML transformation of a POM.
> > > > CycloneDX, for example, can contain information not in a POM, such as
> > > > license information, service relationships, and vulnerabilities [1].
> > > > The component identifiers used are also different in that they
> > > > describe the component uniquely across the entire software space
> > > > (different languages, packaging schemes, etc.) and not just in the
> > > > Maven ecosystem. However, for the purposes of Apache Commons, I
> expect
> > > > that there will be a good amount of overlap between the information
> in
> > > > the POM and that in the SBOM.
> > > >
> > > > Mark, can you provide an more details on how we should interact with
> > > > OpenSSF? Do we simply show up in the Zoom meeting or is there some
> > > > sort of protocol we need to follow? Are you picturing us following
> > > > their lead on SBOM recommendations?
> > > >
> > > > Regards,
> > > > Matt J
> > > >
> > > > [1] https://cyclonedx.org/specification/overview/
> > > >
> > > > On Thu, Jul 21, 2022 at 12:51 PM David Nalley <da...@gnsa.us> wrote:
> > > > >
> > > > > I hesitate to weigh in because I am not going to be doing any of
> the
> > > > work,
> > > > > but I think it's useful to consider what you're trying to
> accomplish
> > > with
> > > > > SBOM. I used to spend a lot of time in the SBOM space.
> > > > >
> > > > > If it's license compliance, SPDX makes a lot of sense. It was built
> > > from
> > > > > the ground up to be a license compliance data exchange format.
> > > > > Folks are aggressively working on SPDX 3.0 and adding some uses
> cases
> > > > > around security and to address some of the gaps that SBOM advocates
> > > have
> > > > > called out.
> > > > >
> > > > > CycloneDX was built from the ground up as a SBOM and security tool.
> > > > What's
> > > > > really telling for me is that there are already a lot of tools for
> > > > sharing,
> > > > > querying, and managing BoMs in the CycloneDX format. Just
> generating
> > > the
> > > > > BoM may be all that we do, but for it to be useful to our users
> they
> > > need
> > > > > tools that can ingest, and do something with the BoM. That's
> > improving
> > > by
> > > > > the day with SPDX, but great tooling exists already for CycloneDX.
> > > > >
> > > > > --David
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jul 18, 2022 at 8:18 AM Steve Springett
> > > > > <st...@owasp.org.invalid> wrote:
> > > > >
> > > > > > There may be value in supporting both formats. Most security
> > vendors
> > > > > > support the CycloneDX standard since its from OWASP and was
> > > > purpose-built
> > > > > > for security use cases. Some security vendors support SPDX as
> well.
> > > > OpenSSF
> > > > > > has publicly stated that they will only support SPDX due to both
> > > > OpenSSF
> > > > > > and SPDX being Linux Foundation projects. Unfortunately, this
> view
> > is
> > > > > > contrary to the adoption we’re seeing in the global security
> > > community.
> > > > > >
> > > > > > Sonatype, the stewards of Maven Central, have been a big
> supporter
> > of
> > > > > > CycloneDX since 2019 and have recommitted to favoring it going
> > > forward.
> > > > > >
> > > > > >
> > > >
> > >
> >
> https://www.sonatype.com/press-releases/sonatype-embraces-cyclonedx-standard-for-integrating-software-bills-of-materials-sboms
> > > > > >
> > > > > > Regardless, the end goal is to have authoritative SBOMs published
> > to
> > > > Maven
> > > > > > Central similar to what DropWizard is doing.
> > > > > >
> > > > > >
> > https://repo1.maven.org/maven2/io/dropwizard/dropwizard-core/2.1.1/
> > > > > >
> > > > > > Non-authorative SBOMs may be on the roadmap for Maven Central.
> > > > > >
> > > > > >
> > > > > > —Steve
> > > > > >
> > > > > >
> > > > > > On 2022/07/17 16:11:28 Matt Juntunen wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > The Apache Commons project recently received a PR [1] for our
> > > parent
> > > > > > > POM that includes the generation of software bill of materials
> > > (SBOM)
> > > > > > > artifacts during the build. During the following discussion [2]
> > on
> > > > our
> > > > > > > dev mailing list, it was suggested that this mailing list would
> > be
> > > > the
> > > > > > > appropriate place to discuss this topic. In short, we are
> trying
> > to
> > > > > > > answer the following questions:
> > > > > > >
> > > > > > > 1. Should our projects include SBOM artifacts?
> > > > > > > 2. If so, what format should we use (e.g., SPDX [3] or
> CycloneDX
> > > > [4])?
> > > > > > >
> > > > > > > I am of the opinion that the ASF in general (and Apache Commons
> > in
> > > > > > > particular) should provide these artifacts when appropriate as
> > they
> > > > 1)
> > > > > > > are useful when performing vulnerability and software supply
> > chain
> > > > > > > analysis and 2) promote good cybersecurity practices in the
> > > > community.
> > > > > > >
> > > > > > > What guidance does the ASF provide on this issue? What, if any,
> > > > > > > standards have been adopted?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Matt J
> > > > > > >
> > > > > > > [1] https://github.com/apache/commons-parent/pull/122
> > > > > > > [2]
> > > https://lists.apache.org/thread/kvdz39t5wndojbtqqn84smm51rt89fnx
> > > > > > > [3] https://spdx.dev/
> > > > > > > [4] https://cyclonedx.org/
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > > > > security-discuss-unsubscribe@community.apache.org
> > > > > > > For additional commands, e-mail:
> > > > > > security-discuss-help@community.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > security-discuss-unsubscribe@community.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > security-discuss-help@community.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > security-discuss-unsubscribe@community.apache.org
> > > > For additional commands, e-mail:
> > > > security-discuss-help@community.apache.org
> > > >
> > > >
> > >
> >
>
Re: SBOM Generation
Posted by Gary Gregory <ga...@gmail.com>.
Hi Brandon,
Is there a Maven plugin that is preferred for SPDX?
Gary
On Mon, Aug 1, 2022, 16:36 Brandon Lum <lu...@google.com.invalid> wrote:
> Regardless of format, equally important is the process and use of SBOMs
> within the ecosystem - integrating them into inventory/CMDB and mapping it
> to vulnerabilities and VEX type documents. I look forward to joining
> the discussions and helping to figure this out. As part of Google Open
> Source Team (GOSST), we are working on the missing pieces (around
> sharing/mapping/discoverability and resolving vulnerabilities with
> OSV/VEX).
>
> From a format perspective, we are actively engaged in SPDX.
>
> On Fri, Jul 22, 2022 at 2:05 AM Mark J Cox <mj...@apache.org> wrote:
>
> > Hi Matt;
> >
> > Regarding OpenSSF participation, they are expecting us to turn up at some
> > point to that working group, so you just need to hop on one of their
> future
> > zoom calls. There's no need for us or you to do anything to join the
> > organisation or pre-notify them, the working groups are open. I expect
> > they're going to be working on producing simple advice and are looking
> for
> > our input as much as anything to help them figure out what advice is
> useful
> > for them to give, so maybe it's a little chicken-and-egg. I''m hoping
> that
> > advice is useful to us, but we've certainly not made any decisions on if
> > we'll adopt it at this early stage.
> >
> > I hadn't realised SBOMs like CycloneDX could include vulnerability lists,
> > because I see SBOM as being immutable; and a brief glance shows they're
> > thinking of vulnerabilities in dependencies known at build time (although
> > perhaps our guidance really ought to be to not ship builds with
> > dependencies with known security issues!). There's other formats for
> > disclosing later-found-vulnerabilities, this isn't in the scope of SBOM.
> >
> > (Also, all, please do update
> > https://cwiki.apache.org/confluence/display/COMDEV/SBOM to capture any
> ASF
> > work or thinking on SBOM or links to OpenSSF work in progress etc)
> >
> > Regards, Mark
> >
> >
> > On Fri, Jul 22, 2022 at 3:52 AM Matt Juntunen <matt.a.juntunen@gmail.com
> >
> > wrote:
> >
> > > Hello all,
> > >
> > > Continuing the conversation here...
> > >
> > > Gary, I wouldn't say that an SBOM is an XML transformation of a POM.
> > > CycloneDX, for example, can contain information not in a POM, such as
> > > license information, service relationships, and vulnerabilities [1].
> > > The component identifiers used are also different in that they
> > > describe the component uniquely across the entire software space
> > > (different languages, packaging schemes, etc.) and not just in the
> > > Maven ecosystem. However, for the purposes of Apache Commons, I expect
> > > that there will be a good amount of overlap between the information in
> > > the POM and that in the SBOM.
> > >
> > > Mark, can you provide an more details on how we should interact with
> > > OpenSSF? Do we simply show up in the Zoom meeting or is there some
> > > sort of protocol we need to follow? Are you picturing us following
> > > their lead on SBOM recommendations?
> > >
> > > Regards,
> > > Matt J
> > >
> > > [1] https://cyclonedx.org/specification/overview/
> > >
> > > On Thu, Jul 21, 2022 at 12:51 PM David Nalley <da...@gnsa.us> wrote:
> > > >
> > > > I hesitate to weigh in because I am not going to be doing any of the
> > > work,
> > > > but I think it's useful to consider what you're trying to accomplish
> > with
> > > > SBOM. I used to spend a lot of time in the SBOM space.
> > > >
> > > > If it's license compliance, SPDX makes a lot of sense. It was built
> > from
> > > > the ground up to be a license compliance data exchange format.
> > > > Folks are aggressively working on SPDX 3.0 and adding some uses cases
> > > > around security and to address some of the gaps that SBOM advocates
> > have
> > > > called out.
> > > >
> > > > CycloneDX was built from the ground up as a SBOM and security tool.
> > > What's
> > > > really telling for me is that there are already a lot of tools for
> > > sharing,
> > > > querying, and managing BoMs in the CycloneDX format. Just generating
> > the
> > > > BoM may be all that we do, but for it to be useful to our users they
> > need
> > > > tools that can ingest, and do something with the BoM. That's
> improving
> > by
> > > > the day with SPDX, but great tooling exists already for CycloneDX.
> > > >
> > > > --David
> > > >
> > > >
> > > >
> > > > On Mon, Jul 18, 2022 at 8:18 AM Steve Springett
> > > > <st...@owasp.org.invalid> wrote:
> > > >
> > > > > There may be value in supporting both formats. Most security
> vendors
> > > > > support the CycloneDX standard since its from OWASP and was
> > > purpose-built
> > > > > for security use cases. Some security vendors support SPDX as well.
> > > OpenSSF
> > > > > has publicly stated that they will only support SPDX due to both
> > > OpenSSF
> > > > > and SPDX being Linux Foundation projects. Unfortunately, this view
> is
> > > > > contrary to the adoption we’re seeing in the global security
> > community.
> > > > >
> > > > > Sonatype, the stewards of Maven Central, have been a big supporter
> of
> > > > > CycloneDX since 2019 and have recommitted to favoring it going
> > forward.
> > > > >
> > > > >
> > >
> >
> https://www.sonatype.com/press-releases/sonatype-embraces-cyclonedx-standard-for-integrating-software-bills-of-materials-sboms
> > > > >
> > > > > Regardless, the end goal is to have authoritative SBOMs published
> to
> > > Maven
> > > > > Central similar to what DropWizard is doing.
> > > > >
> > > > >
> https://repo1.maven.org/maven2/io/dropwizard/dropwizard-core/2.1.1/
> > > > >
> > > > > Non-authorative SBOMs may be on the roadmap for Maven Central.
> > > > >
> > > > >
> > > > > —Steve
> > > > >
> > > > >
> > > > > On 2022/07/17 16:11:28 Matt Juntunen wrote:
> > > > > > Hello,
> > > > > >
> > > > > > The Apache Commons project recently received a PR [1] for our
> > parent
> > > > > > POM that includes the generation of software bill of materials
> > (SBOM)
> > > > > > artifacts during the build. During the following discussion [2]
> on
> > > our
> > > > > > dev mailing list, it was suggested that this mailing list would
> be
> > > the
> > > > > > appropriate place to discuss this topic. In short, we are trying
> to
> > > > > > answer the following questions:
> > > > > >
> > > > > > 1. Should our projects include SBOM artifacts?
> > > > > > 2. If so, what format should we use (e.g., SPDX [3] or CycloneDX
> > > [4])?
> > > > > >
> > > > > > I am of the opinion that the ASF in general (and Apache Commons
> in
> > > > > > particular) should provide these artifacts when appropriate as
> they
> > > 1)
> > > > > > are useful when performing vulnerability and software supply
> chain
> > > > > > analysis and 2) promote good cybersecurity practices in the
> > > community.
> > > > > >
> > > > > > What guidance does the ASF provide on this issue? What, if any,
> > > > > > standards have been adopted?
> > > > > >
> > > > > > Regards,
> > > > > > Matt J
> > > > > >
> > > > > > [1] https://github.com/apache/commons-parent/pull/122
> > > > > > [2]
> > https://lists.apache.org/thread/kvdz39t5wndojbtqqn84smm51rt89fnx
> > > > > > [3] https://spdx.dev/
> > > > > > [4] https://cyclonedx.org/
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > > security-discuss-unsubscribe@community.apache.org
> > > > > > For additional commands, e-mail:
> > > > > security-discuss-help@community.apache.org
> > > > > >
> > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > security-discuss-unsubscribe@community.apache.org
> > > > > For additional commands, e-mail:
> > > > > security-discuss-help@community.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > security-discuss-unsubscribe@community.apache.org
> > > For additional commands, e-mail:
> > > security-discuss-help@community.apache.org
> > >
> > >
> >
>