Can someone give a practical example of a vulnerability and an indicator for that vulnerability (actual STIX JSON)? It would be beneficial to have this in the spec (or an associated implementation guidance document), and would help me understand to make sure we aren't introducing multiple ways of doing something.

I recognize that sometimes "shortcut" relationships are necessary, rather than the more pedantic but accurate ones, but want to make sure we take that into account (my standard example from STIX 1/CybOX 2 is that malware doesn't really connect to a Domain name, but you connect to whatever IP address that domain happens to resolve to).

I am on mobile right now so hard to craft the JSON, but this is pretty trivial to come up with examples for. I can write an SCO pattern to indicate almost any vulnerability by looking for registry keys that enumerate software versions. This is just one example. Another would be to look for certain User-Agent headers in HTTP, banners on connections, etc etc. These are how most OVAL tests work.

Now, it is interesting question on if we EVER want to be getting into this at all. Everyone already uses OVAL for this. Vulnerability scanner vendors are not going to switch to SCO pattern to look for vulnerabilities. So perhaps instead of this request we should be looking at how to use OVAL in STIX.

Oh, thanks @JasonKeirstead. I didn't even think of vulnerability scanning, which I would argue is outside the scope of CTI; as you said, OVAL is already commonly used for this, and the vulnerability object exists only for linkages to Malware, Threat Actor, etc:

Typically, other SDOs assert relationships to Vulnerability objects when a specific vulnerability is targeted and exploited as part of malicious cyber activity.

Furthermore, Indicators are described as containing:

a pattern that can be used to detect suspicious or malicious cyber activity

and I would argue that indicating a vulnerability does not fall into that. If we want to add this relationship, I feel we need to revise the definition for the use of these two objects in STIX. I don't think such a revision is a good idea, as it represents unnecessary scope creep.

After discussions on the working calls and email list, the TC decided not to make this change for 2.1. The decision can be revisited in the future.