RFD: Support CNAs reporting affected artifacts

[alilleybrinker]

This RFD introduces support for CNAs to report artifacts affected by a vulnerability by introducing a new "affectedArtifacts" field to the "cnaPublishedContainer". This new field is an array of objects, with each object identifying a single artifact, potentially with multiple identifiers per-artifact.

---

This is a replacement for the previous OmniBOR portion of #407 (which originally covered both Package URLs and OmniBOR Artifact IDs, before being narrowed to solely focus on Package URLs).

---

The potential implementation can be seen in #441.

---

Rendered

[david-waltermire]

We may want to consider supporting an array of synonyms.

Here are two variant examples:

{
"affectedArtifacts": [
    {
        "artifacts": {
            "omnibor": "gitoid:blob:sha256:9f64df92367881be21e23567a31a8ce01994d98b69d28917b5c132ce32a8e6c8",
            "sha256": "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"
        },
        "status": "affected",
        "version": "0.18.1",
        "versionType": "semver",
        "platforms": ["macOS", "x86"]
    },
    {
        "artifacts": [
            {
                "type": "omnibor",
                "value": "gitoid:blob:sha256:4043df92367881be21e23567a31a8ce01994d98b69d28917b5c132ce32a8e6c8"
            },
            {
                "type": "sha256",
                "value": "40414dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"
            }
        ],
        "status": "affected",
        "version": "0.18.1",
        "versionType": "semver",
        "platforms": ["Windows", "x86"]
    }
]
}

The value of such an approach is twofold:

1. It makes it easy to enforce a rule that at least one artifact type must be provided.
2. It opens the door to add other descriptive properties down the road for each artifact type, making the model more extensible. This is supported by the second variant.

I think both of these reasons outweigh the extra verbosity.

[alilleybrinker]

Thanks @david-waltermire! A few thoughts:

• I think any field for specifying synonymous identifiers should be called "identifiers" rather than "artifacts" since all identifiers should be identifying the same artifact.
• I think we should use distinct fields for different identifier types. Not all identifiers will be expressible with a single "value" field, so I think the "type"/"value" approach would be a bit awkward.
• For OmniBOR specifically, the identifier is called an OmniBOR Artifact ID, with OmniBOR as the name for the overall specification which includes the Input Manifests, so using the name "omnibor" for the field would not be accurate.

[alilleybrinker]

I'll also note that during today's QWG meeting a couple of folks raised the idea of using a "versions" field instead of the "version" field shown in this proposal, to more compactly support cases where the same artifact is associated with multiple versions. I'm open to that, and will update the RFD to reflect that design.

[darakian]

I don't think I expressed my thoughts on the version field well in the QWG meeting yesterday so let me try again in text. First just so we have a hard example to poke and prod at, I've published version 0.1.4 of this crate
https://crates.io/crates/discombobulate/versions
which has no code changes from 0.1.3. Crates did require me to change the toml file before upload so, maybe there are ecosystems where we can be assured that there's a bit level diff between all named versions. I guess that depends on what exactly we're hashing, but this isn't really the thread I want to pull on.
Diff commit is here darakian/discombobulate@273572e as well

I think it may make more sense to not have the version field at all and I'll try to make that case.

The case for omitting version information from an affected artifact list (at least for now)

A few assumptions

1. All else equal fewer properties in the schema is better
2. A single CVE describes a single problem (perhaps in many things)
3. Coarse grained version information already exists in a CVE record

Assumption 1 leads me to a stance of "if there's no clear use case for something then cut it". The rational is that fewer properties make for simpler parser design and lower cognitive load for the humans dealing with the records. Given the presence of version information elsewhere in the record it seems duplicative to have it here as well especially in the face of the dumb edge cases as demonstrated above with my package.

Next I consider how I might use this data and the only use cases I can think of are when the coarse grained version info has failed me. Eg. If I'm reading some CVE and it lays out that the ranges [1.2.3, 2.3.4), [3.4.5, 4.5.6), etc... are vulnerable for whichever product then I would first attempt to check if the versions I use intersect with that list. Perhaps its a failure of my imagination (please call that out if so), but I think I would only be looking for hash based / intrinsic identifiers in the event that the version information has failed me and in that case I don't really care if the hash abc123... matches against version 1.2.4 or 3.4.6 or whatever. I simply care that its in the affected set. Or if its called out as explicitly unaffected.

I can see potential value for an alternate workflow where someone may be doing deeper analysis and want to track a flaw back from some blob they find on disk back to a source, however the discussion yesterday was going toward duplicating much or all of the current version block. I'm not sure it's worth it and I'd like to suggest that in the interest of simplicity that we consider dropping it, observing how people use the field in the wild and reconsider for a 5.3.0 if we feel there's a need. Same for platforms.

My $0.02

Other comments

We should create a list of valid identifiers and link out to their definitions least we end up with more chaos in the records in practice. I guess that list is omnibor and sha256 right now.

I think any field for specifying synonymous identifiers should be called "identifiers" rather than "artifacts" since all identifiers should be identifying the same artifact.

100% agree.

[alilleybrinker]

Thanks @darakian! Regarding removing version/versionType/platforms, I generally agree. My original proposal for the prior design around OmniBOR didn't permit their equivalent fields in affected array objects when the omniborArtifactID was specified.

I'd added them in for this proposal based on feedback from @ElectricNroff (see #427). I assume he would advocate for their inclusion here as well.

In this context, they'd semantically be providing information about the artifact but not constraining applicability the way they do when used in the affected array, so that's a difference worth noting.