To view older blog posts, please visit the archives section.

The Joys of Responsible Disclosures

I’m currently sitting on a stack of unreported security problems (none of which are critical) in various pieces of software, ranging from general-purpose libraries and frameworks to e-commerce SDKs. Why, you might ask, have I not reported them yet?

Because of common gaps in open-source project management.

Now, don’t get me wrong—this isn’t about a lack of goodwill. Open-source maintainers are some of the most dedicated people out there. But despite their good intentions, there are common pitfalls in the way projects are managed that can make the process of responsible disclosure unnecessarily challenging. Let me explain.

Over the past week, I’ve been investigating various vulnerabilities. This led me to uncover instances of similar vulnerabilities across multiple projects. The hardship of reporting these prompted several observations about how open-source software could be made more secure through better practices.

1. If You’re No Longer Maintaining a Project, Say So Clearly

This statement might seem obvious, but it’s a point that hadn’t occurred to me until recently. 

The world is drowning in code—some of it actively maintained, much of it abandoned. Yet, many people still rely on abandoned code without realizing it’s no longer being updated.

In just the past few days, I’ve come across countless GitHub repositories with newly opened issues or pull requests, yet the underlying code hasn’t been touched in years. This tells me people are still actively using these projects, but no one is maintaining them—which means security vulnerabilities aren’t being addressed.

If you’ve decided to stop maintaining an open-source project, do the community a favor: state it clearly. Ideally, transfer ownership of the project to someone in the community who can continue its development. If that’s not an option, make one last update to the README file, announcing that the project is no longer maintained. This way, users can make informed decisions, and someone might even pick up the torch and fork the project.

2. Provide a Way to Report Issues Privately

Nobody likes full disclosures. Responsible disclosure is the preferred path for reporting vulnerabilities. But how can researchers report issues privately if you don’t provide a clear way to contact you?

Without proper channels, researchers are forced to find workarounds, which wastes everyone’s time and may lead to unintended exposure of sensitive information.

If you manage an open-source project, make it easy for people to reach you securely. A simple way to do this is by adding a SECURITY.md file to your GitHub repository. This doesn’t need to be overly formal. A short note like, “If you’ve found a vulnerability or have a security concern, please email [contact info]” is often enough. This small step can make a big difference.

3. Use Platform Resources for Security Disclosures

Not everyone knows how to handle vulnerability reports, and that’s okay! We live in an era where tools and resources for open-source maintainers have never been more accessible. For example, if your project is hosted on GitHub, you can enable private vulnerability reporting.

This feature allows researchers to report issues directly through GitHub in a controlled environment. It also provides maintainers with guidance on publishing security advisories and can even assign a CVE number—all without leaving the platform. It’s a simple, powerful tool that can streamline the entire disclosure process. Why not take advantage of it?

4. Don’t Be Surprised When Someone Reports a Vulnerability

If your project has any kind of following or community, it’s only a matter of time before someone finds a vulnerability in your codebase. This isn’t a personal attack—it’s a contribution to your project in a different form.

As an open-source maintainer, you should be prepared to handle vulnerability disclosures. Fortunately, it doesn’t have to be difficult. If you’re unsure where to start, engage with your community—someone might be able to help. Alternatively, resources like the OWASP Vulnerability Disclosure Cheat Sheet can provide you with clear, actionable guidance.

A Better World for Open Source Software

Take a look around you. Chances are, you’re surrounded by connected devices, most of which rely on open-source software. This software needs to be maintained. To ensure its security, maintainers should make it easy for researchers to report vulnerabilities responsibly. Unfortunately, that’s not always the case.

The last thing anyone wants is a full disclosure of a critical bug in widely used software. If you manage an open-source project, take 10 minutes today to add a SECURITY.md file or enable private vulnerability reporting. It’s a small step that could have a significant impact on the security of the open-source ecosystem.