Hi Eliot,
A well-known URI is just one way of enabling delivery of an SBOM.
Because of this, I think suppliers will need to include the CSAF location
in the SBOM itself.
I also think this is one of those things that crosses a logical boundary
that is no longer about discovering and accessing an SBOM.
Regards,
Pat
On Tue, May 25, 2021 at 11:01 PM Eliot Lear <l...@lear.ch> wrote:
> Hi,
> For those of you who don’t know, Common Security Advisory Format (CSAF) is
> an evolution on Common Vulnerability Reporting Framework. Such an object
> could easily be delivered with an SBOM. It has a slightly different
> characteristic in terms of update frequency. CSAF changes may happen
> independently of software updates, and generally would *not* be hosted on
> individual devices (at least, I don’t see the use case).
>
> CSAF files indicate what products and versions are vulnerable (and what
> are not), and what if any remediations are available, not unlike a classic
> PSIRT advisory.
>
> My proposal is to add into the draft an optional URL that indicates the
> CSAF object for This device, a’la:
>
> container sbom {
> …
> leaf csaf-location {
> type inet:uri;
> description “Location of CSAF file”;
> }
>
>
> I would add some descriptive text similar to the above in as well.
>
> Does this raise any concerns?
>
> Eliot
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
