Slashdot Mirror
Open Source Vulnerability Database Goes Live
Alascom writes "The Open Source Vulnerability Database project has finally gone live. The project aims to provide comprehensive, free and unbiased (no vendor spin) vulnerability information. The database is being incorporated into such fine open source utilities as SNORT and NESSUS."
...per the database info page.
<shameless>
Hey OSVBD folks, here's a little utility to do do some PostgreSQL query analysis!
</shameless>
The Army reading list
The name implied to me that it is only vulnerabilities in Open Source programs/systems that will be tracked, but reading the FAQ it seems to be that the database itself is open-source, and the database covers all systems. I think they could have named it better.
Simon
Physicists get Hadrons!
Not the project, just the posts. Sendmail vulnerability from 2002? FreeBSD vulnerability (top of the list, no less) from 2000? Did I miss something?
Slashdotting. ;)
No vendor spin on security issues. Now we can know the truth to the best of our ability without corporate FUD, hype or downplay.
Gotta love technology when it helps get the full-truth out there.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
How long will it take till they say that?
After 3 days without programming, life becomes meaningless
- The Tao of Programming
But CERT certainly has been.
I could see many users getting angry over this, thinking this is to the disadvantage of open source technology, but no.... this is clearly an advantage! This database will help ensure that essential bug fixes get worked on immediately.
So don't flame over this... it will help make open source software more secure!Oh, right, and if you might think to the contrary, that people not knowing about vulnerabilities is the best way to go for security, you clearly need to do more research on the way open source software works, and why it is so effective.
http://mediagoblin.org/
This should be done for all types of software...Perhaps developers will be a little more careful with their codeing and end users will be able to see just how secure the software is before they commit to it.
As it seems to be already /.ed here is the Google cache
Yeah, this'll be *real* useful. A database with entries that become obsolete after eight hours. "There's a Linux kernel vulnerability, and it...aw, darn." ;-)
May we never see th
Open source vulnerability database goes live...and two days later, it goes dead.
Slashdot - bringing you customizable DDoS attacks for years to come.
I think that this is an excellent concept...I just wish that it were executed well enough that the site wasn't Slashdotted after 25 comments. I mean, damn, we're already trying to shake off the image of being a bunch of amateurs, and having a web site that can't even stand up to moderate traffic doesn't help.
How To Get Humans To Mars
you know i hate the company but it has already been done and is most likely a better DB.
the MITRE Common Vulerability and Exposures DB
http://www.cve.mitre.org/
Security Focus became BIASED as heel from when Symantec bought them. Finally a really neutral source of information. Thank you for doing this guys ...
Regardless of the amount of time passed, the general public, or hacker public, does not need to know how to exploit these bugs, only that they exist, and are being fixed, and where to get the newest version.
And what happens when it isn't being fixed? Vendors have shown time and time again that unless pressure is put upon them, security fixes have a very low priority. Full disclosure is the best method of increasing that priority.
Customers have a right to know that they are using vulnerable software, and be given the chance to secure themselves in any way possible. When I say customers, that means not only joe sixpack, but the admins of mission-critical and sensitive systems as well. If the vendor is unable or unwilling to fix the problem in a reasonable amount of time, the public should be given the ability to. Security through obscurity is a farce. Script kiddies might take exploit code once it is posted, but the crackers that otherwise know of these exploits are the ones doing the real damage.
Information can be abused, yes, but personally, I think it is better than ignorance.
Calling something "open source" doesn't make it open or free (as in freedom). There are three issues of concern here.
First, the licensing terms Why didn't they license the OSVDB database under a free license, whether it be GPL, GFDL, or even the BSD license? If OSVDB and its sponsors (including primarily Digital Defense, Inc., a privately held computer security firm) retain complete ownership of the content, and nobody has the right to fork the database or create derivative works, I can't see why it's being spun as "open source".
Second, I was concerned when I read the OSVDB's statement of intent to comply with the DMCA. A non-free (read: non-forkable) database based in the United States might not be the best idea. One DMCA injunction could shut it down. Since, from my reading of the terms and conditions, nobody has the right to duplicate or fork this database, the work could not continue outside the US if a DMCA injunction shut it down.
Third, the issue of neutrality and bias. I don't believe that a non-free database sponsored by a private security consulting firm based in the United States will be able to remain neutral for long. Private companies are under no obligations to disclose their partnerships or agreements with vendors.
You know, there are non-trivial, free (GFDL) databases out there...the precedent exists for high quality, truly FREE content. I hope OSVDB considers licensing the content under the GFDL or BSD license.
This covers all products all platforms, not just Linux, *BSD etc...
Here we go again!
Where's the OSVDB client, that I install on a host on my LAN, that gets up-to-date security notices selected from queries defined by my local configs? That is the missing layer in OSS SW distribution. Installers, like apt-get, should register installed packages with the local OSVDB.
The local DB gets queried by the client for installed inventory, queries the remote server. Vulnerable SW is tagged with advisory instructions, including patch URLs, confirmation URLs, and "help me" URLs, as well as the URL of the Internet site with that support and more (discussions, etc). The client sends a notification email to the sysadmin, optionally including clickable HTML to install the patch packages (which are, of course, registered with the local DB). Confirmation reports are easily entered in the HTML interface, pointing at the client, which first posts them to the local DB cache for later analyis, then posts them to the remote OSVDB. Requests for help are passed to tech support, based on a policy config'ed when the client is installed: existing support contracts, filtered marketplace pool, goverment/industry referral service.
This infrastructure is the natural evolution of the global infosystem. It mirrors the evolution of the cell: we've got a cell (fire)wall already, and the nucleus (sysadmin server) is now growing a membrane (security infrastructure), with tRNA codes (patches) keeping homeostasis (uptime). As the organism (network) is sickened (exploited) by viruses (viruses) and genetic defects (bugs), vaccines (patches) and therapies (upgrades) keep the organism healthy, and reduce the risk of epidemic infection (every few days on the Internet). Once organisms got an immune system, and communities that worked with it, we took over the world from the volcanoes, eventually freeing our brains for human endeavors (gaming, surfing porn, online dating). If developers bundle the straightforward complexity in simple automated tools, the infosystem's health will become as implicit as our own.
--
make install -not war