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: : 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 Well known vulnerabilities : 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 License restrictions : 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 Lack of flexibility 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 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 if you’d like to know more about it and it’s differences from and . Nexus great article jcenter Maven Central When you publish anything on , 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 — 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. Nexus Nexus IQ server Refresher course After briefly skimming through the , you will find out that you will need the following official tutorial 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 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. artifact’s name Everything that Nexus IQ analyze that is. CAN It’s supported formats include and even The official help says that there are many more supported ones, like C-style files and yet there is one glaring omission there. jar, war, ear, tar, tar.gz, zip Docker images. .o 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 I will teach you some tricks that will help you integrate it with Android. the next article Do you use another tool for vulnerability scan? Have you heard of any downsides of Nexus IQ? Comment below — any feedback is welcome.
