Managing third-party product security risks

When developing digital services, it's common for delivery teams to integrate code, tools or platforms provided by external suppliers. These should be reviewed prior to being used to identify vulnerabilities and manage any potential security risks.

By carrying out security reviews on third-party products before they are implemented, you will be able to:

• make informed risk management decisions and ensure risks have been mitigated to a level that meets your project’s security risk appetite
• confirm whether the products meet relevant security obligations, expected industry security standards and good practice guidance
• guard against security risks such as malware and unauthorised access to sensitive data
• make products that pass due diligence available to others across your organisation that have a similar risk appetite

This activity should take place continuously throughout the lifecycle of a service with all proposed and active third-party products routinely assessed against security risks.

Completing this activity will help you to achieve the outcomes included in the Secure by Design principle to source secure technology products.

Who is involved

The risks related to potential compromises within third-party products need to be understood and managed by your Senior Responsible Owner (SRO), service owner and programme manager.

They should work with delivery and development teams to determine which third-party products may be required, and security professionals who can advise on the potential risks related to them.

How to manage risk from using third-party products

These steps will help you to generate a report that sets out the information third-party suppliers will have access to and the risks associated with using the products you need to integrate into your service.

Step 1: Create a list of product requirements and proposed suppliers

Once the development of your service has evolved beyond the planning and discovery stages, there should be a high level understanding of the service model, solution architecture, technical design, DevOps environment, and the required tools.

Within these, there will be open source products or products that you intend to procure from external vendors. To keep security risks contained, third-party products to be used should be listed with their specific purpose within the delivery of the service and flagged for security review.

Your list should cover all proposed third-party products and the function each will perform within the service.

Step 2: Check if any products have already been assessed

Your organisation may already maintain an approved supplier list that includes details of third-party products already being used within digital service delivery.

Reviewing the security posture of third-party products requires time and resources. Sharing information across project teams helps improve efficiency and provides good value for money.

If you are planning to use a pre-approved product, make sure that the criteria used to complete security due diligence matches the requirements of your project and meets the Secure by Design principles.

Step 3: Review relevant security information

For products that have yet to be reviewed, put together an approach that assesses each product against known risks, appropriate security standards and good practice guidance.

This review should be conducted by security professionals and be proportional to how the product is being used. For example if the product is not going to be handling any sensitive data, there is no need to assess their information handling and storage capabilities.

When reviewing products, you may have multiple options that provide similar functionality. Your review should include an assessment of whether they meet acceptable security obligations (for example, ensuring that data is held in a location that complies with UK security protocols). Security should play a part in the selection of tools, along with cost and other relevant criteria. This may have implications on your budget where procured products are chosen over open-source options in order to meet your project’s security risk appetite.

Recommended third-party security review tasks

This is not an exhaustive list.

• Review security related product documentation and ask the supplier to explain the security controls implemented within the product and their plans for maintaining these
• Confirm how and where the product will store any data and establish the location of any backup servers and protocols for handling data from collection to deletion
• Seek legal advice on proposed contracts so you can understand the supplier’s security obligations and know what you will be responsible for as a consumer of the product
• Assess how the vendor detects and responds to vulnerabilities related to the product, evaluate their track record with security and review how they’ve handled any breaches
• Check security certificates, compliance reports and vulnerability assessment reports related to the product and ensure they are valid and that tests were carried out by reputable and impartial observers
• Review trusted cyber security threat intelligence sources for information about the product

Step 4: Produce a third-party security risk report

Each third-party product evaluated should be included in a security risk report with details of the function, relevant risks and review criteria that was carried out. This should include copies of any relevant documentation and details of who was involved in conducting the review.

This should be considered a living document with the risks and any mitigations continually reviewed and updated. It should be used by the delivery team to make informed decisions on the trade-off between security, performance, usability and functionality when delivering the service.

Your report should also include details of any products which have been assessed but rejected due to security concerns. This information will be valuable to others seeking to use the product either later on in the service lifecycle or in other project teams.

The collated information should be made available to:

• the people within your project who are responsible for ensuring third-party products being used are secure
• service designers and delivery teams who will be responsible for implementing third-party products and ensuring security controls operate as intended
• procurements teams within your organisation who may want to make approved third-party products available to other projects

Retracted versions should also be made available to the suppliers who have been assessed so they can be aware of the success criteria they have been judged against, allowing them to make security improvements to their products and services.

Further reading

• National Cyber Security Council (NCSC): Supply chain security guidance
• NCSC: Supplier assurance questions
• NCSC: Using third-party applications on devices

Related Secure by Design activities

This activity is part of the ‘Understand the security landscape’ stage of Secure by Design, which also includes:

• Understanding business objectives and user needs
• Understanding cyber security obligations

Read the Secure by Design activities

The Secure by Design approach will evolve to reflect the needs of government digital services. Your feedback will help us to improve it.

Last update: 31 January 2024