Keeping Third-Party Dependencies in Check With Nexus Lifecycle

In this article I explain the risks of third-party dependencies and how to mitigate them with appropriate tools.

Damned if you don’t

Whether you’re a developer, a CTO or a tech lead, I bet you've faced the dilemma of whether or not to add a third-party dependency to your software. While they have incredible benefits, they do come with some obvious trade-offs along the following lines:

• Well known vulnerabilities: there are so many people using this code, there are bound to be some smart people who have already found a way to breach it
• License restrictions: a lot of libraries and components cannot be used in some circumstances and unless you’re well versed in different types of licences, you can get into legal trouble
• Lack of flexibility: since you are not the one who owns that code — you’re not the one who calls the shots on what features have to be included and how they are supposed to work

Detecting a problem of the third category is trivial, however how do you detect issues belonging to the first two? If your company is small and there are only a couple of dependencies here and there — you can do a manual check, however when you're starting to scale your business and the number of engineers starts going into tens and hundreds you have to scale your approaches, processes and tools.

Enter Sonatype Nexus Lifecycle (IQ Server) 

You might have heard of Nexus Repository  — it’s a place where you can upload your binary and share it with other people either within your organization or outside of it. With tools like Gradle or Maven anyone with access will be able to depend on your code with little effort. Here’s a great article if you’d like to know more about it and it’s differences from jcenter and Maven Central.

When you publish anything on Nexus, you can inspect your code for known vulnerabilities or license breaches just by flipping a switch in the settings. However should you decide against publishing, you can still use their Nexus Lifecycle (IQ Server) — a powerful engine that allows you to create your own company policies on third-party dependencies usage and a scanner tool that will generate reports about your code’s compliance to them. After being generated these can be found in a dashboard with very detailed descriptions of all the vulnerabilities found, the respective common workarounds and best practices of usage.

Refresher course

After briefly skimming through the official tutorial, you will find that you need the following:

• Deployed instance of Nexus Lifecycle (IQ Server)
• Accessible URL of the deployed instance
• User Credentials and Application ID under which the report will be stored
• Nexus Lifecycle (IQ Server) CLI tool and Java8 to run it
• The binary you want to analyze, I’ll call it the artifact

java -jar <NEXUS_DIR>/nexus-iq.jar -i <APPLICATION_ID> -s <NEXUS_IQ_SERVER_URL> -a <USERNAME>:<PASSWORD> <ARTIFACT>

Presto! Now if you go to your dashboard you will see the entry under your artifact’s name, with the results of the scan. Of course instead of a single file you can supply the whole folder to Nexus IQ CLI and have it analyze everything inside.

Everything that Nexus Lifecycle (IQ Server) CAN analyze that is.

It’s supported formats include jar, war, ear, tar, tar.gz, zip and even Docker images. The official help says that there are many more supported ones, like C-style .o files and yet there is one omission. 

It’s a powerful tool and something that any tech lead or a CTO would appreciate, however there is a catch.

It was not built for Mobile Apps.

While it may seem like a headache to figure out how to add your Android and iOS dependencies to this dashboard, the outcome is well worth it - a single source of truth for your company’s code safety. In part two I will teach you some tricks that will help you integrate it with Android.

A version of this article originally appeared on Hackernoon and has been republished her with permission from the author.