Jeff Williams, CEO of Aspect Security and founding member of OWASP puts a fine point on the challenge…

• “The performance, time and cost advantages of agile, open-source development comes at a price – you have to ensure the components you use are up-to-date and secure.”
• “Unfortunately, it’s not trivial to figure out what components your applications are using, and even harder to figure out which vulnerabilities apply to those components.”
• “The new OWASP Top Ten has detailed recommendations for locking down your software supply chain, and Sonatype’s tools make them much easier.”

So why should managing and securing components be a priority? Simply put, components have become a rich attack vector because of their pervasive reuse. Reuse that makes it easy for hackers to propagate their attack across multiple applications and organizations.

OWASP provides a set of best practice recommendations, including:

1. Identify the components and their versions you are using, including all dependencies.
2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.
3. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable license.

Sonatype CLM goes beyond these recommendations and is designed to manage the entire component lifecycle. The CLM integrates security, licensing and quality information about the components directly in the tools that developers use (repository manager, IDE, build/CI environment), provides early and quick remediation capabilities, and continuously monitors your production applications.

For more information on recommended best practices, check out the 7 steps to Good Component Practice section (it’s at the end) of the 2013 Sonatype Survey results.

You can also check out the press release announcing OWASP A9.  

Have Jenkins (or Hudson) up and running, and want to give Insight for CI plugin a try? The plugin is available in the plugin center and easy to install and configure. — Just add a post build step and configure it to scan (e.g. your build output war file). Get the plugin.

Summary and component results are completely free and will give you a very good indication of the security and license issues (or better their absence) of your software. We’ve even got you covered for manual scans – have a try with Insight App Health Check.

You remember Outlook, maybe some of you are unlucky enough to still use Outlook, but for Microsoft, Outlook was a multi-year security embarrasment. From 1999 to around 2005 it felt like Outlook was having a security vulnerability every other minute. Back then, there were so many that, in technical circles, Outlook became something of a joke to anyone who valued security. In fact, you could make a compelling argument that Outlook’s multi-year security challenges were the weak point in the armor that provided an opening to Google’s GMail (and once you’ve decoupled from Outlook, why not try that Macbook Pro you’ve been eyeing).

If this trend in Java doesn’t stop – if we don’t stop experiencing billion-user, level 10 CVSS security exploits every other week in Java – all the inertia in the world won’t stop a shift to another language or another platform. Check out this news that just crossed the wire yesterday from Softpedia:

One billion users affected by Java security sandbox bypass vulnerability, experts say. Researchers from Security Explorations claimed to identify a flaw that affects all Oracle Java SE versions and the billions of devices on which the software is currently installed. This bug, codenamed issue 50, was identified just before the start of Oracle’s JavaOne 2012 conference. ―The impact of this issue is critical — we were able to successfully exploit it and achieve a complete Java security sandbox bypass in the environment of Java SE 5, 6 and 7,‖ the CEO of Security Explorations said. He said the vulnerability can be leveraged by an attacker to ―violate a fundamental security constraint‖ of Java Virtual Machines. The researchers confirmed Java SE 5 — Update 22, Java SE 6 — Update 35, and Java SE 7 Update 7 running on fully patched Windows 7 32-bit operating systems are susceptible to the attack. The affected Web browsers are Safari 5.1.7, Opera 12.02, Chrome 21.0.1180.89, Firefox 15.0.1, and Internet Explorer 9.0.8112.16421. The company provided Oracle with a complete technical description of the flaw, along with source and binary codes, and a proof-of-concept that demonstrates the complete security sandbox bypass in Java SE 5, 6, and 7.”

Don’t get me wrong, Java’s going nowhere. The JVM and language are here to stay, but when I read things like “a proof-of-concept that demonstrates the complete security sandbox bypass in Java SE 5, 6, and 7″ in the following security bulletin I have to ask myself what sort of foundation we’re building our systems on? Well it isn’t a sandbox if it can be circumvented, is it?

This reminds me of a piece that Vint Cerf wrote for next month’s Communications of the ACM, in it he writes about the lack of a scientific discipline when it comes to software in “Where’s the Science in Computer Science?”. Here’s a good sample:

“When we write a piece of software, do we have the ability to predict how many mistakes we have made (that is, bugs)? Do we know how long it will take to find and fix them? Do we know how many new bugs our fixes will create? Can we say anything concrete about vulnerability? What about the probability of exploitation? Murphy’s Law suggests that if there is a bug that can be exploited for nefarious purposes, it will be.” He continues later in the piece: “…As a group of professionals devoted to the evolution, understanding, and application of software and hardware to the myriad problems, opportunities, and activities of modern society, we have a responsibility to pursue the science in computer science. We must develop better tools and much deeper understanding of the systems we invent and a far greater ability to make predictions about the behavior of these complex, connected, and interacting systems.”

My impolite translation of Cerf’s wisdom? “You are all a bunch of hacks. You couldn’t model software if your life depended on it. Maybe it’s time to start getting serious.” I’d also like to put forward that it might be time for the people responsible for the JVM to hire someone who can take the time to do it right.

If you want to start “Doing it Right” and paying attention to security start with your dependencies. If you don’t use Sonatype Insight, it’s very likely that you are downloading software components with known vulnerabilities every day. Don’t get owned by some vulnerability that’s been in the wild for months, start using Insight today.

I guess this makes sense, developers generally don’t want to have to deal with security, and me bringing up the fact that many of the systems you are working on may be vulnerable to attack isn’t something you want to think about. I understand, you have enough to worry about: looming deadlines, that junior programmer you just hired who isn’t pulling his weight, a continuing fight with operations over who “owns” the deployment process. Work is hard, there are certainly not enough hours in the day, and if you can ignore security, why not? I mean, it’s Java. Who’s going to attack Java?

AntiSec, that’s who. They aren’t just going to compromise your machines because you failed to update Java, they are going to grab your data, parade it around the world for all to see, and then make a few political statements at your expense. And, I’ll bet the FBI wishes that they had installed this February 2012 security patch from Oracle. If they had done so, they’d probably be having a much better day today.

“During the second week of March 2012, a Dell Vostro notebook, used by Supervisor Special Agent Christopher K. Stangl from FBI Regional Cyber Action Team and New York FBI Office Evidence Response Team was breached using the AtomicReferenceArray vulnerability on Java, during the shell session some files were downloaded from his Desktop folder one of them with the name of “NCFTA_iOS_devices_intel.csv” turned to be a list of 12,367,232 Apple iOS devices including Unique Device Identifiers (UDID), user names, name of device, type of device, Apple Push Notification Service tokens, zipcodes, cellphone numbers, addresses, etc. the personal details fields referring to people appears many times empty leaving the whole list incompleted on many parts. no other file on the same folder makes mention about this list or its purpose.”

This is from the AntiSEC statement regarding this breach (inappropriate language).

So what do you think is happening to the person responsible for security right now? Do you think he’s able to say, “you didn’t tell me that security was a priority?” or “It wasn’t my responsibility to check for JVM updates from Oracle?”. No, he’s likely being replaced, if not immediately then his management team is leading him on until they can identify someone who isn’t going to generate front page security failure.

What’s next? Well, the JVM is now front-and-center as far as security vulnerabilities go these days. Just last week you were all asked to turn off Java 7 until a suitable patch was issued (which is a ridiculous request BTW, that’s like asking us to stop working for a few days). I predict that as Java continues to develop as an attack vector – libraries are the next fun vulnerability. I know many of you don’t want to hear this, but it’s true. Your web frameworks are next, prepare yourself with Sonatype Insight, or start coming up with excuses when your systems are the reason for front page security fail.

What’s interesting about this Oracle patch is that Oracle’s current JDK download site isn’t yet setup to tell you why you should upgrade to 7u5. I just did the upgrade and the release notes still point back to 7u4. I had to do my own digging and find the vulnerability listed by US CERT/NVD here Vulnerability Summary for CVE-2012-0507. While this threat was from February, there’s not much information from Oracle about this particular patch. Here’s a quote from CVE-2012-0507:

“Oracle has not commented on claims from a downstream vendor and third party researchers that this issue occurs because the AtomicReferenceArray class implementation does not ensure that the array is of the Object[] type, which allows attackers to cause a denial of service (JVM crash) or bypass Java sandbox restrictions.”

Given the past few months (especially for Java users on OSX), I’d recommend that everyone reading this, stop, drop, and upgrade to the latest JDK. Happy upgrading, download the latest JDK here.

And, here’s the original story from IDG:

IDG News Service – (International) Oracle to issue 14 patches for Java SE. Oracle is planning to ship 14 patches related to Java SE June 12, including a number with the highest level of severity under the common vulnerability scoring system (CVSS) framework, according to a pre-release announcement on the company’s Web site. “Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply Critical Patch Update fixes as soon as possible,” Oracle said. The patch batch is aimed at security weaknesses in many products, including JDK and JRE 7 Update 4 and earlier; JDK and JRE 6 Update 32 and earlier; and JavaFX version 2.1 and earlier, according to the announcement. A dozen of the 14 fixes can be exploited by an attacker remotely, with no username or password required, Oracle said. A number of the weaknesses have a CVSS base score of 10.0, the highest possible, but Oracle did not provide further specifics.

Source: http://www.computerworld.com/s/article/9227909/Oracle_to_issue_14_patches_for_Java_SE

Another thing we’ve been saying is that it is our responsibility, as developers, to start paying attention to security vulnerabilities, and if we don’t take responsibility for application-level security, someone else will impose this requirement on us…

…and that’s exactly what’s we’re seeing both in the EU’s reform of Data Protection Laws and as the US Congress responds to the latest data breach at LinkedIn. Now, who knows what sort of regulations we’re going to see in the coming months, but one thing is sure, the fact that lawmakers feel compelled to act is proof that we’re not doing enough as an industry to address security.

The best security is a layered approach: multiple levels of network security, security policies for production resources that limit access to individuals that need it, secure password policies, and application security. Sonatype’s focused on that last item, application security, and our approach focuses on the components you assemble to create your applications. If you develop software today, you understand that much of your work is spent creating applications that sit atop frameworks like Spring and Hibernate. It isn’t enough for your own software and infrastructure to be secure. These days, you need to account for vulnerabilities in your dependencies.

And, again, this isn’t operation’s responsibility. Security is a shared responsibility across both development and operations. This is something that developers need to take ownership of. While we’ll probably never know how sites like LinkedIn, eHarmony, and Last.fm were compromised, there’s a good chance that some of these sites were compromised via known vulnerabilities in outdated components. Components like Tomcat or frameworks like Struts are among the list of artifacts that have known problems.

Don’t get hacked because you didn’t upgrade to the latest version of Tomcat or because you happened to be using some ancient version of Spring with a known vulnerability. If you are consuming artifacts from Central (and if you are a Java developer, you probably are), you need to start using Nexus Professional to keep track of your dependencies. If you are using Hudson or Jenkins, take some time to evaluate Insight for CI.