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 <l...@lear.ch> 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 <l...@lear.ch> 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
