How to manage third party software dependencies
When you develop and operate a service, it’s important to keep any third party dependencies you use up-to-date. By doing this, you can avoid potential security vulnerabilities.
Any automated tools you use to manage third party dependencies should be compatible with GDS supported programming languages. The tools you use should neither slow down your development process nor disclose potential security vulnerabilities to the public.
You can read more about managing software dependencies in the Service Manual, where you will find a list of common dependency management tools.
Our programming language style guides also contain language-specific advice about managing dependencies (for example, managing Python dependencies).
Update dependencies frequently
Update your dependencies frequently rather than in ‘big bang’ batches. This works well with continuous delivery principles and makes sure the changes introduced are small and can be automatically tested.
There are tools which scan GitHub repositories and raise pull requests (PRs) when they find dependency updates. Most teams at GDS use Dependabot for this, but service teams are free to use a different tool such as Snyk.
You should configure your dependency management tool with a cooldown period to reduce your exposure to newly compromised dependencies. Dependabot has this by default.
Dependabot
Github enables Dependabot by default for security updates, but it can be configured to check for dependency updates too. Turn this on by configuring a .github/dependabot.yml file with your desired update frequency.
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
By default dependabot will limit the number of open update PRs to 5 - you should to increase this limit to 10 or more unless your repo has a very small number of dependencies.
As your project evolves, you may find it useful to:
- use more advanced Dependabot - for example by grouping dependencies or varying the configuration between different package ecosystems
- > Example: GOV.UK’s guidance on using Dependabot includes an example Dependabot config file which uses some of these features
- document your process for reviewing and merging Dependabot PRs
- > Example: GOV.UK’s ‘Merge a Pull Request’ documentation includes guidance on how to review PRs raised by Dependabot
Some teams have enabled automatic merges for some Github PRs. This can reduce the amount of manual effort required to stay up to date, but before enabling this you should be confident in your branch protection, CI and security processes.
Example: GOV.UK have enabled automatic merging for some Dependabot PRs - they have explained their implementation and some of the benefits and tradeoffs in RFC-167.
Github has some examples for using Actions to automate dependabot merges, but these may not work for your repo - for example, many GDS repos have branch protection rules requiring at least one approving review from a maintainer for PRs to be merged into main. These repos will not be able to automatically merge PRs since the action will not be able to approve with maintainer permissions. Do not use actions to automatically merge approved Dependabot PRs, as this would lead to a surprising behaviour at the point of approval.
Monitor for vulnerabilities
You should monitor for potential vulnerabilities in every layer of your technology stack. This is not straightforward but tooling exists to help. The Service Manual provides guidance on browser technology, tooling and mailing lists you can subscribe to.
Most of the tooling that helps you stay on top of dependency updates will also highlight vulnerabilities. Additional tooling includes:
GitHub security alerts
When GitHub discovers or is informed about a vulnerability, it will email an alert to the repository owner and users with admin access. GitHub security alerts will be turned on for all Alphagov repositories. If services wish to opt out of security advisories on their repository, they can contact Cyber Security and then add the no-security-advisories tag to their repository.
Snyk
Snyk is capable of detecting vulnerabilities in a variety of languages including all the GDS supported programming languages. You can configure Snyk to raise PRs, email regular reports and alert you when new vulnerabilities are detected.
If you have an old repository that is receiving security alerts but is not being worked on or maintained, you may wish to archive your repository instead.
Managing Docker dependencies
Rebuild Docker base images
Like dependencies, Docker base images are also frequently updated. If you run containers as part of your service, you should regularly rebuild your images (and base images) to include the latest updates. Automate this process where possible.
Specifying Docker image tags and digests
The GDS Way Dockerfile guidance contains advice on how to use Docker image tags and digests to specify the exact container image version to use.
Use official Docker base images
Always use official base images. Docker Hub regularly scans official images and you can view the results by logging into Docker Hub. If you do not regularly update your base image, you must make sure a manual process exists to monitor and prioritise fixes for detected vulnerabilities.
Minimise what you need to monitor
Minimise the things you need to monitor by minimising dependencies where possible. For example, if running containers, make sure you pick the smallest base images.
Also consider managed solutions where possible. For example, using managed container orchestration technology such as AWS Fargate means you don’t have to monitor for vulnerabilities in your OS or control plane.