Any developer who has ever opened up a pom file on a large project will be familiar with the seemingly infinite number of dependences which make governance nearly impossible. Thankfully, Sonatype is making our job a little bit easier with Nexus Firewall–a tool which allows system administrators the ability to craft policies to limit which open source software and third party plugins developers can insert into their project. Over the past week, I have been messing around with Nexus Firewall on a few virtual machines, and I documented my experiences below.

The process of installing and setting up Nexus Firewall is relatively straightforward. In order to use Nexus Firewall, you must first install Nexus Professional onto your server. Nexus Professional offers a plethora of other features, such as the ability to publish notifications for deployments, and perform repository health checks—which make it useful product in its own right.

After the installation, open up the IQ Server Connection in Nexus Repository Manager, which is located within the “Administration” tab on the left sidebar, and type the URL of the IQ Server. At first I created a policy within the root organization that I expected to quarantine every artifact. The root organization can be accessed by clicking on the hierarchy icon on the top nav-bar, and then selecting “Root Organization.”   Within the main container, select the “New Policy” button. I creatively named my filter “Filter Everything” and added the age constraint to fail every artifact that was younger than 100 years. After defining the policy, the policy can be enabled by going back to Nexus Repository Manager and selecting “enable” on the line titled “IQ Audit and Quarantine” within the Capabilities tab.

Now, I can check to see if there are any IQ policy violations by running a maven deploy on a standard artifact. After executing

 Mvn deploy:deploy-file –DartifactId=ant –DgroupId=ant –Dversion=1.6.5 –Dfile=ant-1.6.5.jar –DrepositoryId=Central –Durl= 

I can see whether the artifact was properly quarantined by returning to capabilities, and under settings selecting “Quarantine.” As expected, I received a message that the “Request item is quarantined”.

Now that I have verified that my IQ server is functioning, I can define more realistic governance policies. Instead of quarantining artifacts that are younger than one hundred years, I can filter out artifacts that are older than 5 years, which may no longer be supported. According to Mark Cox in the article “Open Source Software Security,” which was published in Computer Weekly in April 2008, the responsiveness of any given open source project depends in part on the size of the development team. In crafting my OSS governance policies, I can define a policy which warns me when a developer pulls code in that is too recent, particularly if it is from a small development team which may need more time to react to vulnerabilities uncovered in the code. In addition to security policies, I can specify rules to prohibit developers from using code which is using licenses that are incompatible with my business. Obviously, you should make sure to consult a security expert or a member of your Operations Team for more robust governance policies.

Leave a comment

Your email address will not be published. Required fields are marked *