Eliot, REA has open-sourced a Vendor Response File XML format that addresses SBOM access, using a URL, along with other required data needed for a comprehensive NIST software supply chain risk assessment (C-SCRM), i.e. Known Vulnerabilities disclosure: https://github.com/rjb4standards/REA-Products
Schema file: https://github.com/rjb4standards/REA-Products/raw/master/SAGVendorSchema.xsd Example Vendor Response File: https://github.com/rjb4standards/REA-Products/raw/master/SAG-PM-VendorResponseExample.xml Known Vulnerabilities Declaration: https://github.com/rjb4standards/REA-Products/blob/master/KnownVulnDisclosure.docx?raw=true A software vendor makes the Vendor Response file available to customers via an access controlled customer portal. The materials contained in the response file are sufficient for software vendors to meet the upcoming "SBOM law" that's working its way through Congress, H.R. 4611; https://www.congress.gov/bill/117th-congress/house-bill/4611 Thanks, Dick Brooks Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: d...@reliableenergyanalytics.com Tel: +1 978-696-1788 -----Original Message----- From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of Eliot Lear Sent: Friday, October 22, 2021 8:30 AM To: Ebben Aries <e...@juniper.net>; yang-doct...@ietf.org Cc: draft-ietf-opsawg-sbom-access....@ietf.org; opsawg@ietf.org Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02 Hi Ebben and thanks for your review. Please see below: On 03.10.21 01:15, Ebben Aries via Datatracker wrote: > Reviewer: Ebben Aries > Review result: Almost Ready > > Apologies for not turning this around sooner. Structure wise, the > model is fairly sound. Most of the comments below are either > nits/wording, slight adjustments and questions/clarifications. > > 1 module in this draft: > - ietf-mud-transpare...@2021-07-06.yang > > No YANG compiler errors or warnings (pyang 2.5.0, yanglint 2.0.88, > confdc 7.2.3.4) > - L#364: CODE BEGINS : filename must be defined on same line for tools such as > rfcstrip to correctly parse the module contents > > Module ietf-mud-transpare...@2021-07-06.yang: > - import `ietf-inet-types` should reference RFC 6991 per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4. > 7 Corrected. > - import `ietf-mud` should reference RFC 8520 per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4. > 7 Corrected. > - L#016 - Minor nit: looks like L#17 should be moved up here Corrected. > - L#018-020 - Minor nit: adjust email address formatting per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C Corrected. > - The type and enum members are identically defined for > `sbom-local-well-known` and `vuln-local-well-known`. Is this something you > can leverage by using a typedef or a grouping or is there intention to keep > these separately defined? I think we are removing vuln-local-well-known. > - When retrieving say an 'sbom' from the device, is it assumed that it be via > `sbom-local-well-known`? What if it is necessary to host this on an > alternate port for one of the communication protocols chosen? Would this > scenario then best use `sbom-url` to define a static URI? (Same question > applies to vuln as well) We truly hadn't considered this aspect, but I think you would be right: best to use sbom-url. Alternatively we could add an optional port parameter. > - Independent of the answer to the above question, is `cloud` the best choice > or wording for the other case statement under the retrieval method choices? Pick something better? > > It seems to be that we have 3 cases for sbom/vuln retrieval methods which > correspond to the draft wording at L#176-180 which seems to not pair > identically. > > * on devices themselves: Could be /.well-known/ or a static URI could it > not? .well-known. The issue is this: management systems may well query .well-known without ever referring to this model. > * on a website: Static URI only Correct. > * out-of-band: Static URI only - should this leaf be named something closer > to that vs. 'contact'? I think contact covers this appropriately. > > General comments on the draft/modules: > - L#0021: s/provide access this/provide access to this/ Corrected. > - L#0117: s/bills of material/bill of materials/ Both need an s. > - L#0627: JSON example needs correct prefix for the augment > `ietf-mud-transparency:transparency` Will correct in the tooling that generated this. > - L#0941: s/not be/not been/ Corrected. > - L#0961: s/authoration/authorization/ Corrected. > - Since `ietf-mud-transparency` imports `ietf-inet-types`, a normative > reference must be added per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3. > 9 Done And thanks! Eliot _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
