How do I respond to a published security vulnerability in my application?

Question

In my spare time I write some PHP code the purpose of which is to block link spam and other various malicious activity.

On May 11 someone who discovered an XSS vulnerability in the WordPress version of this code published it without notifying me first. Fortunately my users are on the ball and notified me on May 12. On May 13 I published a fix.

That wasn't the end of it.

Since then I've discovered that the vulnerability was added to a wide variety of databases such as OSVDB and CVE and various mirrors of those databases, with varying degrees of inaccuracy.

For instance, one such site lists somebody completely different as the author of the software. Another lists it as having never been patched.

So my ultimate concern is:

Since vulnerabilities in my application are going to be published all over the Internet whether I like it or not, how do I...

• Find out about a zero-day vulnerability against my application as soon as possible, without having to receive irrelevant notifications?
• Find out when vulnerability databases create entries related to my application?
• Ensure the accuracy of vulnerability database entries related to my application?

Answer 1

For the future, there is one critical thing you should be doing:

• Provide an easy way for people to report security bugs to you.

  I took a look at the web page for your application, and I noticed it doesn't seem to list any way for a security researcher to contact you with a report of a security vulnerability. There is no email address to report security vulnerabilities, or at least I couldn't find one. I couldn't find a bug tracker that lets people submit a confidential security vulnerability report (or even any bug tracker at all that lets a member of the public submit a bug report, let alone a confidential report of a security bug).

  See, e.g., CERT's Recommendations to vendors and Hey corporations: Provide a easy way to disclose vulnerabilities to you!.

  Of course, this is not a silver bullet. Even if you do provide a clear way to report a security vulnerability, some folks still might not contact you -- but some responsible researchers will. In any case, I can tell you one thing: If you don't provide any obvious way to contact you with a security bug report, that significantly diminishes the likelihood that security researchers will do so in the future!

There are also some additional steps you could take, if you wanted, but these are optional and beyond what I would classify as important or essential for an open-source project:

• Do a security assessment of your own code.

  You could use security static analysis tools and black-box penetration testing tools to assess the security of your own code. This way, you have a better chance of detecting any security problems yourself, before others discover them.

  See, e.g., What are some good, free tools to run automated security audits for PHP code? and How to perform a security audit for a PHP application?. Also, take a look at RIPS, a tool that scans your PHP code to try to find potential security vulnerabilities.

• Follow places where vulnerabilies are disclosed.

  You could try to keep track of various places where vulnerabilities are reported publicly. For instance, you might follow the full-disclosure mailing list.

Answer 2

I liked D.W.'s answer so much I'm loathe to write another, but I had some points that were big enough that I'm unfortunately repeating here:

How do I - find out about a zero-day vulnerability against my application as soon as possible, without having to receive irrelevant notifications?

Get as close to the source of vulnerability disclosure as you can, and realize it won't always be the same source. That's going to have to be a combination of getting better at information-retrieval and making yourself easy to find (which has it's own spammy implications).

Good ideas include: - have an obvious way on your site to include bugs and vulnerabilities - make sure that when you are repackaged by any other system, part of the agreement is that bugs in security are sent to your bug/vulnerability tracking system. You'll probably want to discuss how issues are vetted before they are sent your way, but realize that often the biggest vulnerabilities are in how your system integrates with the bigger system. - make sure vulnerability publication sites know how to find you - it won't fix a true "zero day" as they may lag behind by hours or days, but you definitely want to hear directly from them. - collect as much information as you can relevant to potential product vulnerabilities - Google Alerts - was a great idea. I'm sure there are others.

You may need to accept that irrelevant information will come your way - the best you can do is sort it.

Keep in mind, as well, that not all vulnerabilities are found by the good guys. Waiting for someone else to find it is never the ideal way of finding vulnerabilities. As the product grows, you'll want to introduce some form of security verification, including things like:

• Code security analysis - both manual and automated.
• pen testing
• independant review

The level of effort needs to be balanced by the cost of error, here - but you may find that the cost of finding and responding to a vulnerability that gets disclosed in public is higher than implementing your own security verification.

How do I - Find out when vulnerability databases create entries related to my application?

Many of the vulnerability databases have streaming of alerts - you should be able to subscribe to a stream and filter or get an RSS feed and limit it with search criteria.

How do I - Ensure the accuracy of vulnerability database entries related to my application?

First - create a relationship with the database groups. And make it clear how to create a relationship with you if a database group is looking reach out. CERT's guidance, and this article - are great resources for recommendations, but the critical part is realizing that if they can't get to you, they won't get the right answer.

And it's a two way process - have a way to find you, but also find a way to publish information. And when you publish, include solid answers. As developer of solutions, I have too many run-arounds with solutions vendors who give security vulnerability information that sounds like they dreamed it up on the ride to work with no actual testing or factual information. List things like:

• specifics on the fix
• specifics on the testing used to verify the fix
• specifics on the impact of taking the fix (is there any chance something I was relying on will change or break?)
• general summary of the scope of the change - for example "fix made to an underlying utility function", "fix made to specalized code base used for XYZ interoperability, impact outside of this space is extremely limited"

And details of what CVE or other published issue you are trying to fix.

Put it up in as many streams as you can - email subscription, blog, website, etc. You want this to be findable.

And make your process known. If I submit a vulnerability to your website, can I expect to hear back in 24 hours? How do you rate severity? What is the process for resolution? If it's a product that is integrated in other solutions, who does the interop testing?

You don't need perfect metrics, you need to be able to live up to them. So, if your turnaround response time is 2 weeeks - let the users know that.

Answer 3

Zero-day vulnerabilities are more often underground than not, so it will be difficult to apprehend through a trusted source. Published statements typically only occur after the vulnerability has been detected and traced by the victims, often early enough for other potential victims to patch their systems. Unfortunately, these messages only get to the open source community once the publishers distribute the information regarding the vulnerability, leading to a ripple effect of patching.

Thankfully, if you auto-update your software through a package manager, vulnerabilities may be automatically patched for you by the open source community, mitigating the need for self-validation.

First off, it's worth mentioning that CVE has a list of vulnerability alerting services that may be of your interest. These tools will push notifications to alert you when necessary.

You may be interested in reading through certain vulnerability newsletters such as @RISK, which publishes articles about vulnerabilities on a weekly basis.

SecurityFocus also updates their website with a list of vulnerabilities (albeit without a feed) in a spectrum of software.

In order to filter through irrelevant notifications, you may be interested in having a cronned script filter through the content for keywords related to your software.

Answer 4

Google Alerts - work out a search query that finds mentions of your software and vulnerabilities, set it to email you daily, and you'll know about anything within 24 hours of Google indexing it.

Answer 5

If your software is included in big distros like Fedora, Debian, gentoo, etc. it will be beneficial to get in contact with their security teams. I am sure they will be more than happy to have you fix any future security issues that arise as well you would benefit the resources they have to check various sources of vulnerability information daily.