By Jeff Williams, Co-Founder, Chief Technology Officer
June 18, 2014
This week, the fourth annual Open Source Development and Application Security Survey was released. The 3,353 software developers surveyed divulged the eye-opening realities of their open source usage and application security practices. Our partner Sonatype spearheaded this annual survey, co-sponsored by Contrast Security, Rugged Software, NEA, and the Trusted Software Alliance. The fact that Sonatype’s founder built Maven, the most widely used build automation tool out there, as well as the Nexus repository manager, used by over 40,000 organizations for storing and organizing software components, puts Sonatype in a unique position for compiling the survey’s insights.
Open source library usage from the Central Repository has exploded from 8 billion component requests in 2012 to 13 billion in 2013, forever changing the way software is developed. When using open source, developers take a leap of faith relying on the integrity of the code that’s been produced and offered for others to use.
When you’re talking billions of lines of code, it’s impossible to review it all for mistakes. It’s a haystack full of needles. That’s what made the Heartbleed security bug so pervasive. One piece of open source code had a bad vulnerability and it was used quite widely. Because everyone trusted the code, everyone became vulnerable. There will be many other Heartbleed-style vulnerabilities discovered in components in the coming months and years.
The recent Heartbleed fiasco demonstrates two separate problems with securing component use. The first problem is relatively simple. Once you know that a library has a vulnerability, you need to update it with the latest patched version. This is basic patch management, but it is relatively new for the application layer. Contrast includes real time analysis to keep development teams up-to-date on insecure component use across your application portfolio.
The second problem is much more insidious. Libraries are complex and powerful – that’s why they are so popular. But along with that power comes great responsibility to use them safely (apologies to Ben Parker). For example, if you pass an untrusted XML document that you received from a user into a component for parsing XML, you very likely introduced an XML External Entity (XXE) vulnerability. You need to turn off doctype support in your parser before handling untrusted documents. Contrast is unique in identifying these previously unknown security problems that span your custom code and components.
The simple fact is that developers need instantaneous feedback on the security of the code they are writing. That’s why Contrast runs continuously and in real-time – without having to schedule a scan or triage the results. Contrast can analyze third-party application code and frameworks, even if you don’t have access to the source code. (That’s a huge advantage over static tools that require the source code and don’t analyze components.)
Applications are the #1 breach vector of hackers. Let’s look at the survey insights (in italics) as they relate to Contrast Security’s capabilities:
Enter Contrast Security. Contrast is not a scanner – our agent enables applications to self-test their own security. You don’t have to be a security expert to use it. Contrast lets developers be developers; it teaches you security as you code so you don’t make the same mistakes over and over again. Contrast also allows executives visibility into application security across their entire application portfolio, enabling strategic investments and better decisions.
Watch the replay of the June 18, 2014 webinar on the complete survey findings, detailed analysis and best practice recommendations.
Click below to download the full infographic
Perhaps, all it takes is rethinking your existing program and moving to one that leverages a continuous application security (CAS) approach. Organizations practicing CAS quickly determine how a new risk affects them, design a defense strategy, and measure their progress to 100% coverage. By implementing eight functions within an enterprise you can assemble an effective application security program.
Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.
Get the latest content from Contrast directly to your mailbox. By subscribing, you will stay up to date with all the latest and greatest from Contrast.