I would support having both SPDX and CycloneDX. Both have proven viable in my 
testing. 

 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! β„’

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Eliot Lear <l...@cisco.com> 
Sent: Tuesday, January 05, 2021 10:53 AM
To: Dick Brooks <d...@reliableenergyanalytics.com>
Cc: Christopher Gates <chris.ga...@velentium.com>; opsawg@ietf.org; 
ntia-sbom-fram...@cert.org
Subject: Re: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: πŸ”” WG Adoption Call on 
draft-lear-opsawg-sbom-access-00

 

Ok.  Should I add something for CycloneDX?

 

Eliot





On 5 Jan 2021, at 16:51, Dick Brooks <d...@reliableenergyanalytics.com 
<mailto:d...@reliableenergyanalytics.com> > wrote:

 

I concur with Chris. I’ve heard reports of people trying to use SWID to 
communicate SBOM information and they are having to make some β€œbrave” 
assumptions in the process.  SPDX and CycloneDX seem  to be the only viable 
SBOM formats, based on my testing experience with both formats. 

 

There remain several issues on naming and identification conventions. A lot of 
the challenges I’ve experienced could be addressed if NIST NVD and NTIA SBOM 
parties could reach an agreement on how names/identifiers will be represented 
in their respective domains. It would only require a few elements to be agreed 
to, like Publisher name, Product name and Version identifier to make an 
impactful improvement in vulnerability search results, using SBOM data as 
inputs. 

 

Thanks,

 

Dick Brooks

<image001.jpg>

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! β„’

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: OPSAWG <opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org> > On 
Behalf Of Christopher Gates
Sent: Tuesday, January 05, 2021 10:27 AM
To: opsawg@ietf.org <mailto:opsawg@ietf.org> 
Subject: [OPSAWG] Fw: Re: [ntia-sbom-framing] Fwd: πŸ”” WG Adoption Call on 
draft-lear-opsawg-sbom-access-00

 

 

------ Forwarded Message ------

From: "Christopher Gates" <chris.ga...@velentium.com 
<mailto:chris.ga...@velentium.com> >

To: "Eliot Lear" <l...@cisco.com <mailto:l...@cisco.com> >; 
"ntia-sbom-fram...@cert.org <mailto:ntia-sbom-fram...@cert.org> " 
<ntia-sbom-fram...@cert.org <mailto:ntia-sbom-fram...@cert.org> >

Sent: 1/4/2021 2:48:51 PM

Subject: Re: [ntia-sbom-framing] Fwd: [OPSAWG] πŸ”” WG Adoption Call on 
draft-lear-opsawg-sbom-access-00

 

Eliot,

 

I joined the IETF WG, and I have some feedback....

 

<image002.png>

A "SWID tag" isn't an SBOM format, as stated here. It is an element inside of 
an SBOM.

Since we have removed SWID as a format we in the "NTIA SBOM WG are supporting 
for SBOM use, shouldn't this reference be removed from the IETF draft as well?

 

 

Also, I still think that creating a Bluetooth Low Energy SBOM Adopted Profile 
(via the Bluetooth SIG) that is harmonized with this would be a good thing:

<image003.png>

 

Due the the low bandwidth of BLE we wouldn't attempt to provide the SBOM via 
BLE, just the link to a URI that can deliver the SBOM.

It would create a standardized UUID (16 bit) for the SBOM Adopted Profile, and 
have a consistent set of characteristics being exposed via BLE.

This is exactly how an Adopted Profile is supposed to be defined and utilized.

 

 

Christopher Gates

--------------------------------

Director of Product Security

www.velentium.com <http://www.velentium.com/> 

(805)750-0171

520 Courtney Way Suite 110

Lafayette CO. 80026

(GMT-7)

 

Our new book is now shipping:

Medical Device Cybersecurity for Engineers and Manufacturers

U.S. 
<https://us.artechhouse.com/Medical-Device-Cybersecurity-A-Guide-for-Engineers-and-Manufacturers-P2128.aspx>
  | Worldwide 
<https://uk.artechhouse.com/Medical-Device-Cybersecurity-A-Guide-for-Engineers-and-Manufacturers-P2073.aspx>
 

Amazon 
<https://www.amazon.com/Medical-Device-Cybersecurity-Engineers-Manufacturers/dp/1630818151/ref=sr_1_1?dchild=1&keywords=Axel+Wirth&qid=1592335625&sr=8-1>
 & Digital 
<https://us.artechhouse.com/Medical-Device-Cybersecurity-for-Engineers-and-Manufacturers-P2174.aspx>
 

Security Book Of The Year! 
<https://engineering.tapad.com/the-best-information-security-books-of-2020-e7430444fbd4>
 

 

β€œIf everyone is thinking alike, then somebody isn't thinking.” -George S. Patton

"Facts are stubborn things."  -John Adams, 1770

 

------ Original Message ------

From: "Eliot Lear via ntia-sbom-framing" <ntia-sbom-fram...@cert.org 
<mailto:ntia-sbom-fram...@cert.org> >

To: ntia-sbom-fram...@cert.org <mailto:ntia-sbom-fram...@cert.org> 

Sent: 1/4/2021 9:57:22 AM

Subject: [ntia-sbom-framing] Fwd: [OPSAWG] πŸ”” WG Adoption Call on 
draft-lear-opsawg-sbom-access-00

 

FYI- this is your opportunity to contribute to the IETF.  If you think sharing 
of SBOMs is important, this is a starting point for the IETF to begin work on 
that aspect, not an end point.  Please feel free to contribute by joining the 
opsawg IETF list at https://www.ietf.org/mailman/listinfo/opsawg.

 

Eliot






Begin forwarded message:

 

From: Henk Birkholz <henk.birkh...@sit.fraunhofer.de 
<mailto:henk.birkh...@sit.fraunhofer.de> >

Subject: [OPSAWG] πŸ”” WG Adoption Call on draft-lear-opsawg-sbom-access-00

Date: 4 January 2021 at 17:10:19 CET

To: opsawg <opsawg@ietf.org <mailto:opsawg@ietf.org> >

 

Dear OPSAWG members,

this starts a call for Working Group Adoption on 
https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, 
January 25.

As a reminder, this I-D describes different ways to acquire Software Bills of 
Material (SBOM) about distinguishable managed entities. The work was updated by 
the authors on October 13th and now elaborates on three ways SBOM can be found, 
including a MUD URI as one of the options.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org <mailto:OPSAWG@ietf.org> 
https://www.ietf.org/mailman/listinfo/opsawg

 


Disclaimer: The information and attachments transmitted by this e-mail are 
proprietary to Velentium, LLC and the information and attachments may be 
confidential and legally protected under applicable law and are intended for 
use only by the individual or entity to whom it was addressed. If you are not 
the intended recipient, you are hereby notified that any use, forwarding, 
dissemination, or reproduction of this message and attachments is strictly 
prohibited and may be unlawful. If you are not the intended recipient, please 
contact the sender by return e-mail and delete this message from your system 
immediately hereafter.

_______________________________________________
OPSAWG mailing list
 <mailto:OPSAWG@ietf.org> OPSAWG@ietf.org
 <https://www.ietf.org/mailman/listinfo/opsawg> 
https://www.ietf.org/mailman/listinfo/opsawg

 

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to