Re: [csaf] CSAF presentation & Where to find CSAF documents

[Martin Prpic <mprpic@redhat.com>]

Schmidt, Thomas writes:

> Hi @all,
> I wish you a happy and healthy New Year!
>
> Please find attached the presentation which I would like to give at our next call on Wednesday to be able to review it beforehand. You will find
> - a general introduction: p. 2-5
> - different maturity stages in regards to security advisories: p. 6-7
> - conformance targets at document level: p. 8 (see also https://github.com/oasis-tcs/csaf/issues/140)
> - a suggestion how issuers of advisories should provide them: p. 9-10 (see also https://github.com/oasis-tcs/csaf/issues/152)
> - why aggregators are needed: p. 11-15 (see also https://github.com/oasis-tcs/csaf/issues/152)
> - what I suggest to NOT solve in CSAF 2.0 but push to a later version: p. 16
>

Hi Thomas,

Having thought about your presentation a bit, I have a couple of
comments/questions:

I find the number of proposed requirements that a CSAF provider has to meet
a bit high. At least in the open source world, CSAF definitely struggles
with adoption so rating different vendors by their adherence to the
proposed criteria to be able to be presented in some central aggregator as
"trusted" seems a bit skewed towards vendors who can devote a lot of
resources to their CSAF infrastructure. I also doubt many vendors will be
happy to restructure their website to serve their CSAF content at a
required location (especially if you expect it to work for any domain and
subdomain of a vendor).

I generally like the idea of a central aggregator of CSAF documents, but in
my opinion it should be community maintained. If I as a vendor want to
participate in this aggregator, I should be able to provide a pointer to
the location of all my CSAF documents and that's it. It might be easiest to
start a csaf-manifest Git repo that may contain structured YAML files (or
w/e machine readable markup) per vendor.

I think instead of focusing on added requirements in adopting CSAF, the
community should make the standard more approachable to new vendors
and projects.

Also, slide 16 mentions "Integration of SBOM", what exactly does that mean?
How is an SBOM related to the content of advisories? Is the intention for
CSAF documents to include entire SBOMs of artifacts that they provide
updates for?

Thanks again for the presentation!

-- 
Martin PrpiÄ / Red Hat Product Security