Should open source projects care about getting CVE IDs?
Only if you want to.
But it’s a little bit more complicated than that. Even if you don’t care about CVEs, someone else will. And both situations are OK. I think there’s ways to work with this. But first a story about rats.
This is sort of the part two from my other blog post Dear Open Source Developers: It’s OK not to embargo
Rat mode
There’s a show I enjoy called Jet Lag: The Game. In Jet Lag, there’s a thing they call “Rat Mode”. It’s when one of the players start to do completely unexpected and silly things. How they came up with this name is fun to discover, I won’t spoil it here.
But the point is in the context of open source and CVEs, sometimes doing unexpected things has positive results. Sometimes it doesn’t of course, but given this is open source we can revert changes pretty quickly so bad ideas are easy to try and easy to fix. If someone complains, tell them you’ll send a refund.
So what’s CVE rat mode? It’s not caring about CVEs at all. Treat everything as a bug, live your life, run your project. Never think or worry about CVEs.
All of the security people are probably freaking out right about now. Don’t worry, there’s something in here for you too.
So what’s the deal with CVEs?
If you’re an open source project, and you want to work with CVEs, you have a few options under what I’ll call the “traditional” model. I will briefly explain them below.
Become a CNA
You become a CVE Numbering Authority. There’s some training, and a lot of rules you have to understand and follow. Your project becomes your CVE “scope” and only you can assign CVE IDs (in theory). You control your CVE destiny.
It’s not free to do this and it will eat some of your time. Some projects have decided to do this. Some haven’t. The biggest advantage is you can decide what does or doesn’t get an ID and you can get IDs very quickly.
If you are a single person, part time project this is likely more work that it’s worth.
Use GitHub
You can ask GitHub to give you a CVE ID when you file a GHSA. You have to fill out the GHSA and there is currently a lag between asking for a CVE and getting one. It’s just a checkbox so it’s super easy. Once the ID exists getting GitHub to update it can take a while in the event you made a mistake.
The only real downside here is the time delays since GitHub is super busy due to the deluge of vulnerabilities. GitHub is carrying a lot of water for the projects here, I’m not being critical, I’m just setting the expectations.
Ask the CVE program
You can ask the CVE program for IDs on their Request a CVE ID page. They’re pretty slow to issue IDs and even slower to update them. It’s more work than GitHub because you have to give them all the details GitHub will just figure out for you.
The secret option
But there’s the secret CVE option. That’s to do nothing. You can note a bug is a security vulnerability if you want. Or not, whatever. Don’t worry about filing a GHSA. If people want to report a vulnerability to you, they open an issue. They can tag it security if they want, but that doesn’t change anything. A bug is a bug.
Eventually someone will probably show up and request a CVE, but that doesn’t have to affect you. It’s just a bug with a funny label as far as you’re concerned.
If the CVE is unfixed I guarantee you’ll get someone showing up in the issue asking for a fix because their auditor says they need one. You can fix the bug to make it go away, or give them the good old “patches welcome”. Or even suggest they visit your patreon and join the “I’ll fix your bug” tier.
This is the dumbest idea I’ve ever heard
It might be. I’m not entirely sure this is a good thing. But here’s how I’m thinking about this.
First: there are a lot of vulnerability reports. Too many for most open source projects to handle sanely.
Second: the number of open source maintainers who want to only work on security bugs is very close to zero.
Third: in the world of open source a lot of things get externalized onto the developers. Uno reverse this cost.
A lot of open source developers I speak with want to work on their open source projects and not worry about the baggage that comes with a CVE. If you’re a moderately large project you might have people who like working on security bugs. That’s great. Accept reports, get CVEs, play the game.
But if you’re a single person working on a project you started because you thought it would be fun. And if it’s not fun anymore because you’re getting too many security reports. You need to do whatever it takes to bring back the fun. Stop suffering for the benefit of others.
This has been happening for years
One of the unspoken secrets in the world of application security is open source projects are chocked full of unlabeled security bugs in the PRs and issue trackers. It’s not that anyone is trying to hide security bugs. They just didn’t notice, or someone got busy and forgot to label something. Or maybe they did know and didn’t want to bother with all this CVE nonsense.
I work with a team that handles CVE data, we’re seeing more and more reports every day where researchers are looking at old bugs and patches for security vulnerabilities. And there are a lot of them. This topic deserves its own blog post in the future because I think this is going to be the next security tsunami to hit open source.
I mostly point this out because it’s not a new thing, and it’s proof the world won’t end if you try something like this. The worst case will likely be annoying comments in issues. GitHub has a neat feature where you can Unsubscribe from issue notifications.
Anyway, the point of all this is to really just say if you’re an open source project that doesn’t want to deal with CVEs, that’s OK, you don’t have to.
Also don’t get too grumpy when your bugs get CVEs, I guarantee they will eventually. I’m also a firm believer in more and better vulnerability data, getting everything cataloged is good. There are people who care, they will show up and help. This is related to my previous blog post. If all the security issues are embargoed, we lose the power of open source.
Just remember the wise words of WOPR: The only way to win is not to play.