Since its release four years ago, Sonatype Nexus has grown to support many repository formats. And most users of build tools including Gradle, Leiningen, SBT and Ant/Ivy have started to realize the numerous benefits of using a repository manager.

Using an MRM has become accepted best practice for Maven users.

The benefits of proxying external repositories and deploying third party artifacts are only the beginning. Things really take off when you start deploying your internal components to Nexus, making them immediately available to everyone.

Nexus: More Than Basic Repository Management

Nexus is evolving to help you manage the security and licensing aspects of your components.  In order to show you how, we have made this a focus of the latest release of the book Repository Management with Nexus.

The book now shows you how to access Insight information for a particular artifact. There are concrete examples on how to inspect and fix security issues, thanks to the information available in your Nexus search results and the linked information on the public security databases.

Note: When you read this, don’t forget to configure your Routing correctly to ensure that aspect of your Component Lifecycle Management (CLM) efforts is covered and no information about internal artifacts leaks to the public.

Part of your effort to get control over your component usage is to secure your sources. Part of that effort is to start using the Central Repository via secured access.

If you are using Nexus Professional this is as easy as upgrading to 2.2 and changing the Remote Storage Location URL. It is also available now for Nexus OSS by getting a $10 token here and making the same changes. Other repository managers will be supported soon.

Nexus 2.2 Now Included in Nexus Book

We have also made improvements and general updates to cover the latest Nexus 2.2 release. Among the topics changed are settings.xml setup explanations, documentation for capabilities, updates to the plugin creation chapter and many more.

Still, with all these improvements we realize that nothing is perfect and you might have questions or ideas for enhancing the book. If that’s the case, we encourage you to file issues with your wishes or attend one of our Nexus training classes. Also, don’t forget that the book is open source and we do take fixes as pull requests.

Component Lifecycle Management is Key

These improvements to Nexus are part of a larger Component Lifecycle Management solution that is provided by Sonatype. CLM helps you ensure the integrity of component-based software by analyzing usage and providing governance and policy enforcement during development.

As demonstrated by these Nexus improvements, CLM is integrated directly into your development infrastructure – including IDE, CI and repository manager tool of choice.

Have Jenkins (or Hudson) up and running, and want to give Insight for CI plugin a try? The plugin is available in the plugin center and easy to install and configure. — Just add a post build step and configure it to scan (e.g. your build output war file). Get the plugin.

Summary and component results are completely free and will give you a very good indication of the security and license issues (or better their absence) of your software. We’ve even got you covered for manual scans – have a try with Insight App Health Check.

To enable users to scan their applications, we provide an executable JAR with a graphical user interface. With this interface users are a few clicks away from results. But, even with this GUI, some users want to be able to use Insight’s Application Health Check from the command-line because sometimes “clicking” isn’t the most effective way to get something done. If you’re building your application using Apache Maven, you probably already have a terminal window open to invoke its build phases. So, while you’re in there, adding or updating some dependencies in your POM and repackaging your application, why not check whether this dependency update introduced some security vulnerability or license issue, especially if it’s as easy as adding another goal to your command line? Meet the Application Health Check Maven Plugin:

mvn package com.sonatype.insight:ahc:run -D ahc.email=my.name@mycompany.com

Right after all artifacts making up your application have been built, the ahc:run goal will collect their fingerprints and send them to the Insight service. The Insight service will match these fingerprints against a database of OSS licensing and security vulnerability data and identify potential problems. A few minutes after the plugin has uploaded the data, you receive an email with a link to your free Application Health Check report.

[INFO] --- ahc:1.21.2:run (default-cli) @ my-application ---
...
[INFO] Scan completed in 4 seconds
[INFO] Number of directories: 0
[INFO] Number of archives: 37
[INFO] Number of files: 3017
[INFO] Number of errors: 0
[INFO] Uploading scan to https://insight.sonatype.com/
[INFO] Report information will be emailed to my.name@mycompany.com 
       from insight-notification@sonatype.com
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

Notice that you didn’t need to modify your POM to run the plugin. Nothing had to change. In fact, the plugin runs as well without a POM, prompting you for the WAR/EAR/ZIP/TAR.GZ/etc. to be scanned. So whenever you’re in a terminal window and have Maven installed, Application Health Check is right at your fingertips to tell you about security or license issues.

Of course, if you use the plugin on a regular basis to check your apps without having to pass in the full groupId and artifactId of the plugin you just have to make a few tweaks to your Maven settings file. Add the following settings file:

${user.home}/.m2/settings.xml

Then, enter the XML below in it:

<settings>
...
  <pluginGroups>
    <pluginGroup>com.sonatype.insight</pluginGroup>
...
  </pluginGroups>
  <profiles>
    <id>insight</id>
    <properties>
      <ahc.email>my.name@mycompany.com</ahc.email>
    </properties>
  </profiles>
  <activeProfiles>
    <activeProfile>insight</activeProfile>
  </activeProfiles>
</settings>

That blob of XML makes mvn package ahc:run a no-brainer. If you have a project and you want to get started tracking OSS licenses and vulnerabilities, this is the way to get started. We’ll scan your project and then send you an email with the results of the scan.

The plugin has a few more optional parameters e.g. to exclude proprietary packages or customize the report label. Just check out our knowledge base for the details.

As requested by many attendees, you can download the slides right now. If you already have Jenkins (or Hudson) up and running, you might want to give it a try. The Insight for CI plugin is available in the plugin center and trivial to install and configure. Just add a post build step and configure it to scan e.g. your build output war file. The summary and component results are completely free and will give you a very good indication of the security and license issues (or better their absence) of your software. If you are using a different CI server, you should let us know so we can adjust our priorities. And we even got you covered for manual scans – have a try with Insight App Health Check.

You remember Outlook, maybe some of you are unlucky enough to still use Outlook, but for Microsoft, Outlook was a multi-year security embarrasment. From 1999 to around 2005 it felt like Outlook was having a security vulnerability every other minute. Back then, there were so many that, in technical circles, Outlook became something of a joke to anyone who valued security. In fact, you could make a compelling argument that Outlook’s multi-year security challenges were the weak point in the armor that provided an opening to Google’s GMail (and once you’ve decoupled from Outlook, why not try that Macbook Pro you’ve been eyeing).

If this trend in Java doesn’t stop – if we don’t stop experiencing billion-user, level 10 CVSS security exploits every other week in Java – all the inertia in the world won’t stop a shift to another language or another platform. Check out this news that just crossed the wire yesterday from Softpedia:

One billion users affected by Java security sandbox bypass vulnerability, experts say. Researchers from Security Explorations claimed to identify a flaw that affects all Oracle Java SE versions and the billions of devices on which the software is currently installed. This bug, codenamed issue 50, was identified just before the start of Oracle’s JavaOne 2012 conference. ―The impact of this issue is critical — we were able to successfully exploit it and achieve a complete Java security sandbox bypass in the environment of Java SE 5, 6 and 7,‖ the CEO of Security Explorations said. He said the vulnerability can be leveraged by an attacker to ―violate a fundamental security constraint‖ of Java Virtual Machines. The researchers confirmed Java SE 5 — Update 22, Java SE 6 — Update 35, and Java SE 7 Update 7 running on fully patched Windows 7 32-bit operating systems are susceptible to the attack. The affected Web browsers are Safari 5.1.7, Opera 12.02, Chrome 21.0.1180.89, Firefox 15.0.1, and Internet Explorer 9.0.8112.16421. The company provided Oracle with a complete technical description of the flaw, along with source and binary codes, and a proof-of-concept that demonstrates the complete security sandbox bypass in Java SE 5, 6, and 7.”

Don’t get me wrong, Java’s going nowhere. The JVM and language are here to stay, but when I read things like “a proof-of-concept that demonstrates the complete security sandbox bypass in Java SE 5, 6, and 7″ in the following security bulletin I have to ask myself what sort of foundation we’re building our systems on? Well it isn’t a sandbox if it can be circumvented, is it?

This reminds me of a piece that Vint Cerf wrote for next month’s Communications of the ACM, in it he writes about the lack of a scientific discipline when it comes to software in “Where’s the Science in Computer Science?”. Here’s a good sample:

“When we write a piece of software, do we have the ability to predict how many mistakes we have made (that is, bugs)? Do we know how long it will take to find and fix them? Do we know how many new bugs our fixes will create? Can we say anything concrete about vulnerability? What about the probability of exploitation? Murphy’s Law suggests that if there is a bug that can be exploited for nefarious purposes, it will be.” He continues later in the piece: “…As a group of professionals devoted to the evolution, understanding, and application of software and hardware to the myriad problems, opportunities, and activities of modern society, we have a responsibility to pursue the science in computer science. We must develop better tools and much deeper understanding of the systems we invent and a far greater ability to make predictions about the behavior of these complex, connected, and interacting systems.”

My impolite translation of Cerf’s wisdom? “You are all a bunch of hacks. You couldn’t model software if your life depended on it. Maybe it’s time to start getting serious.” I’d also like to put forward that it might be time for the people responsible for the JVM to hire someone who can take the time to do it right.

If you want to start “Doing it Right” and paying attention to security start with your dependencies. If you don’t use Sonatype Insight, it’s very likely that you are downloading software components with known vulnerabilities every day. Don’t get owned by some vulnerability that’s been in the wild for months, start using Insight today.

The New York Times had a great article this weekend that explored some of the disconnect in the industry. In “Power, Pollution and the Internet”, James Glanz writes: “[the] foundation of the information industry is sharply at odds with its image of sleek efficiency and environmental friendliness.” This article is interesting in that it calls out the industry for creating an unsustainable power drain that is based on some awful environmental choices. From the article: “Of all the things the Internet was expected to become, it is safe to say that a seed for the proliferation of backup diesel generators was not one of them.”

This piece made me stop and think about trends over the last decade. While the New York Times is focused on the environmental cost, I’m more interested in how this shift to Infrastructure-as-a-Service and deployment on cloud-based infrastructure is affecting open source licenses. The trend might not be readily apparent if you don’t know what to pay attention to. Here’s an attempt of making sense of licensing trends…

Note: This article explores a trend toward BSD-style licenses. If you are interested in tracking your own application’s exposure to various OSS licenses, please take a look at Sonatype Insight. Using Insight, you can keep track of your application’s exposure to GPL, AGPL, and other licenses which may present problems when you have to worry about external or internal distribution. Make licensing a part of your Application Lifecycle with Insight.

Taking Databases as an Example

Done any serious web development over the past decade? You’ve likely encountered MySQL. MySQL’s popularity exploded as the industry was looking for a capable, general purpose database that could provide an alternative to Oracle. Oracle is prohibitively expensive for a large portion of the market, and if you are running a cash-strapped startup you likely won’t be eager to fork over the minimum six-figure price of entry you’ll need to run Oracle.

For a decade MySQL competed on both cost and capability. You can certainly scale it if you either know what you are doing or are comfortable spending money on Percona’s professional services. It has some scalability issues, but, for the most part, you can either shard or start offloading some of your data to NoSQL once you reach limits. MySQL was the capable database for the 00s, and MySQL rose to popularity over the last decade before people started moving to hosted infrastructure (now what people tend to call Cloud infrastructure).

Enter Postgresql (and the Cloud)

Well, something happened one or two years ago: a number of large, high-profile web sites moved to Postgresql. Now Postgresql has always had a reputation for being a database with a strong opinion. Database administrators, performance nuts, people focused on scalability have always gravitated toward Postgresql. Postgresql community is somewhat “conservative” and there’s a small group of core committers that tend to favor stability over creativity. MySQL, on the other hand, has always had a reputation for being something of a mess. Reliable colleagues tell me that MySQL codebase is full of shipwrecks and broken dreams, and if you’ve ever had to deal with some of the more finnicky parts of MySQL tuning you’ll understand that while there may be a science to MySQL tuning, it is well hidden underneath a deep layer of poor documentation and guesswork.

The commonly accepted reason for the shift to Postgresql was performance and scalability. While I don’t disagree that Postgresql is certainly easier to tune and scale than MySQL. I question this justification as being political rather than practical. This is the simply the justification you’d expect a technical audience to resonate with, but I don’t think it is the real reason for the shift. Here’s why?

Cloud-based Infrastructures Seek BSD-licenses

I was at a Postgresql event last week in Chicago it was really interesting. Postgresql is experiencing a Rennaisance of interest. More and more people are coming to the database and I was interested in why. It isn’t like I’ve seen several compelling pieces outlining reasons to stop, drop, and move to postgresql immediately. Instead it seems like a slow shift that has happened over multiple years. While MySQL was something of a default for startup developers in 2007 and 2008, Postgresql is that default now. I asked around and got the following guesses:

• People have realized MySQL’s Limitations – I don’t buy this one. First, I do think that MySQL poses some tricky scalability issues, but I don’t think the majority of users create systems large enough to experience them. I don’t know anyone other than one or two individuals that has had a MySQL scalability issue they haven’t been able to either fix or workaround given the resources.
• Oracle – I heard a lot of conspiracy theory about Oracle and MySQL. Lot’s of people put this out as a reason why there is a huge shift to Postgresql. I don’t buy it. Oracle is out there chasing after huge contracts. I don’t think the Oracle people lose a bit of sleep over MySQL, and (beyond some structural changes to the OSS project) I don’t think they are taking it away.
• Avoiding NoSQL – This was a RDBMs conference so I took this with a grain of salt. A lot of people mentioned that Postgresql reduced the need to bring in technologies like MongoDB or Hadoop. I don’t buy that, I think that was just wishful thinking from a DBA that doesn’t want to integrate with NoSQL. I’ve also never spoken to anyone who said, “We’re on Postgresql so we don’t need to use Hadoop.” It just has never happened, and I just don’t see them as being in the same class.
• A Cloud-friendly License – Now this I buy. This explains the trend. I think it would be over-simplistic to say that Heroku is behind a shift to Postgresql (but I do think it is a contributing factor). Companies that offer on-demand, PaaS-style services have an incentive to standardize on BSD-style licenses (like the one that covers Postgresql) because they are distributing software.

It’s the Licensing, Stupid.

If you look at the language of the GPL, and especially some of the purposeful FUD that pre-acquisition MySQL AB was throwing around, “distribution” of any kind was enough to cover your entire codebase under the GPL. I remember looking at the MySQL AB website in 2004 and wondering if it was even possible to make the explanation of the GPL license for MySQL any more confusing. At the time, the common wisdom was that MySQL was crafting the licensing explanation in such a way to give companies with any doubt the incentive to purchase (even if it stretched the definition of the GPL).

And, here’s the issue, I don’t want to single out Oracle, I think they are a fine company so don’t get me wrong. But, I do think that people are leery of distributing GPL projects with a single, strong copyright holder within the cloud on behalf of paying customers. Even though the license isn’t as toxic as the AGPL, it is still unclear what constitutes distribution. And here’s the central trend that I think we can call out. As more and more of us rely on third-parties (like Heroku) to download, distribute, and install software, these platforms are increasingly running toward licenses that don’t entangle them with a web of obligations.

Or, to summarize, no one likes distributing the GPL, even in the cloud, especially when the copyright is owned by a big corporation with an interest in license compliance.

So the next time someone tells you that they moved to Postgresql because it as faster and more scalable. Ask yourself whether this is the real underlying reason for the switch or if that person is just being caught up in a larger movement away from copy-left licenses for cloud-based, PaaS systems. Was it an original idea, or were they affected by early adopters of PaaS moving to Postgresql because that’s the only option that was provided.

Clarification: I can already see people bombarding me with this question: what about Linux, that’s GPL? My answer is nuanced: “I do think that people are leery of distributing GPL projects with a single, strong copyright holder within the cloud on behalf of paying customers.” The Debian project or the CentOS project is not going to go after you for internal distribution.

I guess this makes sense, developers generally don’t want to have to deal with security, and me bringing up the fact that many of the systems you are working on may be vulnerable to attack isn’t something you want to think about. I understand, you have enough to worry about: looming deadlines, that junior programmer you just hired who isn’t pulling his weight, a continuing fight with operations over who “owns” the deployment process. Work is hard, there are certainly not enough hours in the day, and if you can ignore security, why not? I mean, it’s Java. Who’s going to attack Java?

AntiSec, that’s who. They aren’t just going to compromise your machines because you failed to update Java, they are going to grab your data, parade it around the world for all to see, and then make a few political statements at your expense. And, I’ll bet the FBI wishes that they had installed this February 2012 security patch from Oracle. If they had done so, they’d probably be having a much better day today.

“During the second week of March 2012, a Dell Vostro notebook, used by Supervisor Special Agent Christopher K. Stangl from FBI Regional Cyber Action Team and New York FBI Office Evidence Response Team was breached using the AtomicReferenceArray vulnerability on Java, during the shell session some files were downloaded from his Desktop folder one of them with the name of “NCFTA_iOS_devices_intel.csv” turned to be a list of 12,367,232 Apple iOS devices including Unique Device Identifiers (UDID), user names, name of device, type of device, Apple Push Notification Service tokens, zipcodes, cellphone numbers, addresses, etc. the personal details fields referring to people appears many times empty leaving the whole list incompleted on many parts. no other file on the same folder makes mention about this list or its purpose.”

This is from the AntiSEC statement regarding this breach (inappropriate language).

So what do you think is happening to the person responsible for security right now? Do you think he’s able to say, “you didn’t tell me that security was a priority?” or “It wasn’t my responsibility to check for JVM updates from Oracle?”. No, he’s likely being replaced, if not immediately then his management team is leading him on until they can identify someone who isn’t going to generate front page security failure.

What’s next? Well, the JVM is now front-and-center as far as security vulnerabilities go these days. Just last week you were all asked to turn off Java 7 until a suitable patch was issued (which is a ridiculous request BTW, that’s like asking us to stop working for a few days). I predict that as Java continues to develop as an attack vector – libraries are the next fun vulnerability. I know many of you don’t want to hear this, but it’s true. Your web frameworks are next, prepare yourself with Sonatype Insight, or start coming up with excuses when your systems are the reason for front page security fail.

Futures: Extending Your Apache Maven-Based Infrastructure

Jason van Zyl, Sonatype CTO and creator of Maven will be teaming up with Joel Confino, a Senior Consultant at Chariot Solutions to offer actionable advice for setting up best-in-class software development processes that make extensive use of 3rd party components (like the Spring framework).

Join us in Philadelphia on Tuesday, September 25 from 8:30am-10:30am EDT, for the Breakfast Meetup and see first hand how you can dramatically reduce risk and improve software quality using Apache Maven or another build tool, along with Nexus, Hudson or Jenkins.

Space is limited. We’ve booked a space at The Hub Cira Centre (2929 Arch Street), and it can only accommodate 30 guests. If you are in the Philadelphia area and are interested in making your build process rock solid, please register and our events coordinator Emily Blades, will save you a space and send you more details.

Reserve Your Seat

“Dogfooding” is such a strange word, and I’m using it as a substitute for “Eating your own dog food”. As we do have a global audience, I worry that the term is somewhat provincial (and maybe a bit strange out of context). So here, here’s the explanation of this idiom on Wikipedia.

Sonatype is “recursive”. We’re a group of developers, creating tools for developers, getting feedback from developers. Logically, we tend to use everything we make. We’re the first customer. We deploy early development releases of Nexus Professional to our own Nexus Professional instance, we use repository.sonatype.org as a test case as the release approaches, and every feature we send out to our customers has been audited and tested internally. By the time you download our software, we’ve already been using it often for a few months or weeks, and we also make heavy use of Sonatype Insight to identify licensing and security risks.

Now, this blog post is a bit risky. I’m about to tell you about the security issues that the Engineering team discovered in Nexus when we ran Nexus through our Insight scanner during the Nexus 2.1 release. By doing this, I’m exposing people that haven’t updated Nexus to 2.1 to some risk. At the same time, I’ve given everyone ample notice to upgrade (I even made a video imploring people to upgrade), and I’m a big believer in transparency. If we know something related to security, you should know it as well after we’ve given people enough time to upgrade.

Security Issues Discovered in Pre-2.1 Nexus Releases

Here’s a quick snapshot of the relevant Nexus Pro JIRA issue that covered the security issues we found in Nexus using Insight:

The OSVDB vulnerabilities we found were:

• OSVDB-59760 – Apache Commons VFS Exception Error Message Cleartext Credential Disclosure
• OSVDB-68314 – Apache XML-RPC SAX Parser External Entity Information Disclosure
• OSVDB-59003 – Apache HttpClient POST Request Handling Memory Consumption DoS

Unless you want to risk exposing a secure credential, get hacked via some XML, or suffer a denial of service attack via our Artifactory bridge, you probably want to upgrade to Nexus 2.1 right now. Got it? Good, Download Nexus Pro 2.1 Here or Download Nexus OSS 2.1 Here.

Going Forward: A Scan for every release?

Maybe. What I’d really like to see is for every single open source project out there to do the same. If I’m going to be depending on Spring or Hibernate, I’d like to see some proof that the developers have done some due diligence.

I think that posting an Insight scan alongside every software release is something that all software companies and open source projects should consider. We’re considering it for all releases going forward. There would be no more effective way to let your customers know that your software is clear of licensing issues and free of vulnerabilities than to post an Insight Application Health Check alongside your software.

NOTE: You might be asking, why the picture of the surfing dog? My answer is simple. Why not a picture of a surfing dog? Next question.

During our initial testing of Insight Application Health Check we found that real-world applications at large enterprise contained an average of 32 publicly known security vulnerabilities. Some of these security vulnerabilities were 3s and 4s on the 10 point CVSS scale, but many were 9s and 10s. These are bugs that are easily exploitable over the network which can be used to take ownership of applications and data.

So, think about it. If you develop Java applications, you’ve been relatively isolated from security concerns for years. Java has never been the top attack vector of hackers, and, because of this, developers have never really had to think about scanning artifacts for security issues. It looks like this is changing, and if you want to do something about it, it’s easy. Just run a free summary scan of your application with Insight App Health Check.

Here’s the IDG story, enjoy:

IDG News Service – (International) Java flaws increasingly targeted by attackers, researchers say. Java vulnerabilities are increasingly exploited by attackers to infect computers, and the problem could become worse if Oracle does not do more to secure the product and keep its installation base up to date, according to security researchers who will talk about Java-based attacks at the Black Hat USA 2012 security conference. Several years ago, the most targeted browser plug-ins were Flash Player and Adobe Reader. However, many current Web exploit toolkits rely heavily on Java exploits, said a security researcher with HP DVLabs, Hewlett-Packard’s vulnerability research division.

Source: http://www.computerworld.com/s/article/9229641/Java_flaws_increasingly_targeted_by_attackers_researchers_say