A CVE Dispute

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.

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.

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.

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

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...