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.
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.
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:
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”1 and “ssh”2 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.
Over the past few months I have been expanding the number of smart home devices I have and appreciating how HomeKit allows these to all be managed in a single place, regardless of the manufacturer.
There is one older device that I have which does not support HomeKit, and was only controllable through the App from the manufacturer. HomeKit support for this device is not coming, but there is a workaround.
Enter HomeBridge.
HomeKit support for the impatient.
Homebridge is a lightweight NodeJS server you can run on your home network that emulates the iOS HomeKit API. It supports Plugins, which are community-contributed modules that provide a basic bridge from HomeKit to various 3rd-party APIs provided by manufacturers of “smart home” devices.
There is a docker image available, but the setup instructions for this require the container to be ran with the “host” networking mode. The primary reason for this appears to be to allow an Avahi daemon to run in the container and be able to answer responses to mDNS requests, which requires the container to be in the same local network subnet as the device performing the lookup.
For isolation purposes I’m not a fan of running services in host networking mode, and I already have an avahi-daemon running on my server for advertising other services.