Dev With Imagination

Git hooks are a fantastic first step for identifying issues before code is pushed to a repository. However, the configuration files which control these client-side hooks cannot be committed to the repository and need to be configured on each client once the repository has been checked out.

In the NPM world, Husky is a tool which is used to maintain commit hooks through the package.json file, and integrates with the NPM build lifecycle to keep the contents of the local “.git/hooks” folder up to date. With this, I have been using commitlint for ensuring commit messages conform to a standard format, as well as ensuring code has had linting checks ran against it.

I had a look for a similar solution for Maven, but could not immediately find one. I wanted to find a solution that could be integrated with the Maven lifecycle, like Husky does for NPM.

» Continue reading

Throughout this series of blog posts I am looking at how to manage third party dependencies in the software development lifecycle. Before we get into how to automate the process of checking library licenses and checking if they are up to date, it is worth looking at how to do this yourself.

In this blog post I will look at the tools available for scanning an Angular application, which would also work for any type of project using NPM.

» Continue reading

As part of looking in to controlling the third party libraries which could be included for use by a project, I wondered if it was possible to effectively apply an approved whitelist at the Sonatype Nexus level. This would only be effective if developers and CI tools are restricted in their web access and cannot contact the central artefact repositories directly, and so are forced to use Nexus as a mirror.

It turns out that this is possible, and the Nexus documentation is pretty good if you know the pieces of the puzzle that need to be joined together to make this work. Roles, which can be assigned to specific users or an anonymous user, are made up of privileges. Privileges can include Content Selectors to restrict the results which are returned. When combining these things, we can effectively build a whitelist. As this approach is role based, different rules can be used depending on who the caller is.

» Continue reading

Third party dependencies are an essential part of every modern software project. It is nearly impossible to build a non-trivial application without depending on third party libraries.

However, by introducing external software dependencies you are also introducing an area of risk to a project. The OWASP top 10 lists “Using Components with Known Vulnerabilities” as the number 9 most critical risk to web applications in the last (2017) list. The linked page provides a lot more detail on the risk and general mitigations, and if you have not came across this list before it really should be required reading for all developers.

There are four key points that need to be considered for the use of libraries by a project:

• only including libraries which are actually required
• ensuring the libraries have a licence which allows their use/distribution in your product
• ensuring libraries are kept up to date
• being aware of Common Vulnerabilities and Exposures (CVEs)

For a small number of dependencies it may be possible to manually keep on top of this, but ideally it should be automated. There are many commercial tools (such as Snyk and Sonatype Lifecycle) which can be used as part of the software delivery supply chain for performing scans and audits on the libraries that a project is using. In this series I will explore some of the options which can be put together using open source solutions.

As part of some experimentation I was doing with Docker Swarm I encountered some inconsistent behaviour in my setup. To rule out inconsistencies in OSs (since I was using a combination of Ubuntu and Debian Buster), I had a look at the install process for Ubuntu on a Raspberry Pi.

The Raspberry Pi which was spare for this experiment was a model 3A+, so no ethernet and only a single USB port. With Raspbian I would have added “wifi_supplicant.conf”¹ and “ssh”² files to configure the WiFi and enable SSH as part of the first boot.

I was looking for a similar approach that would work for a headless Ubuntu install.

I came across this project: Raspberry Pi Cloud-Init for WiFi. This uses the cloud-init system to configure, amongst other things, WiFi. This basically provides a few scripts to generate some additional files to copy on to an Ubuntu imaged SD card.

I did find however that it required a few updates to make it work for me on Ubuntu 19.10.

» Continue reading