Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Managing software dependencies
Most digital services will rely on some third party code from other software to work properly. This is called a dependency.
You’ll need to manage dependencies carefully to keep your:
- code up to date
- system secure
- service working as intended
Meeting the Digital Service Standard
- why you’ve chosen to use the technologies you have, including the code you’ve used and your choice of software
- how you’ve managed any constraints this technology places on the design of the service
- how you’ve built a sustainable system that you can manage easily
The importance of using third party code
You save time building software when you reuse as much existing code as possible.
Generally, a huge amount of code is available for reuse. For example:
- open source libraries or frameworks
- commercial software appliances or applications that your organisation already has or could procure
- code that your organisation has written for other projects
But the more third party software you use, the more dependencies you’ll have. You need to manage these carefully.
How to work with third party code
You can work with third party code by:
- using a dependency management tool
- copying a vendor’s code into your project
- managing your own repository for third party code
Using a dependency management tool
A common approach, especially in the open source community, is to use a dependency management tool. This pulls in third party dependencies automatically at runtime, deploy time or compile time.
Even if you’re using a dependency management tool, you shouldn’t just trust a dependency without testing it first. This includes how secure it is. For example, if a library used to generate a web form introduces an SQL injection vulnerability, then your acceptance tests should fail. You’ll need to trust the specific code and version you are using, not just the general library or framework it belongs to.
Common dependency management tools include:
- Maven for Java
- Bundler for Ruby
- Pip for Python
- sbt for Scala
- Leiningen for Clojure
- Composer for PHP
Copy a vendor’s code into your own project
‘Vendoring’ is the process of moving all third party code into your internal directory. Not all open source licences allow you to do this, and some vendors will force you to licence your code in the same way as the dependency is licensed.
In general, use this approach as a last resort. It breaks the link with the third party code which means that tracking upstream changes becomes a manual job (and therefore slow, inconsistent and time consuming). For this reason, vendored code tends to go out of date quickly.
Ideally you should avoid this approach and use more structured approaches, like a dependency management tool.
Manage your own repository for third party code
Sometimes you’ll need more assurance than a third party code repository can provide. In these cases, you can fork or copy the third party code into a separate repository managed by you. This means that your copy of the code is not automatically affected by changes to the code upstream, but you maintain your link with the original.
Your can update your fork of the code as necessary, for example:
- after a code review
- in response to virus scanning
- after a check against known vulnerabilities
- if you’re modifying the code to provide a new piece of functionality
The downside of this approach (compared to using a dependency management tool) is that it takes time and effort to maintain your copy of the code and pull in any changes from upstream. As with vendoring, this means forked code can quickly go out of date.
Differences across programming language communities
Other communities may have fewer standalone libraries of code, but this tends to mean they have either:
- a more comprehensive standard library, eg Python
- larger dependencies, eg Java
Managing risks in third party code
When you include third party code in your application you’re potentially including known or unknown vulnerabilities.
How you respond to this risk will depend on the risk appetite of your service. If your appetite is moderate to high, you can run tests to find identify problems. If it is low, you may need to do a code review.
Tools that help identify risks
Commercial tools exist to help you track all your dependencies and tell you when software needs updating or becomes vulnerable. These include:
Mailing lists that publish known risks
Most operating systems and vendors, and some open source projects have mailing lists that your team can subscribe to for alerts about security vulnerabilities in third party code.
Subscribe using an internal mailing list rather than an individual’s email address. This makes sure that everyone in your team gets them, even when individuals leave.
You should always be monitoring these alerts, provided they exist for software you use.
Some common examples include:
You may also find the Manage your software configuration guide useful.
- Published by:
- Technology community (backend development)
- Last update:
Guidance first published