|
SBOM is included in the latest Omnibus bill
‘‘SEC. 524B. ENSURING CYBERSECURITY OF DEVICES. ‘‘(3) provide to the Secretary a software bill of 20 materials, including commercial, open-source, and 21 off-the-shelf software components;
This text is referring to medical devices. https://www.appropriations.senate.gov/imo/media/doc/JRQ121922.PDF
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
|
|
|
|
SBOM stripped from NDAA may reappear in the Omnibus bill
Hello Everyone,
I’ve heard the SBOM provision that was in the NDAA is under consideration for the Omnibus Bill. I sent written testimony to the Senate Appropriations Committee deliberating the Omnibus Bill and posted a nearly identical version of my written testimony online:
Please show your support for SBOM by sending written testimony to Congress.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
|
|
|
|
Re: Congress is considering removing the SBOM provision from the NDAA Bill now before Congress
It’s all moot now. The bill passed the House and Senate today and is on it’s way to the President’s desk. https://www.congress.gov/bill/117th-congress/house-bill/7776/text
All of the software supply chain provisions have been gutted in the final NDAA.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of Brian Fox
Sent: Friday, December 16, 2022 5:43 PM To: spdx@... Subject: Re: [spdx] Congress is considering removing the SBOM provision from the NDAA Bill now before Congress
You shared this previously https://insidecybersecurity.com/share/14118
I think that's a significant reason. And even as a proponent / agitator of SBOMs myself, I find the arguments they lay out compelling as we sit right now.
On Fri, Dec 16, 2022 at 4:33 PM Dick Brooks <dick@...> wrote:
|
|
|
|
Re: Congress is considering removing the SBOM provision from the NDAA Bill now before Congress
Brian Fox
You shared this previously https://insidecybersecurity.com/share/14118 I think that's a significant reason. And even as a proponent / agitator of SBOMs myself, I find the arguments they lay out compelling as we sit right now. On Fri, Dec 16, 2022 at 4:33 PM Dick Brooks <dick@...> wrote:
|
|
|
|
Re: Congress is considering removing the SBOM provision from the NDAA Bill now before Congress
Eliot,
I’m not familiar with the GSA work you mention. Can you provide a pointer to GSA documents indicating that SBOM’s are required.
I’ve seen where SBOM’s are required in the Department of State Evolve RFP.
Also, why would ITI and others be lobbying Congress to have SBOM removed from the NDAA, as the linked article indicates.
There must be a reason. I suspect it’s because Congress creates laws, and the NDAA law makes SBOM a legal requirement.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of Eliot Lear
Sent: Friday, December 16, 2022 4:13 PM To: spdx@... Subject: Re: [spdx] Congress is considering removing the SBOM provision from the NDAA Bill now before Congress
Why? GSA is already specifying SBOMs. And is the list to encourage congressional lobbying? On 16.12.22 20:38, Dick Brooks wrote:
|
|
|
|
Re: Congress is considering removing the SBOM provision from the NDAA Bill now before Congress
Eliot Lear
Why? GSA is already specifying SBOMs. And is the list to
encourage congressional lobbying? On 16.12.22 20:38, Dick Brooks wrote:
|
|
|
|
Congress is considering removing the SBOM provision from the NDAA Bill now before Congress
FYI:
Please get the word out to restore the SBOM provision in the NDAA.
“I don't see why any member of Congress would want to hamstring their own cybersecurity professionals from monitoring and mitigating software vulnerabilities that are detectable using an SBOM. Members of Congress please help your own cybersecurity professionals that work so hard to keep you and your districts safe from hacker attacks. Restore the SBOM provision in the NDAA.”
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
|
|
|
|
Possible Vendor Day
Sending this to the SPDX list per Gary’s suggestion at today’s SPDX tech team meeting. .
Last Week I attended a FERC-DOE supply chain technical conference and a suggestion was made to host a “SBOM Vendor Day” to show the energy industry what is available for processing (creating/consuming) SBOM’s.
At this point it’s “just an idea” and there is nothing concrete. I’ve been collecting email from parties with an interest in participating in a SBOM Vendor Day, IF this “Vendor Day” concept comes to fruition.
Please email me if interested in participating in a SBOM Vendor Day presentation for the Energy industry.
FYI: So far OWASP and Microsoft have expressed interest in participating, IF this SBOM Vendor Day comes to fruition.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
|
|
|
|
Your feedback as open source licenses expert/user about OSLiFe-DiSC tool
Sihem Ben Sassi
Dear all, A step forward to automate license processing is to characterize legal terms dealt with by licenses and describe licenses accordingly in order to reach a standardized model. To that end, we developed the OSLiFe-DiSC tool (https://sihem.pythonanywhere.com/ -- please refresh the page if an error is displayed--) based on an open source licenses feature model. It allows (1) discovering licenses features (i.e. description according to the model), (2) selecting licenses satisfying desired features, and (3) comparing two licenses. A 8 minutes video demo (https://youtu.be/VwzBq7XBTvk) shows the OSLiFe-DiSC functionalities. I would ask you, as licenses expert and/or user, to try the tool and give your feedback by filling the questionnaire accessible through the peach colored button inside the OSLiFe-DiSC tool, or directly through https://cutt.ly/G0eiq92 If needed, you may see the manuscript available at https://cutt.ly/P0wsuA for more information about extracted legal terms represented by the features of the licenses model. Your feedback is very appreciated and needed. Best Regards, Sihem Ben Sassi PhD, HDR in computer sciences |
|
|
|
Re: Interpreting SPDX Validator Error: SpdxIdInUseException ... ExtractedLicensingInfo
Keith Zantow
Thank you, Gary! I wasn't sure where the right place was to ask this question. Issue submitted with example: https://github.com/spdx/spdx-online-tools/issues/414 On Wed, Dec 7, 2022 at 5:01 PM Gary O'Neall <gary@...> wrote:
|
|
|
|
Re: Interpreting SPDX Validator Error: SpdxIdInUseException ... ExtractedLicensingInfo
Gary O'Neall
Hi Keith,
The “Unexpected Error” usually indicates an issue with the validation tool itself. Can you post an issue at https://github.com/spdx/spdx-online-tools/issues and attach a file that reproduces the problem? Alternatively, you can email me the information at gary@....
Thanks,
From: spdx@... <spdx@...> On Behalf Of Keith Zantow via lists.spdx.org
Sent: Tuesday, December 6, 2022 1:19 PM To: spdx@... Subject: [spdx] Interpreting SPDX Validator Error: SpdxIdInUseException ... ExtractedLicensingInfo
Hi,
I'm using the SPDX online validator and I'm trying to understand what this error means. Could someone shed some light on it?
Analysis exception processing SPDX file: Unexpected Error: org.spdx.library.model.SpdxIdInUseException: Can not create Apache-2.0. It is already in use with type ListedLicense which is incompatible with type ExtractedLicensingInfo
Thanks much, -Keith Zantow |
|
|
|
Interpreting SPDX Validator Error: SpdxIdInUseException ... ExtractedLicensingInfo
Keith Zantow
Hi, I'm using the SPDX online validator and I'm trying to understand what this error means. Could someone shed some light on it? Analysis exception processing SPDX file: Unexpected Error: org.spdx.library.model.SpdxIdInUseException: Can not create Apache-2.0. It is already in use with type ListedLicense which is incompatible with type ExtractedLicensingInfo Thanks much, -Keith Zantow |
|
|
|
Re: SPDX creation phase
Having also been in that call I would also like this clarification. The idea behind having this information available is for the recipient to make her or his own judgement on how accurate they expect such to be.
If this has been solved in the SPDX community that would be great. 😊 Steve’s comments on different “stages” was not something I had considered, but it does potentially complicate things.
BR J
From: spdx@... <spdx@...>
On Behalf Of Steve Kilbane via lists.spdx.org
Sent: Thursday, 1 December 2022 12:20 To: spdx@... Subject: [spdx] SPDX creation phase
Hi all,
One of the suggestions in today’s call for the OpenChain Telco SIG, where we’re discussing proposals for an SBOM standard for the Telecommunications industry, was:
> SBOMs conforming to the Telco SBOM Specification need to contain the information when the SBOM was created in the “Created” SPDX field and at what phase of the software build it was created (“pre-build”, “build-time” or “post-build”) in the CreatorComment SPDX field.
(See https://github.com/OpenChain-Project/Telco-WG/pull/15)
I raised a concern about ambiguity here, in that your application may be built from libraries that are built at an earlier stage, so the SBOM information may be created after some components are built, but before others. A recipient of the SBOM might also interpret each of these three phrases differently from the creator of the SBOM. I recall hearing that there have been conversations about many different SBOMs according to phase (source SBOM, build SBOM, deploy SBOM, cloud SBOM, etc.), so I wondered whether there was advice that the Telco SIG could lean upon, rather than trying to formulate a solution when it’s already a solved problem.
Apologies if this isn’t the right group.
steve
|
|
|
|
FERC-DOE Supply Chain Technical Conference on December 7, 2022 at FERC HQ in Washington.
Hoping to meet some people at this supply chain technical conference in Washington on December 7.
Please come out and show your support for SBOM in software supply chains and meet many of the people working on supply chain initiatives in the electric industry.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
|
|
|
|
Re: SPDX creation phase
Gary O'Neall
Hi Steve,
I’m going to include the SPDX tech group on the email thread – sorry to many of you for the duplication.
Steve – If you’re a member of that email we can continue the thread there.
There is a Build Profile working group which is tackling very similar problems for the SPDX 3.0 spec led by Brandon and Nisha (cc’d) – you may want to connect with that group.
For SPDX 2.3, I have a couple of thoughts and suggestions. I think the Creation Information created date will provide the information on when the SBOM was created. We don’t have any fields at the SPDX Document level to store and retrieve the build phase information, but we have added 3 new fields at the package level which may be useful:
For a typical SBOM, the SPDX document will have a Document Describes which points to the package the SBOM is describing. Although it isn’t direct, you could use the Built Date and Release Date along with the Creation information to determine where in the lifecycle the SBOM was created. Since these are optional fields, the Telco SIG would need to specify that they be included for the package in the Document Describes field.
Using the comment field for information not in the SPDX spec is an acceptable practice – especially if the information is intended to be human readable. You can also use an Annotation on the SPDX document for the same purpose. The advantage of the Annotation is you can have more than one with each Annotation having a specific purpose. For example, you could have an Annotation “Build-Phase: pre-build” and an separate annotation for unrelated information.
Best regards, Gary
From: spdx@... <spdx@...> On Behalf Of Steve Kilbane
Sent: Thursday, December 1, 2022 3:20 AM To: spdx@... Subject: [spdx] SPDX creation phase
Hi all,
One of the suggestions in today’s call for the OpenChain Telco SIG, where we’re discussing proposals for an SBOM standard for the Telecommunications industry, was:
> SBOMs conforming to the Telco SBOM Specification need to contain the information when the SBOM was created in the “Created” SPDX field and at what phase of the software build it was created (“pre-build”, “build-time” or “post-build”) in the CreatorComment SPDX field.
(See https://github.com/OpenChain-Project/Telco-WG/pull/15)
I raised a concern about ambiguity here, in that your application may be built from libraries that are built at an earlier stage, so the SBOM information may be created after some components are built, but before others. A recipient of the SBOM might also interpret each of these three phrases differently from the creator of the SBOM. I recall hearing that there have been conversations about many different SBOMs according to phase (source SBOM, build SBOM, deploy SBOM, cloud SBOM, etc.), so I wondered whether there was advice that the Telco SIG could lean upon, rather than trying to formulate a solution when it’s already a solved problem.
Apologies if this isn’t the right group.
steve
|
|
|
|
Re: SPDX creation phase
Steve,
SBOM’s are created to serve a purpose, for example some SBOM’s are used for license management, some are used for dependency tracking and the one I’m most familiar with is an SBOM used by a software consumer in a software risk assessment.
In the risk assessment case it’s imperative that the SBOM describe the contents of a software package used for installation and execution in a consumers digital ecosystem. Data in this SBOM, i.e. component names and versions, is more compatible with vulnerability databases when searching for CVE’s filed against component software, i.e. Log4j is a good example.
I can’t speak to SBOM’s used for other purposes.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of Steve Kilbane
Sent: Thursday, December 1, 2022 6:20 AM To: spdx@... Subject: [spdx] SPDX creation phase
Hi all,
One of the suggestions in today’s call for the OpenChain Telco SIG, where we’re discussing proposals for an SBOM standard for the Telecommunications industry, was:
> SBOMs conforming to the Telco SBOM Specification need to contain the information when the SBOM was created in the “Created” SPDX field and at what phase of the software build it was created (“pre-build”, “build-time” or “post-build”) in the CreatorComment SPDX field.
(See https://github.com/OpenChain-Project/Telco-WG/pull/15)
I raised a concern about ambiguity here, in that your application may be built from libraries that are built at an earlier stage, so the SBOM information may be created after some components are built, but before others. A recipient of the SBOM might also interpret each of these three phrases differently from the creator of the SBOM. I recall hearing that there have been conversations about many different SBOMs according to phase (source SBOM, build SBOM, deploy SBOM, cloud SBOM, etc.), so I wondered whether there was advice that the Telco SIG could lean upon, rather than trying to formulate a solution when it’s already a solved problem.
Apologies if this isn’t the right group.
steve
|
|
|
|
SPDX creation phase
Hi all,
One of the suggestions in today’s call for the OpenChain Telco SIG, where we’re discussing proposals for an SBOM standard for the Telecommunications industry, was:
> SBOMs conforming to the Telco SBOM Specification need to contain the information when the SBOM was created in the “Created” SPDX field and at what phase of the software build it was created (“pre-build”, “build-time” or “post-build”) in the CreatorComment SPDX field.
(See https://github.com/OpenChain-Project/Telco-WG/pull/15)
I raised a concern about ambiguity here, in that your application may be built from libraries that are built at an earlier stage, so the SBOM information may be created after some components are built, but before others. A recipient of the SBOM might also interpret each of these three phrases differently from the creator of the SBOM. I recall hearing that there have been conversations about many different SBOMs according to phase (source SBOM, build SBOM, deploy SBOM, cloud SBOM, etc.), so I wondered whether there was advice that the Telco SIG could lean upon, rather than trying to formulate a solution when it’s already a solved problem.
Apologies if this isn’t the right group.
steve
|
|
|
|
Re: Thurs SPDX General Meeting Reminder
Phil Odence
Small correction: Thurs is Dec 1.
From:
spdx@... <spdx@...> on behalf of Phil Odence via lists.spdx.org <phil.odence=synopsys.com@...> This month we’ll have a couple special presentations. Gary will give a debrief on Wednesday’s docfest. Alexios will walk is through the GitHub 3.0 directories so everyone knows how to contribute.
We’d like to add a regular General Meeting topic on presentation folks are delivering featuring SPDX. If you know if any recent or upcoming please add them to the repo created for this purpose: https://github.com/spdx/outreach/blob/main/SPDX-presentations.md
GENERAL MEETING
Meeting Time: Thurs, Dec 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html
Join the meeting:
Etherpad for minutes: https://spdx.swinslow.net/p/spdx-general-minutes
Administrative Agenda Attendance Minutes Approval: https://github.com/spdx/meetings/blob/main/general/2022-11-03.md
Presentations – Gary and Alexios
Steering Committee Update - Phil
Technical Team Report – Kate/Gary/Others
Legal Team Report – Jilayne/Paul/Steve
Outreach/Website Team Report – Jack/Sebastian/Alexios
|
|
|
|
Thurs SPDX General Meeting Reminder
Phil Odence
This month we’ll have a couple special presentations. Gary will give a debrief on Wednesday’s docfest. Alexios will walk is through the GitHub 3.0 directories so everyone knows how to contribute.
We’d like to add a regular General Meeting topic on presentation folks are delivering featuring SPDX. If you know if any recent or upcoming please add them to the repo created for this purpose: https://github.com/spdx/outreach/blob/main/SPDX-presentations.md
GENERAL MEETING
Meeting Time: Thurs, Dec 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html
Join the meeting:
Etherpad for minutes: https://spdx.swinslow.net/p/spdx-general-minutes
Administrative Agenda Attendance Minutes Approval: https://github.com/spdx/meetings/blob/main/general/2022-11-03.md
Presentations – Gary and Alexios
Steering Committee Update - Phil
Technical Team Report – Kate/Gary/Others
Legal Team Report – Jilayne/Paul/Steve
Outreach/Website Team Report – Jack/Sebastian/Alexios
|
|
|
|
Re: SBOM Survey
karen.bennet
This survey was a great start to gather feedback about SBOM, but it would be good to get some questions about AI sBOM, they need additional information collected On Thu, Nov 10, 2022 at 1:34 AM Wintersgill, Nathan <njwintersgill@...> wrote:
|
|
|
