Consider a "Deployment Saturation" decision point

[ahouseholder]

Is your feature request related to a problem? Please describe.

Patch deployment is rarely a one-shot event in a network of any significant size. "Percentage of Systems Patched" is a key metric in many vulnerability management practices. SSVC does not have any mechanism to represent this. Having a decision point to capture this could help organizations who are re-evaluating prioritization decisions at a faster pace than their patch deployment process. This could help folks build more responsive vulnerability management processes driven by live deployment data.

A vulnerability that would otherwise be very concerning might be lowered in priority if the deployment of the patch is mostly complete compared to one where no patches have yet been deployed.

Describe the solution you'd like

Add a decision point that reflects "Deployment Saturation" (placeholder name). This could take the form of 3-5 values that are basically percentage ranges (e.g., 0-20, 20-40, 40-60, 60-80, 80-100). Not sure if a linear scale is better than alternatives (e.g., 0-10, 10-50, 50-90, 90-100) but absent any strong feedback or citations of prior art that already use a non-linear scale it's probably good enough.

Additional context

This is kind of an advanced topic and might not be useful to all SSVC users, but it could be especially useful for larger enterprises where folks are frequently reassessing their priorities while patching is an asynchronous background process elsewhere in the organization.

[j---]

I think this may be better as a meta-metric over an asset deployment than as a decision point used per-asset.
Perhaps the better way to model this would be that each asset should have its own values for certain parts of the decision tree? So for example, a high-value or value-dense asset should be patched before those assets that are not. Internet-exposed should be patched before those that are not. This creates a priority order on patch application for devices within the asset manager's purview.

If that all happens, what is the residual value of knowing that 60% of machines (presumably the more important ones) have been patched when deciding when to patch the rest of the machines?

If folks need different SLEs for critical-uptime services than for, say, end-user laptops, then I think that might be better represented by having a different tree (so a different risk posture) for the different SLEs. Again, then, this metric would be a sort of meta-metric across the SLE, rather than a decision point per se.

Am I misunderstanding the use case here?

[ahouseholder]

I don't know that this decision point would be useful in a "should you deploy now or later" decision. I think it is potentially useful for reviewing outstanding vuls/patches for prioritization later. So someone who's monitoring the vul management process at an org needs to know which vuls they're already working to deploy to push harder on, and this helps them sort that list. The decision might be something more like an "escalate? yes/no" decision at that level.

[j---]

OK. I think that makes sense.
How are we distinguishing which kinds of decisions or organizational process a decision point is recommended for? Just through examples? That might be enough, but I could imagine that getting confusing as we build out decision points that are not just for different stakeholder organization types (deployer, coordinator, etc.) but also roles within those organizations.