OSVDB Blog Migration
For years, we have used Typo3 for our blog, hosted on one of our servers. It isn’t bad software at all, I actually like it. That changes entirely when it sits behind Cloudflare. Despite our server being up and reachable, Cloudflare frequently reports the blog offline. When logged in as an administrator and posting a new blog or comment, Cloudflare challenges me by demanding a CAPTCHA, despite no similar suspicious activity. Having to struggle with a service designed to protect, that becomes a burden is bad. Add to that the administrative overhead of managing servers and blog software and it only takes away from time better spent maintaining the database.
With that, we have migrated over to the managed WordPress offering to free up time and reduce headache. The one downside to this is that Typo3 does not appear to have an export feature that WP recognizes. We have backfilled blogs back to early 2007 and will slowly get to the rest. The other downside is in migrating, comments left on previous blogs can’t be migrated in any semblance of their former self. Time permitting, we may cut/paste them over as a single new comment to preserve community feedback.
The upside, we’re much more likely to resume blogging, and with greater frequency. I currently have 17 drafts going, some dating back a year or more. Yes, the old blogging setup was that bad.
CVSSv2 Shortcomings, Faults, and Failures Formulation
The Open Security Foundation (OSF) and Risk Based Security wrote an open letter to FIRST regarding the upcoming Common Vulnerability Scoring System (CVSS) version 3 proposal. While we were not formally asked to provide input, given the expertise of managing vulnerability databases, along with the daily use of CVSS, we felt the feedback would provide valuable insight to improve CVSS in the future.
Some of the areas discussed include:
- Introducing 4 levels for granularity
- Better definitions for terminology for more accurate scoring
- Re-examining the pitfalls of “Access Complexity”
- Limitations of the current Access Vector breakdown
- The challenge of scoring authentication
- And a variety of other considerations to improve vulnerability scoring
Our conclusion points to the need for CVSS to be overhauled as CVSSv2 has too many current shortcomings to provide an adequate and useful risk scoring model. You can download the full letter in PDF format.
CVE Vulnerabilities: How Your Dataset Influences Statistics
Readers may recall that I blogged about a similar topic just over a month ago, in an article titled Advisories != Vulnerabilities, and How It Affects Statistics. In this installment, instead of “advisories”, we have “CVEs” and the inherent problems when using CVE identifiers in the place of “vulnerabilities”. Doing so is technically inaccurate, and it negatively influences statistics, ultimately leading to bad conclusions.
NSS Labs just released an extensive report titled “Vulnerability Threat Trends; A Decade in Review, Transition on the Way“, by Stefan Frei. While the report is interesting, and the fundamental methodology is sound, Frei uses a dataset that is not designed for true vulnerability statistics. Additionally, I believe that some factors that Frei attributes to trends are incorrect. I offer this blog as open feedback to bring additional perspective to the realm of vulnerability stats, which is a long ways from approaching maturity.
Vulnerabilities versus CVE
In the NSS Labs paper, they define a vulnerability as “a weakness in software that enables an attacker to compromise the integrity, availability, or confidentiality of the software or the data that it processes.” This is as good a definition as any. The key point here is a weakness, singular. What Frei fails to point out, is that the CVE dictionary is not a vulnerability database in the same sense as many others. It is a specialty database designed primarily to assign a unique identifier to a vulnerability, or a group of vulnerabilities, to coordinate tracking and discussion. While CVE says “CVE Identifiers are unique, common identifiers for publicly known information security vulnerabilities” , it is more important to note the way CVE abstracts, which is covered in great detail. From the CVE page on abstraction:
CVE Abstraction Content Decisions (CDs) provide guidelines about when to combine multiple reports, bugs, and/or attack vectors into a single CVE name (“MERGE”), and when to create separate CVE names (“SPLIT”).
This clearly denotes that a single CVE may represent multiple vulnerabilities. With that in mind, every statistic generated by NSS Labs for this report is not accurate, and their numbers are not reproduceable using any other vulnerability dataset (unless it too is only based on CVE data and does not abstract differently, e.g. NVD). This distinction puts the report’s statements and conclusions in a different light:
As of January 2013 the NVD listed 53,489 vulnerabilities ..
In the last ten years on average 4,660 vulnerabilities were disclosed per year ..
.. with an all-‐time high of 6,462 vulnerabilities counted in 2006 ..
The abstraction distinction means that these numbers aren’t just technically inaccurate (i.e. terminology), they are factually inaccurate (i.e. actual stats when abstracting on a per-vulnerability basis). In each case where Frei uses the term “vulnerability”, he really means “CVE”. When you consider that a single CVE may cover as many as 66 or more distinct vulnerabilities, it really invalidates any statistic generated using this dataset as he did. For example:
However, in 2012 alone the number of vulnerabilities increased again to a considerable 5,225 (80% of the all-‐time high), which is 12% above the ten-‐year average. This is the largest increase observed in the past six years and ends the trend of moderate declines since 2006.
Based on my explanation, what does 5,225 really mean? If we agree for the sake of argument, that CVE averages two distinct vulnerabilities per CVE assignment, that is now over 10,000 vulnerabilities. How does that in turn change any observations on trending?
The report’s key findings offer 7 high-level conclusions based on the CVE data. To put all of the above in more perspective, I will examine a few of them and use an alternate dataset, OSVDB, that abstracts entries on a per-vulnerability basis. With those numbers, we can see how the findings stand. NSS Labs report text is quoted below.
The five year long trend in decreasing vulnerability disclosures ended abruptly in 2012 with a +12% increase
Based on OSVDB data, this is incorrect. Both 2009 (7,879) -> 2010 (8,835) as well as 2011 (7,565) -> 2012 (8,919) showed an upward trend.
More than 90 percent of the vulnerabilities disclosed are moderately or highly critical – and therefore relevant
If we assume “moderately” is “Medium” criticality, as later defined in the report, is 4.0 -‐ 6.9 then OSVDB shows 57,373 entries that are CVSSv2 4.0 – 10.0, out of 82,123 total. That means 90% is considerably higher than we show. Note: we do not have complete CVSSv2 data for 100% of our entries, but we do have them for all entries affiliated with the ones Frei examined and more. If “moderately critical” and “highly critical” refer to different ranges, then they should be more clearly defined.
It is also important to note that this finding is a red herring, due to the way CVSS scoring works. A remote path disclosure in a web application scores a 5.0 base score (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N). This skews the scoring data considerably higher than many in the industry would agree with, as 5.0 is the same score you get for many XSS vulnerabilities that can have more serious impact.
9 percent of vulnerabilities disclosed in 2012 are extremely critical (with CVSS score>9.9) paired with low attack/exploitation complexity
This is another red herring, because any CVSS 10.0 score means that “low complexity” was factored in. The wording in the report implies that a > 9.9 score could be paired with higher complexity, which isn’t possible. Further, CVSS is scored for the worst case scenario when details are not available (e.g. CVE-2012-5895). Given the number of “unspecified” issues, this may seriously skew the number of CVSSv2 10.0 scores.
Finally, there was one other element to this report that was used in the overview, and later in the document, that is used to attribute a shift in disclosure trends. From the overview:
The parallel and massive drop of vulnerability disclosures by the two long established purchase programs iDefense VCP and TippingPoint ZDI indicate a transition in the way vulnerability and exploit information is handled in the industry.
I believe this is a case of “correlation does not mean causation“. While these are the two most recognized third-party bug bounty programs around, there are many variables at play here. In the bigger picture, shifts in these programs do not necessarily mean anything. Some of the factors that may have influenced disclosure numbers for those two programs include:
- There are more bug bounty programs available. Some may offer better price or incentive for disclosing through them, stealing business from iDefense/ZDI.
- Both companies have enjoyed their share of internal politics that affected at least one program. In 2012, several people involved in the ZDI program left the company to form their startup. It has been theorized that since their departure, ZDI has not built the team back up and that disclosures were affected as a result.
- ZDI had a small bout of external politics, in which one of their most prevalent bounty collectors (Luigi Auriemma) had a serious disagreement about ZDI’s handling of a vulnerability, as relates to Portnoy and Exodus. Auriemma’s shift to disclose via his own company would dramatically affect ZDI disclosure totals alone.
- Both of these companies have a moving list of software that they offer a bounty on. As it changes, it may result in spikes of disclosures via their programs.
Regardless, iDefense and ZDI represent a small percentage of overall disclosures, it is curious that Frei opted to focus on this so prominently as a reason for vulnerability trends changing without considering some influencing factors. Even during a good year, 2011 for example, iDefense (42) and ZDI (297) together accounted for 339 out of 7,565 vulnerabilities, only ~ 4.5% of the overall disclosures. There are many other trends that could just as easily explain relatively small shifts in disclosure totals. When making statements about trends in vulnerability disclosure and how it affects statistics, it isn’t something that should be done by casual observers. They simply miss a lot of the low-level details you glean on the day-to-day vulnerability handling and cataloging.
To be clear, I am not against using CVE/NVD data to generate statistics. However, when doing so, it is important that the dataset be explained and qualified before going into analysis. The perception and definition of what “a vulnerability” is changes based on the person or VDB. In vulnerability statistics, not all vulnerabilities are created equal.
Everything is Vulnerable – Even Security Software!
A week ago, I read an interesting blog post by Jeremiah Grossman of WhiteHat Security titled: “201x: The Year of the Security Industry Breach”, which discussed that security software may be the next big target for attackers to focus on
Some great points are presented and I especially appreciate how the fact is hammered in that attackers shift focus whenever required, but as Jericho pointed out when we discussed it, “The security industry does not.” I find, however, that the blog post lacking a couple of key points, which caused me to write this follow-up (not a rebuttal – Jericho handles those).
I agree that we have for decades been offered the same solution to all our security problems: Buy more/newer/subscription security software to deal with the threats. It is also certainly installed in abundance.
Security software does present problems however, and these concerns are not new. Researchers have voiced concerns for years over security software like firewalls and especially anti-virus (AV), pointing out that businesses are adding more (potentially flawed) code to protect themselves. It’s a common rule of thumb that the more lines of code, the more vulnerabilities. Reducing attack surface by adding an even greater attack surface is a paradox.
While security software in general presents an interesting target, it does, however, not necessarily mean that we will see it receiving the same heavy abuse as Java, Internet Explorer, and Flash, which are currently getting hammered by the bad guys.
When the bad guys were exploiting vulnerabilities in Adobe Reader, they were not targeting PDF viewers overall; they did not really care about e.g. Foxit Reader, PDF-XChange, nor Sumatra PDF. When Microsoft Office was hot, other office suites like OpenOffice and Corel Office did not feel the burn. And when 0-days are being dropped in Internet Explorer, browsers like Firefox, Opera, and Chrome can relax (relatively speaking) on the side.
These other products are not necessarily going free or only receiving limited attention because they are safer – they may just not have a user base that results in a profitable ROI.
If history is permitted to serve as a pointer, the bad guys do not target a whole class of products, but generally specific products with an extremely high user base allowing widespread attacks. It would, therefore, be more likely to see attacks focusing on products from a specific security vendor. That would, however, require a strong position with the vendor’s products being installed on a very large scale and while security software is prevalent, no single vendor dominates the market – especially not with a single product.
Another option would be if the security products start using the same codebase e.g. for file parsing or other common routines. Should security software e.g. use the same third-party parsing functionality, these parsers would certainly become of greater interest.
It should also be noted that while security software has not been targeted by the bad guys in the same manner as the previously mentioned products (and currently for good reason), it has still received a fair amount of attention over the years from researchers (myself included).
Looking at the OSVDB vulnerability database, it has at the time of writing 1,919 entries covering vulnerabilities in security software – in fact almost 2% of all our entries (yes, we have a specific classification flag, making it very easy to get a historical overview). These span from 2013 all the way back to 1995, when security software started gaining a foothold. I specifically remember when Alex Wheeler in 2005 was doing some serious work on the archive parsing functionality of many security software vendors’ AV solutions.
For the past 5-6 years, Symantec has also had their worries because they decided to implement very flawed parsers from HP/Autonomy/Verity Keyview in some of their security solutions, including their Mail Security and Data Loss Prevention products. Or Microsoft who on a related note made the questionable decision of implementing Oracle Outside In parsers in Microsoft Exchange Server 2007 and 2010. A vendor with a history of vulnerabilities, that they have worked very hard to overcome, deciding to implement a more notoriously insecure vendor’s software is certainly interesting.
Does this mean we won’t see any focus on security software in the future? Certainly not. Security software exposes a broad and tantalizing attack surface and is not necessarily built to impress (as Tavis Ormandy recently demonstrated for Sophos’ security solutions). It is an interesting target class of products that will continue to receive attention – and perhaps even an increasing focus once Oracle eventually sorts out Java, though that may take a while.
When the going gets tough, attackers just change to a different target with a better ROI, and it cannot be ruled out that the target ends up being the code actually intended to protect you.
So remember that 201x is already here and that while the bad guys may not go all-in against security solutions, vulnerabilities in these have been found consistently for many years. Consider what security software you really need – and certainly which features you need enabled.
Researcher Security Advisory Writing Guidelines
Researcher Security Advisory Writing Guidelines
Open Security Foundation / OSVDB.org
moderators at osvdb.org
This document has been prepared by the Open Security Foundation (OSF) to assist security researchers in working with vendors and creating advisories. Security advisories help convey important information to the community, regardless of your goals or intentions. While you may have an intended audience in mind as you write an advisory, they will not be the only ones to read it. There is a lot of information that can be included in a properly written advisory, and leaving any out makes your advisory something less than it could be.
The OSF encourages researchers to use this document as a guideline for writing security advisories. We will focus on the content of the advisory, not the style. While there is a logical order of presentation, what ultimately matters is including the necessary information, though some things are most beneficial at the start of an advisory. Remember; more information is better, and including information for other parties ultimately helps more people.
How you disclose a vulnerability is your choice. The debate about “responsible” or “coordinated” disclosure has raged for over two decades. There is no universal accord on what is an appropriate period of time for a vendor to reply to a vulnerability report, or fix the issue, though it is generally agreed that it is at the least more than a day and less than a year. Researchers, we fully encourage you to work with vendors and coordinate disclosure if possible; your goal is to improve security after all, right? The following material will give you additional information and considerations for this process.
Brian Martin & Daniel Moeller
Advisories != Vulnerabilities, and How It Affects Statistics
I’ve written about the various problems with generating vulnerability statistics in the past. There are countless factors that contribute to, or skew vulnerability stats. This is an ongoing problem for many reasons. First, important numbers are thrown around in the media and taken as gospel, creating varying degrees of bias in administrators and owners. Second, these stats are rarely explained to show how they were derived. In short, no one shows their work, shows potential bias, caveats, or other issues that should be included as a responsible security professional. A recent article has highlighted this problem again. To better show why vulnerability stats are messy, but important, I will show you how it is trivial to skew numbers simply by using different criteria, along with several pitfalls that must be factored into any set of stats you generate. The fun part is that the word used to describe the differences can be equally nebulous and they are all valid, if properly disclaimed!
I noticed a Tweet from @SCMagazine about an article titled “The ghosts of Microsoft: Patch, present and future”. The article is by Alex Horan, security strategist, CORE Security and discusses Microsoft’s vulnerabilities this year. Reading down, the first line of the second paragraph immediately struck me as being incorrect.
Based on my count, there were 83 vulnerabilities announced by Microsoft over the past year. This averages out to a little more than six per month, a reasonable number of patches (and reboots) to apply to your systems over the course of a year.
It is difficult to tell if Horan means “vulnerabilities” or “patches”, as he appears to use the same word to mean both, when they are quite different. The use of ’83′ makes it very clear, Horan is referencing Microsoft advisories, not vulnerabilities. This is an important distinction as a single advisory can contain multiple vulnerabilities.
A cursory look at the data in OSVDB showed there were closer to 170 vulnerabilities verified by Microsoft in 2012. Doing a search to include references for “MS12″ (used in their advisory designation), 160 results. This is how it was easy to determine the number Horan used was inaccurate, or his wording was. If you generate statistics based on advisories versus independent vulnerabilities, results will vary greatly. To add a third perspective, we must also consider the total number of disclosed vulnerabilities in Microsoft products. This means ones that did not correspond to a Microsoft advisory (e.g. perhaps a KB only), did not receive a CVE designation, or were missed completely by the company. On Twitter, Space Rogue (@spacerog) asked about severity breakdowns over the last few years. Since that would take considerable time to generate, I am going to stay focused on 2012 as it demonstrates the issues. Hopefully this will give him a few numbers though!
If we look at the 2012 Microsoft advisories versus 2012 Microsoft CVE versus 2012 Microsoft total vulnerabilities, and do a percentage breakdown by severity, you can see heavy bias. We will use the following breakdown of CVSS scores to determine severity: 9 – 10 = critical, 7 – 8.9 = important, 4 – 6.9 = moderate, 0 – 3.9 = low.
| Base Source | Critical | Important | Moderate | Low |
| 2012 Advisories (83) | 35 (42.2%) | 46 (55.4%) | 2 (2.4%) | – |
| 2012 CVE (160) | 100 (62.5%) | 18 (11.3%) | 39 (24.4%) | 3 (1.8%) |
| 2012 Total (176) | 101 (57.4%) | 19 (10.8%) | 41 (23.3%) | 15 (8.5%) |
It isn’t easy to see the big shifts in totals in a chart, but it is important to establish the numbers involved when displaying any type of chart or visual representation. If we look at those three breakdowns using simple pie charts, the shifts become much more apparent:
The visual jump in critical vulnerabilities from the first to the second two charts is distinct. In addition, notice the jump from the first two charts to the third in regards to the low severity vulnerabilities and that they didn’t even make an appearance on the first chart. This is a simple example of how the “same” vulnerabilities can be represented, based on terminology and the source of data. If you want to get pedantic, there are additional considerations that must be factored into these vulnerabilities.
In no particular order, these are other points that should not only be considered, but disclaimed in any presentation of the data above. While it may seem minor, at least one of these points could further skew vulnerability counts and severity distribution.
- MS12-080 Only contains 1 CVE if you look at immediate identifiers, but also contains 2 more CVE in the fine print related to Oracle Outside In, which is used by the products listed in the advisory.
- MS12-058 actually has no immediate CVEs! If you read the fine print, it actually covers 13 vulnerabilities. Again, these are vulnerabilities in Oracle Outside In, which is used in some Microsoft products.
- Of the 176 Microsoft vulnerabilities in 2012, as tracked by OSVDB, 10 do not have CVE identifiers assigned.
- OSVDB 83750 may or may not be a vulnerability, as it is based on a Microsoft KB with uncertain wording. Vague vulnerability disclosures can skew statistics.
- Most of these CVSS scores are taken from the National Vulnerability Database (NVD). NVD outsources CVSS score generation to junior analysts from a large consulting firm. Just as we occasionally have mistakes in our CVSS scores, so does NVD. Overall, the number of scores that have serious errors are low, but they can still introduce a level of error into statistics.
- One of the vulnerabilities (OSVDB 88774 / CVE-2012-4792) has no formal Microsoft advisory, because it is a 0-day that was just discovered two days ago. There will almost certainly be a formal Microsoft advisory in January 2013 that covers it. This highlights a big problem with using vendor advisories for any statistic generation. Vendors generally release advisories when their investigation of the issue has completed, and a formal solution is made available. Generating statistics or graphics off the same vulnerabilities, but using disclosure versus solution date will give two different results.
These are just a few ways that statistics can be manipulated, often by accident, and why presenting as much data and explanation is beneficial to everyone. I certainly hope that SCMagazine and/or CORE will issue a small correction or explanation as to the what the “83″ number really represents.
2012 End of the Year Updates
We had the best intentions to post more frequently on this blog but haven’t had an update since August. While we would have loved to post more frequently, quiet on the blog is actually of great benefit to you. Every minute we don’t update here, we’re updating the database and adding more vulnerability information. On top of adding new vulnerabilities every day (including X-mas!), we typically update between 100 and 400 existing entries with new references, updated solution information, and more. Anyone monitoring vulnerability disclosure sources know the number of new vulnerabilities are approaching crazy. Some of the other changes and news:
Even after doing server upgrades to handle increased traffic we have still been experiencing some site availability issues. After doing more research, it appears that this is due to an absolutely incredible amount of hits on the web site, primarily from automated scrapers. We are currently testing various technical solutions to help ensure this doesn’t affect site availability. Please note that customers of Risk Based Security (RBS), who we have partnered with for vulnerability intelligence, are not affected by any of these hiccups. For companies that rely on timely vulnerability data delivered in a standard format and are tired of trying to keep up on their own (or tired of their current provider delivering sub-par information), send an inquiry to RBS to discuss the numerous services available.
The Open Security Foundation, and thus OSVDB, has recently gained a new sponsor, High-Tech Bridge. In addition, both Jake Kouns and Brian Martin have joined HTB’s advisory board to give advice and recommendations on further developing and driving their vulnerability research efforts. HTB has spent a considerable amount of time not only performing pro bono research for open source projects, but they have put serious effort into ensuring their research and advisories are at the top of the industry.
Risk Based Security has also been funding the day-to-day import of vulnerability data by sponsoring 2 full time employees, 1 part-time employee, and lending out Carsten Eiram to assist us with problematic entries (e.g. vague disclosures). Carsten is also using his experience with VDB management and vulnerability research to help OSVDB refine our templates, enhance our title scheme to be more descriptive, and provide guidance in moving forward.
Finally, we’d like to give a big shout out to several vendors that go above and beyond. Another ‘behind the scenes’ thing we do is frequently pester vendors for more information about third-party disclosures. We often ask for additional details for exploitation, solution information, and clarification if there is anything left to question. In the past month, there have been several times where our mail was answered incredibly fast that answered all of our questions. This includes a day-long thread on a Sunday that included Foswiki and TWiki, replies from the Microsoft Security Response Center (MSRC) on Christmas day (about 5+ year old CVE assignment questions), and quick responses from Mozilla, Cisco Security, and Symantec’s Security Response team. We can’t emphasize how much we appreciate their attention to these questions, as it ultimately helps their customers and ours.
As always, we encourage you to follow us on Twitter (@OSVDB), for news, quips, and status updates about vulnerabilities.
Fascinating Vulnerability and Glimpse Into 33 Year Old Pen-Testing
Today, we pushed OSVDB 82447 which covers a backdoor in the Multics Operating System. For those not familiar with this old OS, there is an entire domain covering the fascinating history behind the development of Multics. OSVDB 82447 is titled “Multics Unspecified Third-party Backdoor” and gives an interesting insight into backdoors distributed by vendors. In this case, a third-party planted it, told the vendor, and Honeywell still distributed the operating system anyway. I encourage you to read the full paper by Lieutenant Colonel Roger R. Schell, a member of the tiger team that carried out the attack.
To summarize;
During a US Air Force sanctioned penetration test of mainframe computers, sometime before 1979, the tiger team ended up penetrating a Multics installation at Honeywell. In an account of what happened later, a paper said that the tiger team “modified the manufacturer’s master copy of the Multics operating system itself” and injected a backdoor. The backdoor code was described as being small, “fewer than 10 instructions out of 100,000″ and required a password for use. The report continues, saying that even though Honeywell was told it was there and how it worked, their technicians could not find it. Subsequently, the backdoor was distributed in future installations of Multics.
It would be interesting to know why Honeywell didn’t ask for, or didn’t receive, the specific modified code from the Air Force tiger team, and why they opted to distribute it to customers. Perhaps they thought if their own technicians couldn’t find the backdoor, no one else could. Even more interesting is why a tiger team was sanctioned to carry out a penetration test that not only gave them access to the “master copy” of Multics, but why they were allowed to actually place the backdoor there. When they heard Honeywell couldn’t find it, why didn’t they insist on ensuring it was removed before installation at customer locations? This brings a new twist to the ethics of penetration testing, at least in a historical context.
We’re Still Here – Update on OSVDB Project: Data and Exports
At a glance, it may appear as if the OSVDB project has fallen by the wayside. Some of our public facing pages have not been updated in several years, the last string of blog posts was over a year ago, and a recent update caused a few functions to fail (e.g., data exports). On the other hand, anyone paying attention to the data has noticed we are certainly present and moving forward. We have had one person working full time on OSVDB for over a year now. He is responsible for the daily push of new vulnerabilities and is scouring additional sources for vulnerabilities that didn’t appear through the normal channels. Given the nature of the project, we place data completeness and integrity as the top priority.
The OSVDB project is coming up on its tenth year anniversary. The last ten years have seen some big changes, as well as many things that have not changed one bit. The biggest thing that hasn’t changed is the lack of support we receive from the community. The top ten all time contributors are the core members of OSF, the handful of longstanding dedicated volunteers we have had over the years, or some people we have been able to pay to help work on the project. Beyond those ten people, the volunteer support we lobbied for years never materialized. We still enjoy a couple dozen volunteers that primarily mangle their own disclosures, or add CVE references, which we appreciate greatly. Unfortunately, the rate of vulnerability disclosures demands a lot more time and attention. In addition to the lack of volunteers, community support in the form of sponsorship and donations has been minimal at best. Tenable Network Security and Layered Technologies have been with us for many years and have largely been responsible for our ability to keep up with the incoming data.
Other than those two generous companies, we have had a few other sponsors/donations over the years but nothing consistent. In the last year, we have spent most of our time trying to convince companies that are using our data in violation of our posted license to come clean and support our project. In a few cases, these companies have have built full products and services that are entirely based on our data. In other cases, companies use our data for presentations, marketing, customer reports, and more while trying to sell their products and services. Regardless, the one thing they aren’t doing is supporting the project by helping to update data, properly licensing the data or at least throwing us a few bucks as an apology. In short, several security companies, both new and well established, that sell integrity in one form or another, appear to have little integrity of their own. After a recent server upgrade broke our data export functionality, it was amazing to see the number of companies that came out of the woodwork complaining about the lack of exports. Some of them were presumptuous and demanding, as if it is a Constitutional right to have unfettered access to our data. Because of these mails, and because none of these companies want to license our data, we are in no hurry to fix the data exports. In short, they don’t get to profit heavily off the work of our small group of volunteers, many of whom are no longer with us.
Even as an officer of OSF and data manager of OSVDB, I honestly couldn’t tell you how we have survived this long as a project. I can tell you that it involved a lot of personal time, limping along, and the hardcore dedication of less than a dozen individuals over ten years that made it happen. With almost no income and no swarm of volunteers, the project simply isn’t sustainable moving forward, while still maintaining our high standards for data quality. We gave the community ten years to adopt us, and many did. Unfortunately, they largely did it in a completely self serving manner that did not contribute back to the project. That will be ending shortly. In the coming months, there will be big changes to the project as we are forced to shift to a model that allows us to not only make the project sustainable, but push for the evolution we have been preaching about for years. This will involve making the project less open in some aspects, such as our data exports, and has required us to seek a partnership to financially support our efforts.
For ten years we have had a passion for making OSVDB work in an open and free manner. Unfortunately, the rest of the community did not have the same passion and these changes have become a necessity. The upside to all of this is that our recent partnership has allowed us to develop and we will be offering a subscription data feed that has better vulnerability coverage than other solutions, at a considerably better price point. That said, the data will remain open via HTTP and for a 99% of our users this is all that is required. When exports are fixed, we will offer a free export to support the community, but approval will be required and it will contain a limited set of fields for each entry. We are still working out the details and considering a variety of ideas to better support a wide range of interest in the project, but doing so in a sustainable manner. In the end, our new model will help us greatly improve the data we make available, free or otherwise and ensure OSVDB is around for the next 10 years.
