Topic for discussion: how do we link different Bill of Materials?
For anyone who can attend FOSDEM in Brussels on 5 February 2023, we have a track (“devroom”) on Software Bills of Materials, where a number of SBOM-related topics will be discussed.
The Call for Participation is currently open, till 28 November:
https://gist.github.com/zvr/c852b4a560ac2c67885c473034cd4a93
Hope to see you there!
-- zvr
Sent: Saturday, 19 November, 2022 01:13
To: main@...
Subject: Re: [openchain] Topic for discussion: how do we link different Bill of Materials?
Hi Jacob, Shane and all,
Thank you for sharing my thought and your interesting response.
Now some of the OpenChain Japan Sub workgroup member started
discussing about SBOM deeply from the perspective how to use SBOM
effectively in the complex supply chains and what is the problem to use it.
We are still in the early stages of discussions, but we will be sharing our
discussions and materials publicly in the future, so could you give us some advice?
And it might be difficult to participate because the language barriers and
time zones, but if you know similar discussion opportunities elsewhere,
please let me know.
I would like to participate as much as possible.
Thanks,
-- kobota
This is a great point, and one which I believe has been evolving over time. SAST, DAST, IAST, and RASP outputs similarly all show code analysis at different stages of the software build and distribution process. I would say for storage a Software Artifact Repository is the industry standard for code scanning and will most likely continue for SBOM results, but the combination of results will vary based on organizational policies, procedures, regulators, and other market factors.
If I put my computer forensics hat on, traceability and non-tampered evidence collection are paramount. Having the same piece of information at multiple stages of the software build and distribution process is informative in itself. Combination of the results may harm the overall goal. From a pragmatic perspective this is a significant data storage and analysis challenge.
Tying things together, I believe the SBOM consideration material you have made is great and brings light to an important issue. I also believe it fits together remarkably well with the 'SCA tooling evaluation metrics' project mentioned in yesterday's monthly call. Perhaps these stakeholders can work together?
On Tue, Nov 15, 2022 at 6:47 AM Shane Coughlan <scoughlan@...> wrote:
Kobota San has raised an interesting topic for discussion. Attached see slides with an overview.
Summary: there are various different types of SBOM involved in preparing various types of product. For example, Build SBOM, Binary SBOM, Source SBOM.
What is the best way to combine these for final records?
Thoughts and suggestions?
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon
Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
Hi Jacob, Shane and all,
Thank you for sharing my thought and your interesting response.
Now some of the OpenChain Japan Sub workgroup member started
discussing about SBOM deeply from the perspective how to use SBOM
effectively in the complex supply chains and what is the problem to use it.
We are still in the early stages of discussions, but we will be sharing our
discussions and materials publicly in the future, so could you give us some advice?
And it might be difficult to participate because the language barriers and
time zones, but if you know similar discussion opportunities elsewhere,
please let me know.
I would like to participate as much as possible.
Thanks,
-- kobota
Sent: Wednesday, November 16, 2022 1:10 AM
To: main@...
Subject: Re: [openchain] Topic for discussion: how do we link different Bill of Materials?
This is a great point, and one which I believe has been evolving over time. SAST, DAST, IAST, and RASP outputs similarly all show code analysis at different stages of the software build and distribution process. I would say for storage a Software Artifact Repository is the industry standard for code scanning and will most likely continue for SBOM results, but the combination of results will vary based on organizational policies, procedures, regulators, and other market factors.
If I put my computer forensics hat on, traceability and non-tampered evidence collection are paramount. Having the same piece of information at multiple stages of the software build and distribution process is informative in itself. Combination of the results may harm the overall goal. From a pragmatic perspective this is a significant data storage and analysis challenge.
Tying things together, I believe the SBOM consideration material you have made is great and brings light to an important issue. I also believe it fits together remarkably well with the 'SCA tooling evaluation metrics' project mentioned in yesterday's monthly call. Perhaps these stakeholders can work together?
On Tue, Nov 15, 2022 at 6:47 AM Shane Coughlan <scoughlan@...> wrote:
Kobota San has raised an interesting topic for discussion. Attached see slides with an overview.
Summary: there are various different types of SBOM involved in preparing various types of product. For example, Build SBOM, Binary SBOM, Source SBOM.
What is the best way to combine these for final records?
Thoughts and suggestions?
Kobota San has raised an interesting topic for discussion. Attached see slides with an overview.
Summary: there are various different types of SBOM involved in preparing various types of product. For example, Build SBOM, Binary SBOM, Source SBOM.
What is the best way to combine these for final records?
Thoughts and suggestions?
Summary: there are various different types of SBOM involved in preparing various types of product. For example, Build SBOM, Binary SBOM, Source SBOM.
What is the best way to combine these for final records?
Thoughts and suggestions?