> Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore.
I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs. For instance, one time we had a security team that required us to patch a vmware support package that was installed by default on ubuntu, but the CVE required being ran on vmware when we were running on EC2. Arguing with them was pointless because they were not interested in determining if the CVE applied to us, only that it needed fixed.
Lots of teams that are supposed to be in charge of security don't ask "does this CVE affect us", but simply shift the burden of patching downward and outward. In some cases, like in the case of easy to update and centrally deploy SaaS products, that burden is more annoying and frustrating than difficult. In some cases, like when you have complicated deploy or have customer-controlled updates, those mandates cause a huge burden on teams not producing the decision to patch every low CVE.
Yes, I’ve also experienced this kind of attitude. Some scanning tools can detect that certain CVEs do not apply because the specific functionality is not used.
I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)
There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)
> I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs
This is true, but also: needless CVEs place a burden even on security teams who do take a nuanced view of CVEs - it requires some amount of effort to evaluate every CVE and determine whether it's applicable or not.
Absolutely. I was focused on the burden CVEs place on everyone downstream of teams that don't take a nuance view, but even when teams do look at all the CVEs reported in scans, the proliferation of CVEs just adds workload to determine if they are affected. Unless teams say they will not look at lows (or lower-than-lows if the category existed) then what amounts to busy-work just piles up.
The problem of CVE inflation is not just that you might be forced to patch a CVE that is not applicable to your product. Even investigating to understand whether a CVE is applicable or not takes time, and is simply not worth it for obscure issues like the one in this bug.
It would be revealing to see some of the e-mail communications this person was sending to MITRE while trying to fight this issue.
We’re all familiar with how some use LLMs to write code and submit PRs, but there’s a growing problem of people using LLMs to tirelessly fight issues with communications like e-mails and even suggesting physical paperwork too.
Now that the effort to argue something against an institution is approaching zero, more people are getting the idea to have their LLM and harness fight some battles for them. It feels like it costs them very little but if there’s a non-zero chance of personal gain they do it. I’m hearing a lot of stories about everything from local governments to university administration offices being overwhelmed by requests that just keep coming in from relentless senders who figure asking for anything is worth a try even if there’s no chance it would be granted.
I think we’re going to have to rethink a lot of our communication and request systems that previously relied on the fact that most people wouldn’t take the effort to argue for something that they didn’t deserve. When the cost of arguing approaches zero, the machine can keep trying to get the non-zero chance of success for them.
It sounds like the only end result of this is them making the bureaucracy even more bureaucratic by employing their own agents, where the only way to get anything done is to have your agents fight their agents.
Frankly, it feels like Kafka was actually an optimist.
The incentives here are really bad at the moment. Traditionally, your name on a CVE against an important project like curl have a certain cachet in the community. You might even leverage that to get a raise or a better job, so money was definitely part of this.
Now lots of people are throwing code against LLMs and then copy/pasting whatever comes out into "security" reports.
We decided for our projects that any LLM-generated security reports are simply copied to the public list. Everyone has access to LLMs so presumably if one LLM instance found it, then all users of LLMs have already or shortly will find it. We'll fix them if they're important, but the signal to noise is pretty bad.
I think this will, eventually, result in more secure services as the low hanging problems are found and fixed. But unfortunately I don't see the flood of LLM-generated nonsense ending any time soon.
Unless it's a critical CVE, they're worth very little now for your career.
Same for a lot of side projects or small contributions to OSS, people are still chasing them and wasting everyone's time for nothing. They wouldn't even work on them before AI.
In a way I think the false promise of open source that someone else would have gone through the code is actually going to come true as LLM would have gone through the code.
This kind of hellish experience is a great example of the CVE system trying to have it both ways: when on the offense it’s a rich source of information for defenders, and when on the defense it’s just an opaque ID for coordination that implies nothing about the quality or correctness of the underlying report.
First thing that came to my mind... why people are so self-centric... and yet, somehow, you feel bad because the same people flex with these CVEs while you can't tell a single huge one you had found under NDAs, while they keep downplaying or ignoring you. I think its better to treat these people as less professional, and try to influence the common reception what is actually professional and what is not.
I think all this goes to the joke/not-a-joke about "you aren't a real hacker until you have a CVE to your name". Its also a form of forced social proof.
> it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.
If it's just about that, fix those low priority issues and bundle them along with the next higher-priority fix pack, i.e. "lower than low" -> fix but not release immediately; "medium" or higher -> release with any earlier unreleased "lower than low" fixes.
Seeing how much energy you spent in dismissing the person's report on the "lower than low" vuln in https://hackerone.com/reports/3455037, it'd be easier and faster to just fix it rather than argue...
According to the linked article, that’s exactly what they did. It was a legitimate bug, but the security consequences were lower than low. It’s a code quality issue, not a security issue, but both are worth fixing.
I don't see how that correlates, and that's already pretty much what they do anyway. The reporter's issue wasn't that it didn't get fixed (it did), but that it wasn't given a CVE.
If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time. So it's very much worth it, and I, for one, am very grateful for it.
And make no mistake - havin every user of curl spend time to read this CVE and decide that it doesn't affect that would be 10000% wasted effort for each and every one of them.
> Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore.
I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs. For instance, one time we had a security team that required us to patch a vmware support package that was installed by default on ubuntu, but the CVE required being ran on vmware when we were running on EC2. Arguing with them was pointless because they were not interested in determining if the CVE applied to us, only that it needed fixed.
Lots of teams that are supposed to be in charge of security don't ask "does this CVE affect us", but simply shift the burden of patching downward and outward. In some cases, like in the case of easy to update and centrally deploy SaaS products, that burden is more annoying and frustrating than difficult. In some cases, like when you have complicated deploy or have customer-controlled updates, those mandates cause a huge burden on teams not producing the decision to patch every low CVE.
Yes, I’ve also experienced this kind of attitude. Some scanning tools can detect that certain CVEs do not apply because the specific functionality is not used.
I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)
There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)
> I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs
This is true, but also: needless CVEs place a burden even on security teams who do take a nuanced view of CVEs - it requires some amount of effort to evaluate every CVE and determine whether it's applicable or not.
Absolutely. I was focused on the burden CVEs place on everyone downstream of teams that don't take a nuance view, but even when teams do look at all the CVEs reported in scans, the proliferation of CVEs just adds workload to determine if they are affected. Unless teams say they will not look at lows (or lower-than-lows if the category existed) then what amounts to busy-work just piles up.
The problem of CVE inflation is not just that you might be forced to patch a CVE that is not applicable to your product. Even investigating to understand whether a CVE is applicable or not takes time, and is simply not worth it for obscure issues like the one in this bug.
It would be revealing to see some of the e-mail communications this person was sending to MITRE while trying to fight this issue.
We’re all familiar with how some use LLMs to write code and submit PRs, but there’s a growing problem of people using LLMs to tirelessly fight issues with communications like e-mails and even suggesting physical paperwork too.
Now that the effort to argue something against an institution is approaching zero, more people are getting the idea to have their LLM and harness fight some battles for them. It feels like it costs them very little but if there’s a non-zero chance of personal gain they do it. I’m hearing a lot of stories about everything from local governments to university administration offices being overwhelmed by requests that just keep coming in from relentless senders who figure asking for anything is worth a try even if there’s no chance it would be granted.
I think we’re going to have to rethink a lot of our communication and request systems that previously relied on the fact that most people wouldn’t take the effort to argue for something that they didn’t deserve. When the cost of arguing approaches zero, the machine can keep trying to get the non-zero chance of success for them.
It sounds like the only end result of this is them making the bureaucracy even more bureaucratic by employing their own agents, where the only way to get anything done is to have your agents fight their agents.
Frankly, it feels like Kafka was actually an optimist.
The incentives here are really bad at the moment. Traditionally, your name on a CVE against an important project like curl have a certain cachet in the community. You might even leverage that to get a raise or a better job, so money was definitely part of this.
Now lots of people are throwing code against LLMs and then copy/pasting whatever comes out into "security" reports.
We decided for our projects that any LLM-generated security reports are simply copied to the public list. Everyone has access to LLMs so presumably if one LLM instance found it, then all users of LLMs have already or shortly will find it. We'll fix them if they're important, but the signal to noise is pretty bad.
I think this will, eventually, result in more secure services as the low hanging problems are found and fixed. But unfortunately I don't see the flood of LLM-generated nonsense ending any time soon.
Unless it's a critical CVE, they're worth very little now for your career.
Same for a lot of side projects or small contributions to OSS, people are still chasing them and wasting everyone's time for nothing. They wouldn't even work on them before AI.
In a way I think the false promise of open source that someone else would have gone through the code is actually going to come true as LLM would have gone through the code.
This kind of hellish experience is a great example of the CVE system trying to have it both ways: when on the offense it’s a rich source of information for defenders, and when on the defense it’s just an opaque ID for coordination that implies nothing about the quality or correctness of the underlying report.
” On June 15, we were again contacted by MITRE asking for the reasoning behind our decision to not give a CVE for this issue.
We replied with similar wording again. Linking to the same issue, again.
This seems like a great system.”
Looks like MITRE is using the Microsoft model of consent: Yes, or Ask Me Again Tomorrow
Someone must have really wanted to put this on their CV.
First thing that came to my mind... why people are so self-centric... and yet, somehow, you feel bad because the same people flex with these CVEs while you can't tell a single huge one you had found under NDAs, while they keep downplaying or ignoring you. I think its better to treat these people as less professional, and try to influence the common reception what is actually professional and what is not.
I think all this goes to the joke/not-a-joke about "you aren't a real hacker until you have a CVE to your name". Its also a form of forced social proof.
> it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.
If it's just about that, fix those low priority issues and bundle them along with the next higher-priority fix pack, i.e. "lower than low" -> fix but not release immediately; "medium" or higher -> release with any earlier unreleased "lower than low" fixes.
Seeing how much energy you spent in dismissing the person's report on the "lower than low" vuln in https://hackerone.com/reports/3455037, it'd be easier and faster to just fix it rather than argue...
According to the linked article, that’s exactly what they did. It was a legitimate bug, but the security consequences were lower than low. It’s a code quality issue, not a security issue, but both are worth fixing.
I don't see how that correlates, and that's already pretty much what they do anyway. The reporter's issue wasn't that it didn't get fixed (it did), but that it wasn't given a CVE.
If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time. So it's very much worth it, and I, for one, am very grateful for it.
And make no mistake - havin every user of curl spend time to read this CVE and decide that it doesn't affect that would be 10000% wasted effort for each and every one of them.