Before open source software took over the world, people bought software from companies with cold hard cash. There were rolex watches involved, but there were also regular security updates, too. Crazy, right?
Vulnerability disclosure for commercial software typically goes like this:
A security researcher sends an email, encrypted with PGP, to the vendor’s security team letting them know that a security issue exists Once they acknowledge receipt, a more detailed disclosure of the vulnerability is shared The vendor will then establish a timeline for fixing the issue, validating that the fix actually works, and planning the release of the fix. Once the fix is released, the vulnerability is disclosed publicly.While this process usually works well for commercial software, there are many ways that it can fall apart when disclosing open source vulnerabilities.
Who you gonna call?It’s not always obvious who should be contacted about a security disclosure on an open source project. Is there an email address for security issues? Probably not. Who are the current active maintainers? Good question.
We disclose a lot of new vulnerabilities in open source libraries and unfortunately most of the time we never get a response to our initial email. We follow up every week until the 30-day mutual-disclosure period expires, but it’s often just a waiting game. When the 30 days are up, we disclose the issue publicly.
If you maintain an open source project, please add contact information to your README file to ensure security issues can be addressed quickly.
Don’t sweep vulnerabilities under the rugSometimes maintainers are so eager to fix the issue, they just go ahead make a fix, and cut a new release. The release notes might say something about fixing a security bug, but that doesn’t go far enough to help protect your users.
Instead, work together with the research team to establish a timeline for public disclosure. This allows for public disclosure of the detailed security issue, including the list of effected versions, the vulnerable methods, etc. to ship at the same time that a fix is released. Throw a link to the disclosed vulnerability in your release notes, so everyone has the best information on how to keep themselves safe.
If you have a project that is no longer actively maintained, say soAnother reason vulnerabilities in open source libraries may not get fixed is that the project itself has been abandoned. Abandoning projects isn’t the issue, but failing to identify a project as abandoned means people may unwittingly use a project that they now need to take responsibility for maintaining themselves in order to stay safe.
We want to improve the state of security in open-source software. If you have other ideas for improving disclosure for open source, we’d love to hear it. Also,we’re hiring!
