Open juanis2112 opened 5 months ago
Are there cases where the vulnerability does not deserve a CVE (i.e., issuing a CVE would be overkill and cause unnecessary panic from management)? If so, what are the guidelines?
For severe cases, do we privately disclose the vulnerability to affected downstream first to give them a chance to patch things before we issue a public CVE? If so, how do we identify them (opt-in? opt-out? auto bot?) and what are the guidelines?
... issuing a CVE would be overkill and cause unnecessary panic from management ...
I would disagree with that specific part. Security needs to become part of our workflow and we need to keep raising awareness on the matter. I am actually happy if management etc. gets panicked about security. It could help us steer security related topics.
I am actually happy if management etc. gets panicked about security.
I think this is a double-edged sword. In OSS, the reaction could also be, "Oh no, look at how insecure this package X is, let's roll our own in a private repo."
As someone working in a very regulated environment, this is actually something we want to see 😅 Companies who know what a CVE is, know the ins and outs of what this means.
Companies who know what a CVE is, know the ins and outs of what this means.
Is this true for academic overloards and agencies? If not, this may more hurtful for the more domain specific libraries. (I don't know the answer, this really just thinking out load and stirring the pot)
This is a question for you 😉 I can only speak for the business side (that I know of)
Maybe @eteq can share his experience dealing with a more academic domain, if he doesn't mind. We went through this recently.
We are doing some work at the summit on security best practices and vulnerability disclosure came up. So we'll add it as SPEC 11. Here's the scope for the spec:
What to do when you get a vulnerability report?
This is the draft: https://hackmd.io/dZiPH2UDRXWtPg_-1af2Iw