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?
Bouncy Castle. Do those words mean anything to you? If you are a Java developer, you might know that Bouncy Castle is an encryption library often used to generate secure hash codes and encrypt data. In other words, it is a silly project name for a serious purpose. Do you any know that old, released versions of Bouncy Castle have known security vulnerabilities? I’m not writing this to cast a shadow of doubt on the project. Bouncy Castle is an awesome open source library, as is the Spring framework, Commons HttpClient, Tomcat, and Jetty. What Bouncy Castle has in common with all of these other open source components is that old versions of each project have known security vulnerabilities.
There’s a good chance that you might not be focused on this problem. You might not be constantly evaluating your project’s dependencies to analyze the risks.
Continue reading →
I’ve had the opportunity to see many development environments: from the mature organization with tens of thousands of developers that can afford to spend millions on dedicated infrastructure teams, to the three person start-up lacking something as simple as source control. This series of posts discusses some of the common anti-patterns in development infrastructure that are relevant regardless of team size or approach. It also provides some hints for how to avoid these problems.
Problem/Anti-pattern: Too Many Logins
No matter how mature your process is, I’ve always found credentials to be especially difficult for a new hire. It takes days, and then, even when you think you’ve created all of the necessary passwords, there are those other systems that jump up from out of nowhere.
“Do you have a login for Subversion? No. Talk to Tom about that? How about JIRA? I’m not sure who setup JIRA, let me check on that. Ok, we have this VPN, and you are going to need to get those credentials in order to check your email which, unfortunately, is a whole different set of passwords.”
The first few days of employment are meeting people, downloading Gigabytes of software, and remembering an encyclopedia of passwords. Some of these password might be managed by HR, others are managed by your Technology department, but this post focuses on those credentials that affect development infrastructure. If your development infrastructure is mature, your organization might solve this by consolidating authorization and access control information on an LDAP server or Atlassian’s Crowd. If you don’t use one of these products, then you are dealing with an expanding constellation of moving parts: JIRA, Subversion, GitHub, Basecamp, Bugzilla, Confluence, Twiki, Matrix, CruiseControl, etc.
Part of my daily routine involves managing the Sonatype OSS Repository, a free, hosted Nexus Professional instance for hosting open source project repositories . There are more than 100 projects hosted on the OSS instance, and each project has at least one release repository, one snapshot repository, and one repository group. When we started offering this service I would create two repositories and a single repository group for each project, but as community adoption increased, I found that managing hundreds of repositories was become a very complicated and time-consuming task. In this post, I’m going to discuss how I consolidated hundreds of repositories down to a single release repository, snapshot repository, and repository group. I’m also going to discuss how I used Nexus security settings to partition these consolidated repositories, providing necessary isolation between separate projects.
If you are running a large instance of Nexus to manage internal development, or if you are responsible for an open source project’s installation of Nexus, you can use the approach outlined in this post. Continue reading →