While that may be a catchy title, it’s also the question I've been asking attendees at SCALE and Container World over the past few weeks. More precisely, “Where would you rather get your security vulnerability information from?” Now I’m going to pause here and let that sink in for a minute. Think about it, which source do you trust more? Both are valid options and both are on the short list for many people. Made your choice? Cool, then onward!
The Myth of NIST
In my “survey,” the preferred choice was NIST-US-CERT. By a long shot, NIST won. The reason was pretty simple, NIST is trustworthy. Most people are aware of the various locations to find the NIST vulnerability information, all under the umbrella of the “National Vulnerability Database” or NVD. The problem with NIST is its latency. The NVD can be latent anywhere from a day or so up to weeks. In the case of Dirty Cow (aka CVE-2016-5195), the NVD had no meaningful information for close to three weeks. That’s a really long time for bad actors to know about something you don’t. My flippant answer to those choosing NIST was “Thank you for giving me weeks to build an attack against your infra.” Sorry guys ;)
The Allure of The Hacker News
I freely admit that I read The Hacker News, but if you’re getting your security news from it, you’ve both realized something crucial and missed an important detail. The realization comes from the fact that The Hacker News wants to be your security source. This means they’re going to grab onto a crucial security topic in a way only El Reg can aspire to. That’s cool because you’ll know about the really bad stuff soon, as in “now.” The flip side is that the mundane and arcane stuff gets passed over. Dirty Cow will get all the attention, but an issue in a minor project won’t get the same attention. That’s good in a way, because if The Hacker News dilute their feed with everything, people would become bored because the sky is always falling.
The Better Way to Get Vulnerability Information
Implicit to the question of The Hacker News vs. NIST is an assertion that a better way must exist. A few weeks back, the good folks at Forrester Research released their latest Forrester Wave for Software Composition Analysis. In it they looked at several of our competitors, and while I don’t completely agree with their methodology, they do have a reasonable set of criteria to base their opinions on. Where they missed the mark is in understanding why someone needs to understand the makeup of the software they produce, release and deploy.
Why is Software Composition So Important?
When you distill it, there are only two reasons to create a piece of software. First, you’re doing it to solve a problem you care about. Second, you’re doing it because you need to solve a problem your employer cares about. In both cases the reputation of the developer is on the line, but in the second case there is real money involved. Until a piece of software is released (or deployed), the risk associated with its composition is purely academic. Once in the hands of others, composition risk translates to dollars. Investors such as venture capitalists and private equity firms primarily want to invest in something that is reasonably unique and has high barriers to replication. They want to ensure security practices are in place that reduce risk of data breaches. Users expect you to protect their personal information.
Selecting the Correct Product and Vendor to Assess Software Risk
Selecting a security vendor is a really task. I’ve worked with some stellar organizations in the past, and some that were less so. You can look at buyers guides and analyst reports all day long, but when push comes to shove, you need to separate those committed to your success from those trying to make a buck. Here are some of the items I’d be looking at if I wanted to be confident standing in front of my board of directors explaining my software security risk management procedures.
- We didn’t select the cheapest vendor. We selected the vendor providing the best value and a vendor that would and could grow with us.
- We chose a solution that can alert us to issues before they are reported in the media. This rules out any solution that gets its data primarily from the NVD. It means we asked the vendor how many data sources they use and who their primary information partners are.
At Black Duck, we obtain our security information from over 9000 different data sources and through active monitoring of commit activity on millions of projects. This allows us to identify when impactful code changes are on the horizon.
- Our chosen vendor is investing in ways to allow them to continually reduce the window of opportunity for attack. This means they employ security researchers and are investing in security research at a pace which will ensure leadership.
Black Duck founded the Center for Open Source Research and Innovation with the express purpose of keeping open source ecosystems vibrant in the face of security challenges.
- We chose a solution that can proactively alert us to the presence of issues in our deployed software — before they become public security problems. This allows us to start planning remediation before problems hit the media.
The Black Duck Hub policy engine triggers alerts if an issue occurs in a code dependency— not just a generic piece of code.
- The vendor has an industry recognized reputation for auditing software solutions for risk items.
Last year the Black Duck On Demand team performed an average of 20 customer software audits per week. Customers requesting audits were preparing for critical business lifecycle events including new investment, IPO, merger, sale and initial product release. When the success of their organizations were at stake, they turned to Black Duck to guide them.
Black Duck Software meets these objectives nicely. If you’ve chosen an alternative open source risk management vendor or are thinking about choosing someone else, I’d encourage you to challenge them on these same points and see how they measure up. If you’re comfortable with your choice, that’s cool, but I’d hate for anyone to make a security decision based on price or UI only to find that when a security incident occurs the vendor didn’t get it right.