Keeping third-party dependencies in check

In this article I am explaining 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 have at some point faced a dilemma of adding a third-party dependency to your software. With all the benefits, they sure 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 are they 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 are 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 too.

Enter Sonatype Nexus IQ

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 the 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 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 on 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 out that you will need the following

• Deployed instance of Nexus IQ server
• Accessible URL of the deployed instance
• User Credentials and Application ID under which the report will be stored
• Nexus IQ 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 there with the results of it’s 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 IQ 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 glaring omission there.

Oh well.

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.

It will likely give you 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, and in the next article I will teach you some tricks that will help you integrate it with Android.

Do you use another tool for vulnerability scan? Have you heard of any downsides of Nexus IQ? Comment below — any feedback is welcome.