Replies: 1 comment 1 reply
-
|
I don't think we should lash our boat to SemVer as there are enough viable alternatives and I don't want to make it harder for folks doing continuous deployment to use SSVC. To the broader point about the meaning of Defer though, I think there are a variety of possible meanings (and we would do well to figure out which of them we intend). A few examples:
I think we had the second one in mind originally, and the reason it was Defer instead of Close is that all decisions to take no further action are reversible (by deciding to take further action). 3 is almost the same as 2, although it makes the revisiting explicit. However, it would need to be a stakeholder-specified timeframe to address their operational tempo. Perhaps even a case-specific timeframe based on environmental volatility. But that might lead to lead to the potential of a suite of deferral outcomes based on timeframes: defer-1, defer-7, defer-30, defer-90 and now you're in the ironic state of prioritizing your deprioritizations. Taking things in a slightly different (but not totally off-topic) direction, many IT problem / change management practices (think ITIL or whatever the cool kids are doing these days) have specific SLEs attached to issue severity levels. In principle, an SSVC deployer organization could choose to map our generic decision outcomes directly to their Severity levels or SLEs, for example:
I know less about how idiosyncratic (or not) real-world developer bugfix SLEs can be, but it seems plausible that there might be some existing model(s) to map to? Again, as with the deployer example above though, I think we'd have to just highlight in the doc that "when we say Defer, you should figure out how that maps onto your process, and then decide if the tree you are using is scaled appropriately to your work priority categories". |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for writing this out. SemVer can one option for how it can be represented, and SLEs can be another way of representing it. I agree we don't need to tie ourselves to just one. I think the broader point is that we currently have it defined as something like your 2 or 3. And I think it should be more like what you have as 1. |
Beta Was this translation helpful? Give feedback.
-
https://github.com/CERTCC/SSVC/blob/82363313b2f0c17308bce829753641bda77e73e3/doc/md_src_files/040_stakeholders-scope.md?plain=1#L135C7-L135C7
| Defer | Do not work on the patch at present. |I think we could give clearer guidance on suppliers actions here. Based on discussion with @thomas-proell and @bs37208.
For a supplier, there probably should be a definition of Defer about when the vulnerability will be remediated, rather than the rather over-simplified "do not work on patch at present".
What do we think about tying Supplier actions in to release types related to SemVer? As in, defer would mean "fix in the next minor version release or equivalent time line".
Then scheduled would track to fixing in the next scheduled patch release version. Naturally, out-of-cycle would mean issuing an out-of-cycle patch. I think immediate also leads to an out of cycle patch, but with different advisory and notifications around it, and probably with different resources devoted to getting it done faster. I'm not imagining a substantive change to the three levels above defer, just shifting the language to be similar to that for defer.
I think we still have to leave space for developers to define their own software release cadences, even though of course we still have the problem of stacking lots of 90-day patch release time lines in a supply chain might mean that patches don't fully propagate for years. I think we have to work that separately, though, as getting people on shorter scheduled maintenance windows -- as in, that's not in scope for SSVC to solve by itself.
Beta Was this translation helpful? Give feedback.
All reactions