3 ms·

> noone should ever be able to file a CVE without the product owner having a say in this. That's a really stupid idea. CVEs track security vulnerabilities, not

> noone should ever be able to file a CVE without the product owner having a say in this. That's a really stupid idea. CVEs track security vulnerabilities, not 'security vulnerabilities the product owner is prepared to admit to'. Imagine if Cisco decided they were going to be the CNA for Cisco devices just weren't going to issue any CVEs for any vulnerabilities in any Cisco devices, regardless of whether they're exploited or not.

em-bee 3y ago
i am not saying that the product owner should be able to veto without being overridden, just that they should have a right to be heard, and that their response needs to be considered. i do realize that many businesses would rather hide any security issues instead of acknowledging them. so a simple "no" or no response from them would not be enough. but the current situation where we get a CVE for anything that is not proven to be safe (when giving that proof is very expensive to make) is also not helpful. the linux kernel and curl becoming their own CVE authority is a hack to work around a broken process.
- eviks 3y ago
  Who would be able to override the product owner? If it's the party that files, then what changed?
  - em-bee 3y ago
    maybe a number of independent reviewers. kind of like we have reviewers for scientific papers, except i would make the list of reviewers known and attached to the CVE like signoffs on patches, including reviewers that reject the claims. (actually, that should be done for papers as well, but that's a different discussion) then you can evaluate the seriousness of any CVE not only by its assigned threat level but also by weighing who and how many people reviewed the claims. further there could be review levels, also similar to how bug reports are handled: new/incoming, triage, verified/reproduced, closed/unreproducible, fixed. that would allow further categorization and give people another way to evaluate if a CVE is serious.
  - marcus0x62 3y ago
    Within the existing system, I think MITRE should be able to override a CNA, but I don’t know that they can, just that they don’t appear to do so.
patmorgan23 3y ago
There are "security researchers" who grep GitHub for the words 'password' or 'secret' and blindly file CVE's if they find any hits.
- stonogo 3y ago
  and those CVEs are rejected or revoked. There are bad actors everywhere; they're not a good excuse to stop trying.
  - deleted 3y ago
    [deleted]
  - worthless-trash 3y ago
    There are -many- software vendors and developers that wont accept or even respond to security researchers. You are absolutely correct.
lifthrasiir 3y ago
It's indeed stupid in general, but many big F/OSS projects suffer too much from this issue that they really want to do this. A possible resolution would be to have two kinds of CVE numbers: researchers can request and get assigned provisional CVE numbers that don't look like the current CVE numbers (e.g. pCVE-2021-3PF5), and the current CVE number format would be used for verified CVE numbers where the vendor(s) have confirmed them (e.g. CVE-2021-22204). Note that my example assumes that they still share the same identifier space: a conversion from "3PF5" to "22204" should be mechanical [1]. So researchers can still use pCVE numbers as needed, but proper CVE numbers would require vendor's cooperation. That sounds a reasonable trade-off for the security purpose. [1] I've specifically used bijective vigesimal numbers with digits from Open Location Code in this example. So 1..20 = 2..X, 21..420 = 22..XX, 421..8420 = 222..XXX and so on. I've specifically picked OLC because it avoids many profanity possibilities, but an ideal scheme would also avoid all-number identifiers to clearly distinguish it from normal CVE numbers.
- fweimer 3y ago
  We tried that already, there used to be candidate CAN-* identifiers. Review to promote them to CVE-* identifiers was always a bottleneck.
  - lifthrasiir 3y ago
    That's a fair argument. But candidate numbers were abandandoned long before the current problem, back when there were only ~5000 CVE numbers assigned per year (vs. 52000+ for 2023). And more crucially, this review was done by the CVE Editorial Board, which is a small group of people who could vote for/against making it the "entry" status. That is clearly not scalable and I'm not proposing that. In fact, I believe there doesn't even need an actual vendor intervention to be "confirmed" in my scheme---the researcher should be able to attach a vendor response as an evidence in principle. (Of course such response can be forged, so there would have to be a proper process to counteract that.)
- PeterisP 3y ago
  I strongly disagree, whatever process we have should work also for 'hostile' vendors and allow for "the community" to verify and assert vulnerabilities even if the vendor denies them, attempts to take legal action, etc. There are all kinds of options, perhaps national CERTs could override vendor decisions, perhaps something else, but we can't simply assume good-faith behavior from every vendor. The whole reason why we have various community resources for tracking vulnerabilities was that relying on vendor behavior didn't (and doesn't) work, and it's up to the general public to figure out how force appropriate behavior with e.g. responsible disclosure deadlines, public shaming, etc; and CVEs are part of that mechanism of the community pushing reasonable standards on vendors whether they want it or not - since many vendors often have a clear financial motivation to act against user's interests, downplay and ignore vulnerabilities, and CVEs are for the benefit of system users, not vendors, they are how security researchers can communicate risks to the system users, with or without cooperation from the vendor.

em-bee 3y ago

i am not saying that the product owner should be able to veto without being overridden, just that they should have a right to be heard, and that their response needs to be considered. i do realize that many businesses would rather hide any security issues instead of acknowledging them. so a simple "no" or no response from them would not be enough. but the current situation where we get a CVE for anything that is not proven to be safe (when giving that proof is very expensive to make) is also not helpful. the linux kernel and curl becoming their own CVE authority is a hack to work around a broken process.

eviks 3y ago
Who would be able to override the product owner? If it's the party that files, then what changed?
- em-bee 3y ago
  maybe a number of independent reviewers. kind of like we have reviewers for scientific papers, except i would make the list of reviewers known and attached to the CVE like signoffs on patches, including reviewers that reject the claims. (actually, that should be done for papers as well, but that's a different discussion) then you can evaluate the seriousness of any CVE not only by its assigned threat level but also by weighing who and how many people reviewed the claims. further there could be review levels, also similar to how bug reports are handled: new/incoming, triage, verified/reproduced, closed/unreproducible, fixed. that would allow further categorization and give people another way to evaluate if a CVE is serious.
- marcus0x62 3y ago
  Within the existing system, I think MITRE should be able to override a CNA, but I don’t know that they can, just that they don’t appear to do so.

patmorgan23 3y ago

There are "security researchers" who grep GitHub for the words 'password' or 'secret' and blindly file CVE's if they find any hits.

stonogo 3y ago
and those CVEs are rejected or revoked. There are bad actors everywhere; they're not a good excuse to stop trying.
- deleted 3y ago
  [deleted]
- worthless-trash 3y ago
  There are -many- software vendors and developers that wont accept or even respond to security researchers. You are absolutely correct.

lifthrasiir 3y ago

It's indeed stupid in general, but many big F/OSS projects suffer too much from this issue that they really want to do this. A possible resolution would be to have two kinds of CVE numbers: researchers can request and get assigned provisional CVE numbers that don't look like the current CVE numbers (e.g. pCVE-2021-3PF5), and the current CVE number format would be used for verified CVE numbers where the vendor(s) have confirmed them (e.g. CVE-2021-22204). Note that my example assumes that they still share the same identifier space: a conversion from "3PF5" to "22204" should be mechanical [1]. So researchers can still use pCVE numbers as needed, but proper CVE numbers would require vendor's cooperation. That sounds a reasonable trade-off for the security purpose. [1] I've specifically used bijective vigesimal numbers with digits from Open Location Code in this example. So 1..20 = 2..X, 21..420 = 22..XX, 421..8420 = 222..XXX and so on. I've specifically picked OLC because it avoids many profanity possibilities, but an ideal scheme would also avoid all-number identifiers to clearly distinguish it from normal CVE numbers.

fweimer 3y ago
We tried that already, there used to be candidate CAN-* identifiers. Review to promote them to CVE-* identifiers was always a bottleneck.
- lifthrasiir 3y ago
  That's a fair argument. But candidate numbers were abandandoned long before the current problem, back when there were only ~5000 CVE numbers assigned per year (vs. 52000+ for 2023). And more crucially, this review was done by the CVE Editorial Board, which is a small group of people who could vote for/against making it the "entry" status. That is clearly not scalable and I'm not proposing that. In fact, I believe there doesn't even need an actual vendor intervention to be "confirmed" in my scheme---the researcher should be able to attach a vendor response as an evidence in principle. (Of course such response can be forged, so there would have to be a proper process to counteract that.)
PeterisP 3y ago
I strongly disagree, whatever process we have should work also for 'hostile' vendors and allow for "the community" to verify and assert vulnerabilities even if the vendor denies them, attempts to take legal action, etc. There are all kinds of options, perhaps national CERTs could override vendor decisions, perhaps something else, but we can't simply assume good-faith behavior from every vendor. The whole reason why we have various community resources for tracking vulnerabilities was that relying on vendor behavior didn't (and doesn't) work, and it's up to the general public to figure out how force appropriate behavior with e.g. responsible disclosure deadlines, public shaming, etc; and CVEs are part of that mechanism of the community pushing reasonable standards on vendors whether they want it or not - since many vendors often have a clear financial motivation to act against user's interests, downplay and ignore vulnerabilities, and CVEs are for the benefit of system users, not vendors, they are how security researchers can communicate risks to the system users, with or without cooperation from the vendor.