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 any dependencies in your service carefully to keep your:
- code up to date
- system secure
- service working as intended
Whether your configuration code is open or closed, you must keep your dependencies up to date. New versions of software often contain fixes for security flaws so if you don’t update regularly you’ll leave your system vulnerable.
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
- npm for JavaScript
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.
You 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
Different programming language communities tend to treat dependencies differently. For instance, in the Ruby or JavaScript communities you’ll find lots of little libraries that do one trivial thing well. This approach can quickly create projects with hundreds of dependencies.
Other communities may have fewer standalone libraries of code, but this tends to mean they have either:
- a more comprehensive standard library - for example, Python
- larger dependencies - for example, 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 identify problems. If it is low, you may need to do a code review.
Making the most of modern browser technology
Modern browsers come with technology that can help you to greatly reduce any potential damage by a third-party script. You should consider enabling:
- Subresource Integrity (SRI), which checks assets served by third parties and ensures they have not been compromised for hostile purposes
- Content Security Policy (CSP), which helps website authors to improve security by restricting where an HTML page can load assets from
When used together, SRI and CSP can be very effective in helping to protect your service from many different kinds of attack
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:
Related guides
You may also find the Manage your software configuration guide useful.
- Last update:
-
Updated list of security tools and suggested using SRI and CSP.
-
Guidance first published