Getting Up Close And Personal With The OSVDBGetting Up Close And Personal With The OSVDB

After my blog post about the revamp of the OSVDB, I was contacted directly by Jake Kouns, one of the OSVDB's project leaders. He wanted to clarify some of the project's goals and respond to some of the criticisms sent his way, and it turned into a deeply involving discussion.

The first criticism Jake wanted to address was the group's use of the term "open source." Yes, the code used to present the OSVDB's database is not available, but the database itself is and always will be, and can be reused by anyone with the proper credit. In Jake's opinion, the presentation layer is something OSVDB reserves the right to keep close to its chest, but the data itself will always be freely available. Their use of the term "open source" stemmed from this, and they decided to simply stick with it over time -- and that they don't feel, in all honesty, that providing the dataset and scheme but not the code to the presentation layer presents any ethical problems.

What about fears that the company would be bought out and turned into a commercial project? This was something it had fought hard to avoid, both in deed and image. I suspect even though it's set up as a registered 501(c)3 nonprofit entity, people who would be inclined to question its motives will continue to do so anyway, no matter what happens. Accusing someone of something it hasn't even done based on what others have done seems bizarrely paranoid to me.

I noted that a friend of mine, a security researcher himself, was kind of derisive about efforts like the OSVDB, because they are reactive, not proactive -- they don't address things like the bad programming practices that he thinks are a major reason for security issues in the first place. Jake agreed that while OSVDB's approach doesn't actively do anything about such things, it isn't really meant to -- it's a separate issue from tracking and making people aware of vulnerabilities, which is their stated goal.

One thing that's being worked on, though, is a way to allow the OSVDB to serve as a kind of "middleware" for vendors that want to be reached out to by independent researchers, and the researchers themselves -- a channel for responsible disclosure of security problems, which I thought was a really good idea. Right now there's a basic framework in place to build this feature on -- the Vendor Dictionary -- so watch for how this develops in the future.

The last and in some ways biggest question I had was how they plan to handle the continued maintenance of the database -- to avoid the "Wikipedia problem," as it were, where the quality of the data entered into the system and its maintenance can become issues. Part of this is handled by designating a certain number of security-savvy maintainers to screen vulnerability data submitted to the system, so that they are not simply at the mercy of whatever is thrown their way.

Another problem is the timeliness of the data. For instance, an entry for an IE vulnerability that has gotten a lot of traffic to the system is not up to date; it listed there being no known fix when in fact one of the very Microsoft links referenced in the article has a patch available. Yes, this can be a problem, he admitted -- but the cure for that is also very Wikipedia-esque: if you see such a thing, it takes relatively little time to provide a correction if you know one exists. The point is to allow those who see a problem to become part of the solution.

There's a balance that's exhibiting itself here, one I've seen elsewhere in the open source world: the give and take between those who use open source efforts and those who contribute to it. Jake has found a number of people using the OSVDB's data without even the proper attribution -- a rather depressing concept, since it's less than no skin off someone's nose to properly attribute the OSVDB's data back to it. But it goes back into something I've mentioned before: If you make something open source, then you have to steel yourself a bit against the possibility that someone's not using it ethically (or even according to the terms of the license). It's part of the territory.

Another issue that arose from that one -- the balance between being an open, public project and a more proprietary albeit better-financed one. If the OSVDB remains a contributor-driven effort, it runs the risk of falling behind a more formally financed one. And if it becomes more formally financed (getting a high level of technical expertise to vet contributions means you'd probably have to pay them), it also means becoming potentially beholden to the money. The OSVDB folks don't have a cut-and-dried answer yet for how to handle that, but the very process of figuring that out, in conjunction with their collaborators, is in itself a sort of an answer.