Michael, The predominant "SBOM delivery channel" I see is through access controlled customer portals where customers can download SBOM's Vulnerability Disclosures and other artifacts needed to perform a NIST C-SCRM risk assessment for Executive Order 14028. Here's a use case to consider, listing all of the evidence data needed: https://github.com/rjb4standards/REA-Products/blob/master/UseCaseVDR117/READ ME.md
Thanks, Dick Brooks Never trust software, always verify and report! T http://www.reliableenergyanalytics.com Email: [email protected] Tel: +1 978-696-1788 -----Original Message----- From: OPSAWG <[email protected]> On Behalf Of Michael Richardson Sent: Friday, February 4, 2022 12:40 PM To: [email protected] Cc: [email protected] Subject: [OPSAWG] SBOMs and version non-specific MUD files ietf-opsawg-sbom-access provides for linking to an SBOM from a MUD file. My understanding is that for the sbom-retrival-method==cloud, that a list of sboms is included, one per version of the device firmware. I just wanted to re-iterate that this really is a good thing, because it allows for a version agnostic MUD file to list many things. I would like a cloud example to be added. I think that we need some RFC6125 text for the https: local-well-known text to explain how validation is (not) done. We still need some way to determine what version of firmware a device is running, and while the correct answer is remote attestation, it would be lovely if there was a recommendation for a lighter weight process. LLDP regularly reveals this, but that's unlikely to work over wifi or in residential situations. (I acknowledge that this is out of scope for sbom-access) -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
