Chainability of a vul

[j---]

@cgyarbrough :

Consider 'chain ability' of a given vulnerability. This is probably beyond the scope of {what's current in automatable}, but certain vulnerabilities might be considered more 'beachhead' category (i.e., tending to allow for ingress to a system or software) and others are more effective at lateral movement or secondary instantiation in a blended or staged exploitation attempt. DoDCAR has done some initial work on the additive nature of exploits, but each of those is composed of underlying exploitable vulnerabilities.

This would be a good topic to address when we address #78 (after v2 is set)

[ahouseholder]

Some incomplete ideas capturing notes from conversation on 2021-02-24:

• might be an expansion of technical impact (e.g., exploitation yields additional access but not "total")
• might be an expansion of exposure (e.g., exploitation increases exposure to other vuls)
• might be a new decision point, something related to fix/mitigation value (e.g., by fixing/mitigating you cut off not just this vul but others too)

[ahouseholder]

Converting to discussion. Note also that #78 referenced above has also been converted to discussion #227

[j---]

One thing that might be plausible is for deployer stakeholders, who are at least some times prioritizing patches (which patch multiple CVE IDs) rather than individual vuls, that the analyst might scope what is chainable to or from each other as all the vuls that are addressed in the patch being considered. That helps keep the problem from exploding, but still might be practically useful.