Tag Archives: open source

Wayne Jackson’s Presentation at RSA 2012: An Overview of Insight


April 2, 2012 By Tim O'Brien

At RSA 2012, Wayne Jackson gave a short presentation focused on the security aspects of Sonatype Insight and the newly released Repository Health Check in Nexus Professional. This five minute overview gives you a sense of the magnitude of the problem we are trying to solve.

Here are some of the highlights from Wayne’s presentation followed by the video of his talk and his slide deck:

  • “The benefits of ‘many eyeballs’ in open source does create better software but you can only leverage that if you know about it. That’s particularly troubling in the context of the fact that more than 80% of the modern software application is [comprised of] open source and the components that are used to build those applications are surprisingly complex.”
  • “That complexity is compounded by the fact that when issues arise their implications are viral and the big problem is that when those issues are resolved in the root components the solutions are not [similarly viral] . Spring Beans 2.5.6 compromised 1400 open source components and God knows how many downstream applications. When Spring Beans 2.5.6 was fixed, none of the others were fixed.”
  • “You can imagine the ripple effect of compromising open source. And the combination of things like the lack of notification infrastructure and the complexity of open source componentry is how you get situations like this. 6,982 organizations including the Dept of Homeland Security and several financial institutions are still using a 3 year old crypto library with an “as bad as it gets” Level 10 flaw that has known exploit code.”
  • “Sonatype is creating an extraordinary infrastructure for finding out everything knowable about a given component. So that when flaws are discovered, we can know and we have the ability to deliver that knowledge into the tools that developers are using every day. This family of technologies is called Insight.”
  • “Critical to that is the Central repository. Central houses hundreds of thousands of components from nearly every open source project in the world and it is used by tens of thousands of organizations.”

 

 

 

We’re a Java shop, we’re not going to get hacked…


March 27, 2012 By Tim O'Brien

This article is another in a series of articles associated with our Executive Brief. To access the executive brief, “Addressing Security Concerns in Open-Source Components,” visit www.sonatype.com/securitybrief. You can follow the conversation on Twitter using the hashtag #OSSsecurity.

I just wanted to reiterate the key point of yesterday’s security brief which is: “You and everyone else in the world are likely downloading vulnerable components.” If you don’t believe me, then take a look at this graph:

First, note the logarithmic scale – downloads over an entire year. Then, take a look at the left-side of the chart. See anything familiar? GWT, Spring, Struts, CXF, Xerces? If you use these components, you should try to identify which versions are affected by widely known CVE vulnerabilities. It’s that simple, if you use these components it would be a good idea to browse the CVE database, or to take a look at Nexus Professional’s Repository Health Check.

Really, attackers aren’t going to go to the trouble…

Developers, you might be thinking, “an insecurity in GWT or Xerces, who’s going to trouble of doing that much research? Who’s really going to hack into Megabank via some obscure AJP vulnerability in a Tomcat connector?” And if you are asking these questions as a way to shuffle this all under the rug, I understand. There’s enough work in the pipeline already and you don’t need another thing to worry about. As developers we’re not going to turn into security professionals overnight, but we can start using tools like Nexus Professional to help identify vulnerable components and isolate us from deploying known security problems to production.

It isn’t the likelihood that someone will hack GWT that is the issue, it is the idea that deploying any code with a known security vulnerability needs to be identified as a disqualifier. The idea that if you get compromised and someone realizes that it was a known vulnerability (for years): developers need to be motivated to avoid this embarrasing situation. The point I’ve tried to make on this blog is that we (developers) are not really paying attention to this problem because we just assume that it is someone else’s problem.

Ignoring Security: It isn’t a question of if you’ll get hacked, it’s when

The issue of data and systems security has repeatedly been front-page news time and time again over the past year. Groups like Anonymous and Lulzsec made a public sport in 2011 of hacking into serious organizations and making every effort to embarrass and ridicule them for lax security. The last few years have been pretty embarrassing years for a lot of security departments at large corporations and a few governments. 2012 promises to be even more active with McAfee predicting the reorganization of Anonymous, but focusing on these high-profile, news-generating events ignores the scope of the problem. It isn’t about volume, it is about your exposure to this risk.

I’ve seen some recent attacks in action. Attacks on both Java-based web architectures and PHP-based architectures. While it’s true that PHP-based applications present a much larger and more insecure surface area to attack, it has to be said that Java-based web applications and .NET present a much more lucrative target. An attacker can compromise all the two-bit Drupal instances in the world without stumbling upon anything worth intruding, or they can focus on a multi-month strategy of social engineering and direct attacks to compromise one the Global 100 financial institutions that are downloading insecure dependencies every day.

Welcome to the Security Theater

If you are banking on the fact that attacking Struts 2 or Log4J is just too esoteric for most hackers to do, you are participating in something Bruce Schneier calls Security Theater, and that’s really what I’m taking away from this study. Some of these institutions are so invested in presenting an image of trust and security that they will spend millions on Super Bowl ads and marketing efforts to purchase customer trust. But, at the end of that day they continue to download vulnerabilities. It doesn’t match up, we need a change of culture in development and security needs to be top of mind.

It’s time for developers to start taking security seriously. You could choose to be proactive about the problem and use tools like Nexus Professional to automatically correlate CVE vulnerabilities from CERT with your artifacts, or you can wait until someone replaces your company website with a funny picture and lose the ability to download artifacts from Central altogether. The choice is yours.

Today’s Security Brief: Application security is widely neglected (by some surprising companies)


March 26, 2012 By Tim O'Brien

Today we published a paper with Aspect Security, and it’s a shocking look at how few people are paying attention to application security. If you consume dependencies from the Central Repository and you don’t want to get hacked, I’d suggest reading the report and understanding some of the challenges, I’d also check out some of these statistics. Here are three that jumped out at me:

  • Global 500 organizations downloaded more than 2.8 million insecure components in one year.
  • Financial services firms are the most exposed: Global 100 financial services firms alone downloaded more than 567,000 insecure components in one year.
  • 48% (a little under half) of organizations don’t have an inventory of Open source software used in production. (If there’s a new vulnerability discovered in something like GWT, who knows if we have that in production.)

To access the executive brief, “Addressing Security Concerns in Open-Source Components,” visit www.sonatype.com/securitybrief. You can follow the conversation on Twitter using the hashtag #OSSsecurity.

NOTE: Now, Developers, I know what you are thinking, you see the word “Executive Brief” and immediately dismiss this as C-level corporate-speak. Sure, there’s a little bit of that, but you’ll also learn how to own any unpatched Struts 2 application with a known vulnerability. If you use Struts, maybe you should read this report before your boss uncovers a vulnerability in your application?

How well do you know your open source licensing?


January 9, 2012 By Terry Bernstein

Choosing components with appropriate licenses is critical to ensuring you realize the benefits and avoid the risks when developing with open source components. But, how well do you know your licenses?

  • Can you describe the differences between permissive, weakly protective and copyleft licenses?
  • Do you understand the ramifications of including copyleft licensed components in your commercial applications?
  • Do you know how component dependencies affect your application’s licensing?

If you want to brush up on your knowledge, please check out our short paper on open source licensing available here.

 

 

Tips for Increasing Open Source Benefits– Tips #1 and #2


October 17, 2011 By Terry Bernstein

With our launch of Insight, we’ve been talking to a lot of customers and prospective customers about effective management of open source-based development.  At this point, we’ve heard it all.  But some trends have emerged.  One thing is clear — virtually everyone wants to use more open source in their development processs, but realizes the need to effectively manage its use.  With thousands of components in use across their organizations, many people struggle with where to start.  With this in mind, we’ve put together a ‘top 10 list” to get things started.  You’ll find a summary of the entire list here.

We’ll be exploring each item in more depth through a series of five blog posts.   But for now, let’s start at the beginning with understanding your current usage of open source components. Continue reading →