188体育

Most digital services will rely on some third-party code from other software to work properly. This is called a dependency.

You鈥檒l 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鈥檛 update regularly you鈥檒l leave your system vulnerable.

This can be particularly important when working with emerging technologies like [artificial intelligence](/government/publications/ai-playbook-for-the-uk-government].

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鈥檒l 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鈥檚 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鈥檙e using a dependency management tool, you shouldn鈥檛 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鈥檒l 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:

• for Java
• for Ruby
• for Python
• for Scala
• for Clojure
• for PHP
• for JavaScript

Copy a vendor鈥檚 code into your own project

鈥榁endoring鈥� is the process of moving all third-party code into your internal directory. Not all 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鈥檒l 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鈥檙e 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鈥檒l 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鈥檙e 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:

• , which checks assets served by third parties and ensures they have not been compromised for hostile purposes
• , 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鈥檚 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.

For information about managing risks and dependencies associated with artificial intelligence (AI) read the AI Playbook.