Replies: 2 comments 1 reply
-
So if I'm visually diff'ing correctly, you're specifically suggesting two changes:
to
and
to
These both seem like reasonable changes to me. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Based on a discussion with @thomas-proell and @bs37208. However, I have digested their comments, so should not be taken to represent their views directly.
Observation: For suppliers, who are working on patches pre-disclosure especially, state of exploitation is very often None. Suppliers are also hesitant to assess even the paired down Public Safety impact, See https://github.com/CERTCC/SSVC/blob/main/doc/graphics/ssvc_2_supplier.pdf
This leaves Utility and Technical Impact to do most of the work of differentiating work priority for most vuls that a supplier actually processes.
We should reassess the core lines of the recommended prioritization tree with this in mind.
Namely. the odd numbered rows between 1 and 11.
SSVC/data/csvs/supplier-options.csv
Line 2 in 8236331
If this is where the majority of vulnerability reports are landing, it probably makes sense to have more variability within these 6 lines. I think it is OK to reserve immediate for situations where there is actually safety impact or active exploitation. Then a developer really should drop other things to get out a patch.
However, I think it might make sense, in light of this feedback, to reassess the outcomes to be more like:
Thoughts?
Also, opening a separate discussion for maybe "defer" for a supplier needs to mean something different than the current definition.
However, this is also tangled in supply chain complexities about who is a supplier and who is a deployer, and that many orgs are both ( (also a separate discussion).
Beta Was this translation helpful? Give feedback.
All reactions