Nexus Sighting: Illegal Argument Podcast #76
Nexus was mentioned in Episode #76 of Illegal Argument. Mark Derricutt published a list of technologies that he would choose if he were starting a startup and hosts discussed and modified his choices:
- Git
- git-flow
- Gerrit
- Jenkins
- Gitblit
- Vagrant / Pallet – For consitency, “if you are going to deploy to a RedHat machine have your dev instance running on a virtual machine”
- Maven
- BitBucket
- MySQL
- …and, of course, Nexus
Fun fact about this discussion is that while almost everything else in the stack comes under considerable dicsussion. Nexus is a unanimous decision, there’s no discussion of running this stack without Nexus – Running Nexus is a foregone conclusion. (So, what are you waiting for, download Nexus if you haven’t already.)
To listen to Illegal Argument, you can visit the Illegal Argument web site or you can subscribe to the podcast in iTunes. You can also follow this podcast’s Twitter account @illegalargument.
Evaluating an Open Source Project’s Security
Last week I wrote about how important it is to pay attention to the security of the OSS projects you depend on. This isn’t just a one-time responsibility when you are trying to choose which component to depend on, this is an ongoing requirement. Even if you use the most secure OSS projects out there, if you don’t pay attention to security updates, it is all for nothing. Staying secure requires constant vigilance.
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.
How do most people find new dependencies… Google.
Our 2012 developer survey (PDF) asked: “How do you find artifacts for your projects?” This question might mean different things to different developers, but in general what we’re trying to find out is what process people use when they are creating a new project and they need to figure out what to put in a pom.xml for a dependency. This is usually something that happens at the beginning of the software lifecycle, and it is a time to update versions or evaluate alternative libraries. Some developers might just be looking for the latest version of Spring or Hibernate, and other developers might have a larger mandate to identify new alternative dependencies.
How do people find artifacts? How do they find the proper GAV coordinates for a dependency?
The overwhelming answer is: “Search the web for artifacts”. Another translation: “We just Google it, and figure out what the latest version of a library is.” Or, “We just Google it and figure out what the latest greatest thing is and then we try to see what other people are using.”
That first, most popular answer, isn’t ideal for a few reasons: SEO, the popularity game of search, and the fact that evaluating a hundred of options in open source is really just a big subjective game. There’s no objective “score” for projects, there’s no relative ranking. Here’s an example:
The OSS projects you depend on take security seriously. Do you?
When we published our executive brief on security a few of you immediately reacted wondering if we were calling OSS insecure, we are not. OSS is both secure and increasingly awesome. What we’re trying to call attention to is the disconnect between OSS security and the ways in which it is consumed. It is clear from our survey of the data that many organizations are just not paying any attention to a constant stream of critical security updates. As a result these organizations are exposed to security flaws that have already been addressed by these projects.
Important projects, projects like Apache httpd, Apache Tomcat, JBoss, or Spring all have something in common. Each of these projects has a formal security team and a process for addressing security flaws. The presence of a security team in an OSS project is a signature of how seriously a project takes vulnerabilities. If you are evaluating projects for security, you should evaluate a project not by the number of vulnerabilities you identify with a tool like Nexus 2.0, but on the process a project uses for addressing security risks.
Just because a project has a large number of vulnerabilities doesn’t mean this project is insecure. Take, for example, Tomcat.
OSS Compliance: Lead or be Led, Your Choice
In case you missed it, we published the results of our Developer Survey as a PDF. One of the things we did this year was post some comparisons to last year’s survey, specifically the changing attitudes toward OSS license compliance and policy. Here’s a statistic that caught my attention:
These two ends of spectrum – no standards vs. total lock down – had huge movement between 2011 and 2012, and I predict that we’re going to see the same sort of movement in next year’s survey. Open source compliance is top of mind for a few reasons, but I think that the trend can be explained by the timing of corporate adoption of OSS over the last decade and the average lifecycle of enterprise development.
