Although we enhanced the content model a lot (looking back to version 1.2) there is still this itch I really want to scratch at:

For CSAF like with other formats (eg. SARIF) the minimal valid document is ... an absolutely useless one.

What is an advisory not containing at least wun object and wun relation to a vulnerability? Seriously:

What would our parents and children think of us if they knew what we are doing here: Standardizing per hundred(s) pages rules for advisories, that allow those advisories to contain and provide essentially ... nothing?

So, over the next days and weeks, I will propose an augmented baseline for being a valid CSAF document and I invite all members, esp. from organizations actually producing or consuming security advisories in production, to support me in that final attempt of defining such a minimal document content that is worth being called a minimal viable product (MVP).

Currently, what we minimally allow is not an MVP, or is it?

Trying to identify such additional mandatory elements, I find it encouraging, that important use cases for issuing and processing a security advisory can be those, where not much is actually known. Essentially a heads up, important nevertheless. Typically not for every product it is known from news of a vulnerability discovery, if this product is affected by that vulnerability and if so, what measures can be advised. But, we can issue advisories of value to consumers, informing the product users, that there are known unknowns. Like, not yet knowing if that product is affected by this vulnerability or not in an initial version of the advisory.

In my world being actionable is the most important attribute of anything claiming to be advice.

This should be doable for CSAF. Valid advice for me includes (in version 1):

That 👉🏽 plant 🌱 may be infected with mites 🦠 we are investigating ...

Then version 2 issued after inspection:

That 👉🏽 plant 🌱 is infected with mites 🦠 working on mitigations ...

... and so on, simple like that (maybe neither for the plant nor the mites though).

Basically, I think that

if creating the next level above a meta data only CSAF document is high in the sky, then there is something wrong with the format or model

In that case, we should IMO consider why and if this is good. My feeling is, that if one needs to fill many more fields to go from zero to wun this is wrong and may hamper adoption.

So, if this is the case, we should correct that and provide with version 2.0 (which already signals per semantic versioning breaking changes).

Am I pathetic 👴🏽 or does that make sense? I sincerely hope the latter and

... am possibly sorry for the Saturday Morning version of the pwnd international english language used to create this call to action. — Caveat emptor: I borrowed the term wun (meaning 1) from Douglas Crockford without asking for permission and hope for forgiveness.

@tschmidtb51 very helpful. Looking forward to the PR, as merging this before I inject the conformance targets and their anchors/hooks because then the members can more easily separate formal changes (ordering) from content changes (conformance targets on roles).

During the process, we mixed up the order of the properties in the JSON schema. I suggest to rearrange them in alphabethical order. The JSON key words will still be in the order of https://github.com/oasis-tcs/csaf/issues/110#issuecomment-689148217.

    _$comment (to be removed before publication)_
    title
    description
    type / $ref
    default
    enum
    format
    pattern
    maxLength
    minLength
    maxItems
    minItems
    maxProperties
    minProperties
    required
    uniqueItems
    properties
    items
    examples

Hi @adulau, one reference implementation would be any jsonschema parser that can parse the jsonschema version we use (currently draft 7). But, this validates of course mainly the shape (overall and per values). I am considering to provide a candidate for a more considerate parser module to the TC and the wider community, that adds constraints not enforceable per JSON schema. And this I assume will not be the only one.

The TC members will be more than happy to support interfacing with e.g. MISP and other community projects. We will update this issue to communicate available tools.

Hope this helps and thank you very much for the inquiry, much appreciated.

Is there any reference implementation of CSAF? Such as a Python library or alike? Thank you very much

Thanks for clarifying how we could leverage the existing structure-- I think that's an acceptable resolution to what I was suggesting, once hashes can be included.

@mprpic and @santosomar _ please see my assessment in the linked issue. This is a small scope and suggest we merge and include in the next revision of the draft explicitly listing the fix. Will merge this PR tomorrow 1700 UTC if no one objects until then. Thanks.

I consider this a consistency bug and merely editorial to fix. Will request accordingly in corresponding PR

• resolves #189
• add "uniqueItems" to the definition
• change prose to reflect schema

Currently, it is allowed to have the same product_id twice in the list of product_ids in one product group element. See example below:

"product_groups": [
      {
        "group_id": "CSAFGID-0001",
        "product_ids": [
          "CSAFPID-0001",
          "CSAFPID-0001"
        ]
      }

However, this violates the rule CSAF-5.1.4.1.2-1. Therefore, I suggest to add an "uniqueItems": true.