“Cyber security is on the national political agenda, but do we really understand what it takes to be secure? Now that enterprise development has become component based, rather than using custom code running off-the-shelf platforms, it’s time for enterprise development to wake up and smell the black hats. They’re targeting your components, not just your servers.” 

Simon references our recent survey of 3500 developers, managers and architects that use open source software and our findings about the prevalence of OSS components. Things like:

• Applications are made up of at least 80% components
• Vast majority of organizations have not control over the components they use
• Developers don’t focus much on security

His quote sums up the fact that applications are the predominant threat vector, and with the recent data that today’s applications primarily consist of components it should be no surprise that components can be a significant threat. Why? Well it comes down to economy of scale. If the hacker can exploit a single component, and that component is used in hundreds or thousands of independent applications, hmmm check and mate.

In another article on InfoWorld, Simon addresses Oracle’s approach to Java stating “Oracle’s closed approach keeps Java at risk”. I’m drawn to his comments comparing whether proprietary or open source software (in this case Java) poses a greater risk. This type of editorial has been going on for years – debating the merits of the “many eyes” theory. He also discusses how technical debt in proprietary systems is a more significant issue than can be found in open source. While I understand (though I don’t agree with his thoughts), I think there is a bigger problem here. Since applications are constructed from components sourced from many locations, organizations need to treat software security using supply chain principles. Components of all types need to be managed: internally developed components, open source components, shrink-wrap (COTS), cloud services, you name it.

The issues that are coming to light with Java may vary in technical detail, but their impact is similar to the pervasiveness of Windows ActiveX controls, Adobe PDF files, or other technologies. For those of you old enough to remember, think about the rampant issues found in UNIX’s open source Sendmail program. The point being, this is not an open source vs. closed source debate, this is an application security problem that is rampant across all communities.

Personally I am glad that Oracle is starting to step up to the plate and address these issues head on, but let’s not fault the fact that not all Java is open source. And let’s not lead people to believe that by making a project open source, that security is automatically improved. While there are lots of security stars in the open source community, there are plenty of black holes. As a security community, we need to promote better security practices across all development efforts and avoid generalizations that marginalize any one approach.

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.  

• An overwhelming 86 percent of you stated that your applications are at least 80 percent open source with the remaining 20 percent custom components and code.

Organizations are reacting to this trend by providing development infrastructure that is designed to leverage open source components and frameworks (e.g., Maven, Hudson/Jenkins, Eclipse, Git, Nexus, etc.):

• 53% noted that they are standardizing on an open source development infrastructure stack.

But given the explosive growth in component usage – 8 billion downloads from the Sonatype Central Repository in 2012 represents an 800% increase in activity since its inception – it comes as no surprise that organizations are struggling to keep up:

• 76% of large organizations have no control over what components are being used in software development projects
• 65% don’t maintain an inventory of components used in production applications.

And since development is under extreme pressure to deliver applications fast while budgets are being cut, it’s also not surprising to see security taking a back seat:

• More than half of large organizations shared that developers don’t focus on security at all.

The good news is that Nexus users have a natural path to address these shortcomings – a strategy that we call Component Lifecycle Management. And we will soon launch a community relating to Good Component Practice.

But, lets’ get back to the survey.

The survey results are also available in pdf format here.

Let us know what you think about the results. What did you find surprising? What actions will you take?

And check back with us to continue the dialogue and to learn more about best practice approaches for managing your components.

We’re making SSL connectivity to Central available to anyone that downloads open source components regardless of the repository manager. Given the tremendous growth of Central, and the fact that modern applications are largely built from OSS components, this capability is likely to be leveraged by many organizations. SSL has become the standard mechanism for protecting web traffic – across the spectrum of Ecommerce, banking, health care, and so on. Providing SSL support for Central means that your components are no longer susceptible to man-in-the-middle attacks that could compromise the component. SSL also eliminates the potential for a hacker to gain visibility into your organization by tracking the components that you download for your development initiatives.

As of Nexus Pro 2.2 (available now), SSL is now the default connectivity option for Nexus Pro users. Because we take security of the ecosystem seriously, we aren’t stopping there, we’re making SSL connectivity to Central available to you even if you aren’t using Nexus Pro.

In order to ensure the highest level of performance for those who count on SSL, we are securing the service with a token. You can get a token for your organization simply by providing a $10 donation that will be donated to open source causes. For the first 60 days all donations will go to the Apache Software Foundation. After that, the donations will go to other open source foundations such as Eclipse. Sonatype will provide a donation on behalf of Nexus Pro customers since we’ve included SSL access to all Pro customers automatically.

If you happen to be using Nexus OSS (any version), support for the SSL token is included already. I’ve already reached out to the Artifactory and Archiva teams and they are working on the changes necessary to enable SSL to Central – we’ll let you know when that support is enabled. If you’re not using a repository manager at all, what are you waiting for?

If you are an existing Nexus Pro customer, you can download the latest release from the support page.

If you would like to make a donation to the open source community and get SSL access, you may do so here.

“The new Android malware disguises itself in fully functional copies of apps, including ―Angry Birds Space,∥ and hides its malicious payload in the string of code at the end of an otherwise genuine JPEG file, Lookout said. This rogue code exploits the GingerBreak vulnerability, a flaw that enables it to gain control of the phone and trick the victim into purchasing apps from illegitimate app stores.”

It looks like Android developers need to start paying more attention to security in general now that Android has exceeded 50% market share in the US market. While this vulnerability isn’t something that is directly addressable with Insight at the moment, but it reminds us that we need to start focusing more on mobile. Since Android development is Java-based, you can immediately benefit from downloading Nexus Professional 2.0 today and making sure that all of your application dependencies are free of known vulnerabilities.

Note: This post references our Security Feed. We maintain a feed of security stories relevant to developers which is isolated from our main blog feed. If you are interested in getting the full feed, read it here.

Penetration testing experts use a tool like Havij: An Advanced SQL Injection Tool. It’s a nice friendly GUI designed to make it easy to “own” an application. Point, click, and compromise. Well, even though the project itself has nothing to do with evil, Cybercriminals are having a love affair with Havij.

My advice: download this tool and get to know it. Start your own love affair with Havij before the bad guys start throwing errant quotes into your form fields. Also don’t think that enterprise languages like Java or .NET are invulnerable to SQL injection attacks. To avoid these attacks, here’s some quick advice:

• Never trust input directly from an HTTP parameter.
• Use some web framework like Tapestry, GWT, or Struts, and make sure that all user input passes through whatever mechanism it is using for input processing and validation. It is very likely that the framework is built to resist SQL injection.
• Use a good ORM or persistence library like iBatis or Hibernate. Again these are just more layers to make sure that your input isn’t going straight into a SQL statement.
• Use Nexus 2.0 Repository Health Check to make sure that your web frameworks and persistence frameworks are up to date.

Note: This post references our Security Feed. We maintain a feed of security stories relevant to developers which is isolated from our main blog feed. If you are interested in getting the full feed, read it here.

In case you missed it there is a vulnerability in Apple’s version of Java that is fueling the rise of what people are calling the Flashback botnet. According to this Computerworld article, this OSX Flashback botnet is at least 600,000 computers strong and the latest variants of the attack “do not require user intervention”. The advice to fix this Mac vulnerability? Last week a Register article stated that “F-Secure advises users to disable Java, which is not needed to visit the vast majority of Web sites, on their Mac.” Right….. disable Java. Something tells me that’s not effective advice for this developer audience.

If you want to protect yourself, follow Apple’s instructions and upgrade Java. If you are running OSX Leopard or earlier, you are out of luck and you should probably either disable Java or upgrade (really, isn’t it time for an upgrade anyway?). This upgrade from Apple will also remove installed malware if you’ve been compromised. Conclusion: Java developers, all of your OSX machines are belong to Flashback. Upgrade now.

Note: This post references our Security Feed. We maintain a feed of security stories relevant to developers which is isolated from our main blog feed. If you are interested in getting the full feed, read it here.

Sonatype’s Charles Gold has just published an article in the ISACA Journal: “Mitigating the Risk of OSS Software”. Here’s an excerpt from his ISACA blog discussing the article:

“[I]t has been reported that up to 80 percent of custom software code created today is assembled from open-source components. Upon closer examination, we see a software supply chain that lacks visibility and control and carries with it some glaring risks. While the industry has been quick to embrace open source for its rapid innovation and its undisputed acquisition cost benefits, it has largely ignored a fundamental problem: there is no update notification infrastructure for open-source components.”

If you are a member of a ISACA, you can read this article in the current issue (Volume 2, 2012) of the Journal. In the full article Gold defines the challenges and risks associated with unmanaged OSS consumption and then defines a series of recommended steps you can take to mitigate these risks.

Gold’s article raises awareness of application-level security within the context of OSS-consumption. Here are two interesting excerpts from the article. The first talks about the disconnect between US-CERT security vulnerabilities and the consumption of artifacts from Central:

“Even when security warnings are posted and easily accessible, they are often overlooked. In March 2009, the US Computer Emergency Readiness Team (US-CERT) and the US National Figure 2—Transitive Dependencies Make It Difficult to Govern Component Usage Institute of Standards and Technology (NIST) issued a warning that the Legion of the Bouncy Castle Java Cryptography API artifact was extremely vulnerable to remote attacks. In January 2011, almost two years later, 1,651 different organizations downloaded the vulnerable version of the artifact from the Central Repository within a single month.”

And, the second addresses the problem of assessing exposure to OSS licenses:

“cutting through the complexity of acquiring and evaluating external components and the associated legal obligations can be difficult and time-consuming. There are multiple types of open-source licenses, each with different terms and conditions that must be met.”

If you are consuming OSS without paying attention to some of the critical issues outlined in this article, you can start today by downloading a trial of Nexus Professional. With Nexus Professional’s Repository Health Check you can keep track of your exposure to both security vulnerabilities and OSS licenses.

Thank you to all of you who contributed your thoughts about your tooling, the components you use, and your organizations’ open source policies (and how you feel about them).    There results are extremely interesting.

Take a look for yourself  (best viewed in  ‘full screen’ mode), let us know what you think, and share with your friends and colleagues.

For those of you who would prefer our survey results as a PDF, here they are: Sonatype Survey Findings

To improve the experience for users in Europe, Sonatype has provisioned a new official repository in the United Kingdom. This is more than a mere mirror of Central, this system is updated in lockstep with the systems here in the US, and is managed and monitored 24×7 by Contegix, the same team watching over the US repositories. The new repository consists of two fully redundant systems running in parallel to provide complete fail-over capacity.

In addition to the new repository, we have taken several steps to improve and further secure Central itself:

• A new system has replaced Central as the inbound processing engine. On this staging system, we can now vet inbound artifacts for quality and other parameters before publishing them to repo1 and Europe. It also serves as a hot standby for the US repository.
• We’ve worked with Contegix to implement additional layered security around the repository machines themselves.
• There is a new Jira project to manage any and all concerns and issues with Central, the Mirrors, Content, etc
• We are working to setup another official Central Repository in Asia soon

The new repository is live at http://uk.maven.org/maven2/ if you’re using a repository manager, just replace references to http://repo1.maven.org/maven2 with the new url. If you’re not, you should be (Whitepapers: Intro to Repository Management / Stages of Repository Adoption), but until you get a repository manager in place, add the following to your settings.xml:

<mirrors> <mirror> <id>uk</id> <mirrorOf>central</mirrorOf> <url>http://uk.maven.org/maven2/</url> </mirror> </mirrors>

Some additional coverage on this topic can be seen at InfoWorld, BusinessWire and InfoQ