Gartner recently published research about the enterprise IT supply chain and impending threats that should encourage organizations to act. An overview of the research is available on Help Net Security: “Enterprise IT supply chains will be compromised”. The title sounds ominous, but it’s a good read that advises organizations to take a holistic approach to protecting the IT supply chain. We were happy to see that Neil MacDonald and Ray Valdes from Gartner cite research that Sonatype did with Aspect Security; research on open source software (OSS) downloads and how component vulnerability can impact the health of the IT supply chain.
Gartner’s take is in line with how Sonatype sees the world. In the remainder of this post we’ll address aspects that are particularly interesting and offer initial considerations about how to optimize the IT supply chain.
The New Reality
IT Supply Chain = Complexity: The IT supply chain is highly complicated. Consider these words or phrases: distributed, complex, component based, internally & externally sourced, combination of hardware & software. And think about the job responsibilities necessary to effectively manage an IT supply chain. The number of roles necessary to gather requirements, design, develop, test, deploy, monitor, maintain software and it’s related infrastructure is indicative of the IT supply chain complexity. As far as trust goes, complexity increases the likelihood of application issues and the number of threat vectors that can be manipulated to hinder the IT supply chain. Continue reading →
We know how components from the Central Repository have become critical to your development efforts. We also know that you need to trust those components. Part of that trust is knowing that hackers don’t have visibility into the components you download or that they compromise components using a man-in-the middle or Cross Build Injection (XBI) attack.
We’re making SSL connectivity to Central available to anyone that downloads open source components regardless of the repository manager. Given the tremendous growth of Central, and the fact that modern applications are largely built from OSS components, this capability is likely to be leveraged by many organizations. SSL has become the standard mechanism for protecting web traffic – across the spectrum of Ecommerce, banking, health care, and so on. Providing SSL support for Central means that your components are no longer susceptible to man-in-the-middle attacks that could compromise the component. SSL also eliminates the potential for a hacker to gain visibility into your organization by tracking the components that you download for your development initiatives.
As of Nexus Pro 2.2 (available now), SSL is now the default connectivity option for Nexus Pro users. Because we take security of the ecosystem seriously, we aren’t stopping there, we’re making SSL connectivity to Central available to you even if you aren’t using Nexus Pro.
In order to ensure the highest level of performance for those who count on SSL, we are securing the service with a token. You can get a token for your organization simply by providing a $10 donation that will be donated to open source causes. For the first 60 days all donations will go to the Apache Software Foundation. After that, the donations will go to other open source foundations such as Eclipse. Sonatype will provide a donation on behalf of Nexus Pro customers since we’ve included SSL access to all Pro customers automatically.
If you happen to be using Nexus OSS (any version), support for the SSL token is included already. I’ve already reached out to the Artifactory and Archiva teams and they are working on the changes necessary to enable SSL to Central – we’ll let you know when that support is enabled. If you’re not using a repository manager at all, what are you waiting for?
A few weeks ago, a few of us joined the Jenkins community at the Jenkins User Conference 2012 in San Francisco. Our presentation “Improving Software Quality Using Component Lifecycle Management with Jenkins” given by Manfred Moser, was very well attended and there seemed to be a lot of interest. A video of our presentation has now been posted here and you can download the slides as well.
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.
A few months ago, we launched Insight Application Health Check. Today, I’d like to announce another way to get started tracking licensing and security issues. In this post, I’m going to show you how to scan your project with nothing more than Maven and an existing project. You can get started with Insight without having to download a client or server. All you’ll need to do is run a simple plugin from the commandline.
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:
The an upcoming release of Nexus OSS will have full support for Yum repositories. Sebastian Herold, with gracious support from IS24, has developed and contributed his code and time to integrate his Nexus Yum Plugin into the Nexus 2.x line. We have heard from many Nexus users, who are heading down the path of continuous delivery, that Yum support in Nexus to deliver RPMs to production servers is a critical requirement. Several of our customers have been using Sebastian’s plugin for quite some time and have been impressed and so we’re really excited about the integration of Yum functionality into Nexus OSS!
Some of you might be interested in using our Yum support to facilitate application deployment to staging and production networks. A lot of companies that deploy Java and other technologies end up packaging applications as RPMs and deploying them through Yum on Redhat or Centos because it provides a really easy way to manage, deploy, and rollback software packages in production. It is much easier to tell Operations to deploy RPMs than it is to draw up a series of instructions for installing Jetty or Tomcat from a tarball. To support these use cases, we’re going to invest some of our time developing more documentation and training to support developers that need to adapt applications to deployments that depend on this Yum integration.
While Nexus is primarily used to support application development, this Yum support can be used on its own as a way to cache and simplify Yum repository configuration and package data. We’ll also be building out more examples of how Nexus can be integrated with infrastructure management tools such as chef and puppet.
Features of the Nexus Yum Support
As we integrate this feature into Nexus proper, here is the current list of features. We expect this support to evolve over time, but here’s what the plugin provides now.
Expose an existing Maven repository as an RPM repository – Use a Maven repository, hosted in Nexus, containing RPMs as if it is a Yum repository. This leverages the virtual repository mechanism in Nexus which allows you to use Maven tooling to deploy RPMs into a Maven repository but still allow Yum clients to interact with the repository using the protocol it understands.
Automated Refresh of Repository Data – Yum repositories are automatically updated if you upload/deploy/delete a new RPM into Nexus. In a traditional RPM repository you have to run createrepo to refresh repository metadata. With Nexus this is all taken care of automatically.
Full group support so that you can logically group a set of Yum repositories behind a single URL. If your infrastructure relies on a number of remote RPM repositories you can consolidate OS configuration to point to a single Yum repository that can aggregate multiple repositories into one.
Versioned views on repositories: http://your.nexus/nexus/service/local/yum/repos/releases/1.2.3/ gives you a Yum repository with all packages in version 1.2.3 in repository releases. This particular feature is a game-changer for companies that release software using RPM as a delivery mechanism.
Alias Definitions for Specific Versions eg. production=1.2 and testing=2.0 and access them via the alias: http://your.nexus/nexus/service/local/yum/repos/releases/testing/ and http://your.nexus/nexus/service/local/yum/repos/releases/production/ to get constant repository URLs for your servers. A new release is then applied to the server by setting the alias to a new version.
createrepo Nexus Tasks Types – Create Yum createrepo tasks manually via web interface. Multiple createrepo tasks on the same repository are merged.
Full Integration with Nexus Staging – Use Yum group repositories as target of staging repositories (Nexus Pro). Stage RPM artifacts to development environments configured to pull artifact from Nexus repository groups./li>