CSAF Version 2.0 draft feedback

[Christian Keil <keil@dfn-cert.de>]

Dear CSAF TC,

thank you for the Version 2.0 draft and invitation for comments.

We are the CERT of the DFN, the German NREN, and in that function provide
advisory services for our academic constituency, collecting, translating and
augmenting advisories from various vendors and OS distributions. As part of
that service, we already ingest CVRF advisories from multiple sources.

A couple remarks on the Version 2.0 draft:

Status

  The invitation for public comments on the website 

https://docs.oasis-open.org/csaf/csaf/v2.0/csd01/csaf-v2.0-csd01.html

directs to the TC page for OpenC2
(https://www.oasis-open.org/committees/openc2/)

3.1.3.3 Full Product Name Type - Product Identification Helper

  We welcome the addition of new ways to identify products besides CPE. Two
issues we face in this regard is renaming or selling products and patching of
software packages by Linux distributions. Both probably out of scope for
CSAF, but they might be relevant context.
  If a vendor decides to rename a product or sell it to another company, it
becomes difficult for an advisory consumer to determine, whether an advisory
is relevant or not. Things like "previous name / vendor" or "alternative
name" might be helpful in this regard.
  Determining whether an installed package from a Linux distribution is
vulnerable based on identifiers using version numbers is difficult if the
distribution has not yet published its own advisory. With distributions
backporting patches and therefore deviating from upstream version numbers, it
is not possible to derive this information from an upstream advisory.

3.1.5 Notes Type

  Similar to CVRF, Version 2.0 defines 7 note types and gives a summary
sentence each on what information is supposed to go into the different note
types. Our experience with CVRF advisories is that this is not sufficient
guideline for advisory writers. For a vulnerability description for example
we regularly check note types description, details, and summary. While the
standard indicates that these contain different levels of information, we
don't see this reflected in actual CVRF advisories.

3.1.11.2 Version Type - Semantic versioning

  The idea of semantic versioning, especially denoting a need to rematch by
increasing the major version is interesting. We are interested to see how
successful this is, regarding the limited success of semantic versioning in
the software world. A strict reading of rule 7 suggests, that the major
version must be increased, if a rematch is necessary. But it doesn't require
that it is only increased if a rematch is necessary. To our reading it would
conform to the rules if the major version is increased for a mere typo. While
an unnecessary rematch is better than a missed rematch, wich is ruled out by
7, this is similar to the situation in the software world where major
versions are sometimes handled quite liberally.

3.2.3.8 Vulnerabilities Property - Product Status

  We expect that for some product versions companies might be inclined to not
further investigate whether they are vulnerable or not. End of life products
or ancient versions come to mind. With the defined status values this cannot
be expressed. It might be present implicitly by not stating anything about
the respective product versions.


Best regards,

	Christian

-- 
Dr.-Ing. Christian Keil                             (Principal Researcher)
Phone:+49 40 808077-648    Fax:+49 40 808077-556    Mail: keil@dfn-cert.de

DFN-CERT Services GmbH, https://www.dfn-cert.de/,   Fax: +49 40 808077-556
Sitz / Register: Hamburg, AG Hamburg, HRB 88805,  Ust-IdNr.:  DE 232129737
Nagelsweg 41, 20097 Hamburg, Germany. CEO: Dr. Klaus-Peter Kossakowski

Attachment: smime.p7s
Description: S/MIME cryptographic signature