lled "SBOM Everywhere" and have
> set up a SIG (sort of like our equivalent of a
> project-that-doesnt-release-code) to focus on it that meets biweekly by
> Zoom and ongoing via email and Slack:
>
> https://github.com/ossf/sbom-everywhere
>
> The goal of that s
lease-code) to focus on it that meets biweekly by
Zoom and ongoing via email and Slack:
https://github.com/ossf/sbom-everywhere
The goal of that stream is simple: get SBOM generation and consumption
implemented into build and release tools so that they become more built by
default and a low lift fo
o, or join the SPDX tech email
> list: spdx-t...@lists.spdx.org <mailto:spdx-t...@lists.spdx.org>
>
>
>
> Best regards,
> Gary O’Neall
>
>
>
> From: Brandon Lum
> Sent: Wednesday, August 3, 2022 2:04 PM
> To: security-discuss@community.apache.org
> Cc: Ma
spdx-t...@lists.spdx.org <mailto:spdx-t...@lists.spdx.org>
Best regards,
Gary O’Neall
From: Brandon Lum
Sent: Wednesday, August 3, 2022 2:04 PM
To: security-discuss@community.apache.org
Cc: Matt Juntunen ; Gary O'Neall
Subject: Re: SBOM Generation
Gary O'Neall maintains the java li
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,
Hi Brandon,
Is there a Maven plugin that is preferred for SPDX?
Gary
On Mon, Aug 1, 2022, 16:36 Brandon Lum 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
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
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
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
I quickly chatted to Josh Bressers who is chair for the OpenSSF security
tooling working group, and it looks like that group is going to be the
focal point for OpenSSF SBOM work. They're likely going to be first looking
to provide advice/a guide to OSS projects on SBOM. So it'd be worth us
Questions:
The goal for any SBOM is to be published right next to the jar and pom in a
Maven repository, right?
An SBOM is just an XML transformation of a POM into something else (XML,
JSON), right?
Gary
On Mon, Jul 18, 2022, 11:18 Steve Springett
wrote:
> There may be value in supporting
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
On Sun, Jul 17, 2022 at 5:11 PM 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
Found this: https://github.com/spdx/spdx-maven-plugin
Gary
On Sun, Jul 17, 2022, 13:26 Dominik Psenner wrote:
> SBOMs appear to be the solution, allowing introspection and thus provide a
> way for building automated tools that can answer tough questions, i.e.
> regarding IT security. As of the
SBOMs appear to be the solution, allowing introspection and thus provide a
way for building automated tools that can answer tough questions, i.e.
regarding IT security. As of the format, I would stick with the ISO
standard: SPDX.
--
Sent from my phone. Typos are a kind gift to anyone who happens
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
16 matches
Mail list logo
