In this post, I’m going to talk about OSS project security. Since we’ve been paying a lot of attention to OSS security, I wanted to lay out some guidelines for evaluating an OSS project’s security. There’s a wide range of approaches to security from OSS projects: on one end of the spectrum, a one-person OSS project on Github won’t have a formal approach to security; on the other end of the spectrum, a project that is at the center of a billion dollar commercial ecosystem (like Apache httpd or Tomcat) will have a dedicated security team.

This post focuses on the secure end of the spectrum. Projects like Tomcat and Apache httpd that have dedicated security teams. Here are some of the baseline requirements for an OSS security teams. If you are maintain an open source project and you want to let the end-user know you take security seriously, you should consider starting a security team and following the guidelines in this post. If you are consuming open source, you should look for the following signs that this project has a mature approach to security in place:

• A low-volume general, public announcements list – Every OSS project should have a “announcements” list which only contains release announcements or critical security announcements, no more, no less. Having a low-volume announcement list and being disciplined about what you send to this list increases the value of having an announcement list. The best case is a project that has a separate security announcement list. Users can define filters and flag these messages as important guides for security. The worst case is a project that has a noisy list that is a mixture of discussions and announcements. Keep the noise out of security announcements.
• A private security list – If you run an open source project and someone notifies you of a vulnerability, you’ll want a private place to discuss the potential impact and any proposed fixes. If your project is especially large (Linux, httpd, Tomcat) you want to limit this list to a few trusted members of the project.
• One or more PGP Keys – This is a critical requirement, if someone identifies a security vulnerability in your software they need some assurance that the vulnerability report is being delivered to the right people. This is critical because (as a hypothetical) if I were going to compromise Tomcat, I might also attempt to compromise the accounts of the people who maintain Tomcat. Email is, in general, unencrypted over the public internet, you shouldn’t put anything sensitive into a plaintext email that you wouldn’t want broadcast to the entire world.
• How to Report a Vulnerability – Every project has different requirements, but if someone is reporting a vulnerability in a project like Tomcat, the security team will likely want to know some basic common details: what JVM was being used? What version of Tomcat was vulnerable? Is there any exploit code that can test the vulnerability? Also important, who else is aware fo the vulnerability? How long have you known about the vulnerability? Are you aware of any successful attacks using this vulnerability?
• A Description of the Security Process – This is especially important because Security teams are one part of an OSS project that is very opaque. While the public has visibility into almost all other aspects of a collaborative open source project, the security team is often working in secret to address identified vulnerabilities (possibly for months before they are generally known). To reduce friction between the transparency and the need for secrecy make sure that the public is aware of the security process. Consider retroactive transparency for discussions once the exploit has been published.

Here are a few examples of projects with mature security teams:

• SpringSource Security Team – http://www.springsource.com/security
• Apache Security Team – http://www.apache.org/security/ (Focuses mostly on APR and HTTP)
• Apache Tomcat Security Team – http://tomcat.apache.org/security.html
• Apache Struts Security Team – http://struts.apache.org/security.html

These projects have enough developers to have created a critical mass of both end-users and developers. All of these projects also have a strong commercial interest that can sustain continuous investment in a security team. As I’ve been surveying open source security, I’ve been impressed at the speed with which most open source projects react to security vulnerabilities. In general, projects that are attached to a respected forge (like Apache and Eclipse) are associated with a process and procedure for making sure that end-users have an interface to a security team. On the other hand, I see a very large list of projects that don’t present any interface for security other than a public developer’s list.

If we’re going to start taking application security seriously, every open source project should take the time to satisfy these minimum standards for presenting a secure interface to end-users.

See what components are used, which versions, and when updates are available

We want to make component based development as easy as possible by providing you the tools to choose the right components from the beginning to speed development, improve quality, and reduce costly rework. This plugin, the first of a series of development tools, helps you tame the issues typically associated with utilizing open source Java components, including:

• Determining when new component versions are available and making informed update decisions
• Understanding what versions of each component are used in your project
• Identifying where specific components are used
• Updating components throughout your project

The plugin is build tool agnostic, and so works with all Java projects in general (Java, PDE, Maven, etc.).

This is just the beginning. We’ll be adding features to help you choose components that meet your security, quality, and licensing standards by providing useful information about each component right in the IDE.  For example, we’ll alert you when a component, or one of its dependencies has known security vulnerabilities. You’ll also be able to tell how each component or dependency is licensed without having to hunt through the code yourself.

So tame your dependencies today and get the Sonatype Insight Plugin for Eclipse.

More on this presentation:

Maven 3 is the best version of Maven yet. Maven 3 is faster, has been optimized for IDE use, and is fully backward compatible with Maven 2. One of the big focuses of Maven 3 is to provide a more reliable, more stable and better performing build tool. Faster Maven builds lead to higher developer productivity in your organization.

Watch the video below:

About the webinar:

Tycho is a set of Maven plugins and extensions for building Eclipse plugins and OSGI bundles with Maven. Eclipse plugins and OSGI bundles have their own metadata for expressing dependencies, source folder locations, etc. that are normally found in a Maven POM. Tycho uses native metadata for Eclipse plugins and OSGi bundles and uses the POM to configure and drive the build. Tycho supports bundles, fragments, features, update site projects and RCP applications. Tycho also knows how to run JUnit test plugins using OSGi runtime and there is also support for sharing build results using Maven artifact repositories.

Join this webinar to get an overview of the Tycho project and to learn what plans the project has for the future.

• Date: May 3, 2011
• Time: 9:00 am PST / 12:00 pm EST / 4:00 pm UTC / 6:00 pm CET
• Length: 60 minutes
• Enroll here!

Software developer Igor Fedorenko details the new features and changes to m2eclipse 1.0, including pom.xml editor enhancements and reworked build lifecycle mapping.

For more videos from the Sonatype team, visit our Resource Center, or go to our YouTube channel.

EclipseCon is the conference for anyone involved in Eclipse. As a proud member of the Eclipse Foundation, Sonatype is looking forward to another year of great talks, tutorials and BOF’s. We will be hosting a number of talks in the Cypress Room all day on Tuesday, March 22, 2011.

Sonatype founder Jason van Zyl will be giving a presentation on Building Eclipse plugins and RCP applications with Tycho, Nexus & Hudson.

Event details:

• Date: March 21-24, 2011
• Location: Hyatt Regency Santa Clara, CA
• Event website: http://www.eclipsecon.org/2011/

Stay tuned to the Sonatype blog for updates on Sonatype’s talks and presentations at EclipseCon 2011. And for the latest news and updates from the Sonatype team, follow us on Twitter @SonatypeCM.

Today we are releasing m2e 0.12.1. Despite our previous announcement that 0.12.0 would be the last version made available from Sonatype, we have decided to cut this point release to make available new versions of the m2e dependencies.

Most notably, this release includes recently released Maven 3.0.2 embedded runtime and an updated version of Async HTTP Client that resolves all known issues reported against m2e 0.12.0, and thus helps make m2e work better in corporate environments.

As usual this version of m2e is made available from the Eclipse Marketplace and from http://m2eclipse.sonatype.org/sites/m2e/.

Enjoy!

Learn best practices, central concepts, and complete integration for Maven, Nexus Professional, and m2eclipse. Sonatype books offer the latest content for the software development tools you depend on.

The fourth book in our series of books available for downloading is Developing with Eclipse and Maven.

In this book you will learn how to fully integrate Maven with Eclipse, the world’s most widely used IDE for Java development.

Why Maven?

Maven is a software build tool, but it is much more than that. Maven is also a project management tool. It is designed to be flexible, easy, and intuitive – to be a more efficient and comprehensive build tool.

Why Eclipse?

Eclipse is the most widely used IDE for Java development today. Eclipse has a huge amount of plugins and an innumerable amount of organizations developing their own software on top of it. Quite simply, Eclipse is ubiquitous. The m2eclipse project provides full integration for Maven within the Eclipse IDE.

From an end-user perspective this means a wider availability of m2eclipse, but more importantly it means an alignment of m2e with the main Eclipse components and also with the Eclipse releases.  m2e will be participating in the Indigo release train and we have asked for its inclusion in the Java Developer Package.

Eclipse is known for IP cleanliness. Through its very thorough IP review process, the Eclipse Foundation has been known to only make available code with a very clear pedigree. In fact, it is this very process that prevented us from moving our code to Eclipse a couple years ago. We now have addressed all the issues uncovered in this initial attempt.

You may wonder, how does this help me? It does not make m2e run faster, or better? You are right, but it helps where you can’t see.  It helps making someone in your management chain more comfortable with the usage of m2e, but also enables m2e for inclusion into more Eclipse-based products and to some extent favor the creation of m2e extensions.

From an extender perspective, this move means work. In fact, since m2e namespace will now be org.eclipse.m2e instead of org.maven.ide, m2e extension developers will to be forced to change their code to have their extensions work with the new m2e. Despite our commitment to work in Eclipse 3.7 (Indigo), m2e is still targeted to work on Eclipse 3.5, 3.6 and 3.7, which means that you should not have to maintain two branches of your code one for the “old” Sonatype m2e and one for the new Eclipse m2e.

Overall despite the initial hurdle that can result from this sort of move, we are deeply convinced that it is a great opportunity for the m2e community at large.

At this point, the move has not been completed as we are still working with the Eclipse IP team to get all our code and dependencies reviewed. If all goes well, we are hoping to have everything moved to the Eclipse Foundation by mid-December. In the meantime the development is still happening on github but under the new org.eclipse.m2e name-space. We will keep you posted when the code has been completed moved.