Blog - We have to change the rules of security | Open Source Security

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