I recently talked to Sal Kimmich on the podcast. The topic centered around solutions to many of our existing systemic problems, Sal has an impressive understanding of the current problems as well as how to fix those problems with systemic long term solutions. But systemic fixes are the long game. Things that will help future me are not helpful to present me. And present me, present everyone, is drowning in security problems right now.
What can do right now to help with the problems? The future systemic solutions Sal is talking about are going to take years, maybe decades. I have problems today. At the moment, I am less interested in future fixes than I am in right now fixes.
So what can we do today?
Every security team is drowning in vulnerabilities, attacks, compromises, and work. Everyone already has more tools than they know what to do with. Nobody has enough staff. It’s not very clear what we can do to make a difference with what we have. Most of the advice from the self proclaimed experts is to “GO FASTER” which is not only stupid, but also useless.
I’ve not seen any actual real suggestions on what to do. The reality is nobody knows what to do because everyone is trying to exist in security mindset and rules that were created long ago. We can’t change what is happening around us, we can’t acquire vastly more resources. The only thing we can do is change the rules we follow.
The way we handle security problems today is the result of expectations that were created in a world that no longer exists. There were hundreds of vulnerabilities. Most of the internet wasn’t using https. Everything was a lot slower and easier to understand. Ideas like spending plenty of time coordinating vulnerabilities, fixing all the CVEs, and investigating every alert were reasonable and expected.
But today? Anyone receiving vulnerability reports from researchers can’t keep track of half of the incoming. Fixing all the CVEs in all the software is almost as funny as trying to deeply investigate 1% of the alerts your team gets from the tools. And the cherry on top of this poop sundae is all the talking heads that claim AI is the solution.
Vulnerabilities as our example
Let’s use vulnerabilities as our example. Open source projects are drowning in these things. So are closed source, but for this post, I’m going to focus on open source security (see what I did there). This is without question the result of the LLMs finding vulnerabilities. But what we don’t have is the ability to triage the reports as quickly. This is an easy example of the lopsided modern problem space.
It’s also a good example because what most open source projects need isn’t more tools, it’s more time. You could add people, but that’s a whole complicated conversation thanks to Jia Tan. And that would assume there are people to add (there aren’t).
So if we have more vulnerability reports than ever. We don’t have enough time to triage them all. We can’t add more time. But what if we could reduce the number of reports? How would we even do that? We can if we change the definition of a vulnerability for our project.
Can we do that?
We can do anything, we’re open source!
There are two ways to interpret this statement. On one hand, open source developers have been doing incredible things with no resources for decades. Open source can do anything. But also, there’s a clause in nearly every open source license.
Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND
This means we can make a decision like not fixing every bug in a timely manner because the software is provided “as is”. We get to make the rules. If someone doesn’t like it, they can help, fork it, or use something else. The reality is most complainers will do nothing because the only option easier than complaining is doing nothing.
But back to vulnerabilities
There are two ideas I want to explore
- What if we just stopped assigning CVE IDs to low and moderate vulnerabilities?
- What if we defined aggressive boundaries around our attack surface?
The most important aspect to keep in mind here is that dealing with embargoed vulnerability reports is VERY expensive. They take a lot of time and mental energy. I don’t have any data, but in my experience I would say an embargoed vulnerability report is easily 10 times more effort than dealing with a bug filed in the issue tracker.
There are many possible options for changing the environment around us, I use these as simple examples in this particular discussion.
Let’s talk about the idea of calling low and medium things bugs
The first response will be “but we can chain them together!”. You can chain together regular bugs too to make systems do weird things. We’re not saying don’t fix them. We’re saying stop treating them special. Treat them like bugs, if someone finds a clever chain, increase the severity and fix it faster.
The next response will be “but how can we decide what low and moderate even are?” It’s not up to us to decide. Let the project decide. They know vastly more about what’s going on than security people do.
What does an aggressive attack surface boundary mean?
This one means we decide to not deal with certain types of bugs as vulnerabilities. If I have a web framework, defining regular expression denial of service (ReDos) as bugs instead of vulnerabilities is an easy example. ReDos are annoying and mostly harmless.
If you’re an SBOM scanner, you can define purposely trying to hide packages as something that’s not a vulnerability. We did this with the Syft SBOM scanner by defining a trust boundary. Syft is an SBOM scanner, it’s not a security scanner.
There are an infinite number of ways to define this one. It’s probably going to be easiest to just keep adding things as they come in and you decide they’re out of scope. The “right” way to do this would be building a threat model and attack surface diagram, but zero open source projects have the time to do that right now.
Keep in mind that a lot of how we coordinate vulnerabilities are the result of Microsoft in the early 2000’s. They had disdain for security researchers, these rules are all designed to put the reporters at a disadvantage while making less work for Microsoft. Thank goodness that’s no longer the case in 2026.
Playing it safe
There are people who will claim doing things the way it’s always been done is the safest bet. It’s not because if you think you’re doing things the old way you’re lying to yourself and everyone else. Or you’re an idiot. Probably both I suppose. Playing it safe during disruptive times is the refuge of cowards.
We are well past a point we can pretend anything is normal or fine. This is just neglect and irresponsible behavior. Nobody can keep up, we’re dropping a huge number of things on the floor, we’re not playing it safe. This is the opposite of safe. Every security team is hoping the things they’re not seeing are less important than the things they do see. It keeps us up at night.
If anything the volume of incoming will only increase for the foreseeable future. The only thing we can change for the next year or two is what we respond to.
In order to add ideas to this discussion, and because it amused me to write it, I have included a FAQ at the end. I have heard these phrases uttered over the last few months as I have tried suggesting doing less to various people I know. If you have some choice phrases you’ve heard do let me know!
What’s next?
It’s much easier to say we should change the rules than to understand what changing these rules needs to look like. I won’t pretend it’s easy. Deciding what to stop doing is hard. Luckily when you stop doing something, the steps needed tend to be pretty simple.
Some of what we do is driven by external auditors, or compliance standards. It’s easy to say “do less” when you’re not the one who has to figure out what to stop doing. I suppose the only thing I would say is you’re going to make mistakes, you’re going to screw things up. But your’e already making mistakes and screwing things up, so it’s basically going to be a wash.
FAQ
Or maybe are frequently uttered statements
It’s irresponsible to not coordinate vulnerabilities!
It’s also irresponsible to use open source without funding it, yet nobody seems to worry about these minor details.
You’re giving the attackers an edge!
They have AI too, I bet they already know about these bugs. They’re probably laughing at you right now.
We can’t do it that way!
You can do whatever you want. I’ll tap the sign
Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND
You’re shifting the burden to MY security team!
Correct, feel free to change your rules, or you are welcome to come help and shift it back. We all know you’re going to do nothing, it’s OK.
It’ll go back to normal in a few months
I applaud your optimism and lack of reality based existence
I’m going to rewrite your project with an LLM
Awesome, let us know how it goes