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?
  • 5
    Those vulnerability databases coalesce data from a range of sources, and are often summarised in a hurry when there's a large backlog to go through. The operators of those databases strive for accuracy, though, so they should be more than happy to correct any false information. If you have a patch release notice, you can submit that to them too. Get in touch with them and explain the situation - they should fix the issues pretty quickly.
    – Polynomial
    Aug 30, 2012 at 6:09
  • 1
    One of the problems is knowing who "them" are. There seem to be more sites out there than I can reasonably find, and I'm halfway sure I'll miss one. Aug 30, 2012 at 23:25
  • 1
    Stick to what you can find. Others are likely to be less well-known, and often just spider the existing databases of others.
    – Polynomial
    Aug 31, 2012 at 6:02

5 Answers 5


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.


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:

  • 2
    Added a quick and dirty contact page. The bug tracker will come later after I finish the move to github. Aug 30, 2012 at 8:07

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.

  • 3
    "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" - I think you might have misread the question. Michael is the author of a PHP application, and he is asking how to avoid getting surprised by public disclosure of vulnerabilities in his own code. No package manager is going to solve that for him. The open source community is not going to somehow magically patch his code for him.
    – D.W.
    Aug 30, 2012 at 5:52
  • Not to mention I'm looking for answers that can help any application developer; it is meant to be a question useful to the global Internet community as well as myself. Aug 30, 2012 at 20:18

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .