+1 I think it's cleaner to leave security advisories out of scope for this.
Thanks, Dick Brooks <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: OPSAWG <[email protected]> On Behalf Of Patrick Dwyer Sent: Wednesday, May 26, 2021 6:12 PM To: Eliot Lear <[email protected]> Cc: [email protected] Subject: Re: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access Just to be clear. I'm on the fence. SBOMs and security advisory information, although delivered separately, go hand in hand. I think this draft is pretty close to done. Adding security advisories to it, in my opinion, would require changes to the introduction and security considerations sections. I think it's cleaner to leave security advisories out of scope for this. Deferring to the WG sounds like a reasonable idea. Thanks Eliot On Thu, May 27, 2021 at 1:20 AM Eliot Lear <[email protected] <mailto:[email protected]> > wrote: I don't mind. If it helps I can relabel some of the containers to generalize. Also keep in mind, the extension does not REQUIRE any elements in the MUD file. But I think the WG should make a call on this. If it is a bit far aways from the SBOM, we could write another draft. On 26.05.21 13:46, Patrick Dwyer wrote: I agree with all of that. Perhaps not on whether it belongs here though. This draft, so far, is completely focused on SBOMs. Not on vulnerability information or advisories. Perhaps it would be better served as a separate MUD extension and well-known URI? On Wed, May 26, 2021 at 4:39 PM Eliot Lear <[email protected] <mailto:[email protected]> > wrote: Hi Patrick, Snipping to the meat: On 26.05.21 05:08, Patrick Dwyer wrote: True, although I wouldn't expect a CSAF reference in isolation in this case. I think different manufacturers will hold different points of view on this. Some may simply be required to release an SBOM based on some regulatory requirement. Some not, and some may wish to release an SBOM without using this mechanism. > I also think this is one of those things that crosses a logical > boundary that is no longer about discovering and accessing an SBOM. That is true. But not a huge stretch. It's not a huge stretch. But this is also tied to a particular format for this type of information. Personally I think CSAF is the format to use. But that might not be the case in some particular industries and countries. Yes. I myself am hemming and hawing on this point a bit... Let's just delve into that a bit more: On the one hand, we have one really good candidate, CSAF. On the other hand, one might want to refer to the Old (more deployed) Stuff, which does almost as good a job, CVRF. On the third hand, it is possible that this information could be included directly in a schema like CycloneDX, either directly or as an extension. On the fourth hand, the information could be included as a reference by the underlying SBOM format, as you mentioned earlier. So what are the principles here? I think they are these: 1. If the information exists outside the context of an SBOM, it should be made known. 2. Don't make the end device do work. Leave that to the network management. 3. When there's one really overwhelmingly good candidate, use it and don't overcomplicate the network management. 4. Provide some flexibility for the idea that these formats may change. 5. Don't duplicate information elements. Some of these principles conflict. Here's what I suggest: 1. If the information is included in the SBOM there is no need for a MUD file to include the new element. 2. If the information is NOT included in the SBOM, or the SBOM isn't available, there is a need to provide the new element. 3. Let's change the name of the element from "csaf-location" to "vulnerability-info", and make use of the same mechanism we used for SBOMs to decide, with a suggestion that CSAF be the preferred initial format for consumers. This splits the baby a bit, but perhaps covers your concern? Also note that with CSAF I am taking a certain liberty to constrain the CSAF reference in this case to contain a single product, so that we don't get into a naming fiasco. Naming. I hate naming. Eliot
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
