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]> 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
