Software supply chain requirements are taking shape in Europe: don't fall behind

The software supply chain has gained significant attention in 2022 following high-profile vulnerabilities and attacks that targeted a range of industries. Following these incidents, US President Joe Biden published Executive Order 14208 as the first step in a flurry of legislative and regulatory guidance, advisories, and mandates in an attempt to rapidly uplift the security and integrity of the supply chain. A brief timeline explaining the list of publications launched in a targeted campaign by the U.S. Authorities to address an issue that had been overlooked for far too long can be found here: A timeline of federal guidance on software supply chain security.

It is clear however, that both the supply chain and broader existential threat of cyber attacks bear no borders. As a result, we have now seen oversight bodies in the UK and Europe begin to follow suit by ensuring organisation’s within their remit are taking appropriate steps to protect the global software ecosystem.

In this article, we explore the existing guidance published by legal and regulatory bodies in the UK and Europe regarding supply chain risk management (SCRM), as well as how organisations can prepare for emerging requirements coming down the pipeline.

Inherent Trust in the Software Ecosystem

Historically, there has been limited industry agnostic, EU wide legislation or regulation that has covered the need to secure the supply chain, let alone the software within it. In fact, it was not until 2016 that the European Commission proposed the first iteration of the Network and Information Security (NIS) directive addressing the broader cyber landscape. In alignment with other guidance to date, NIS did not specifically highlight the security risk posed by the supply chain. In fact, it suggested that software within the supply chain only enhanced an organisation's security posture, contributing to the “Inherent Trust” phenomenon that still plagues the security industry today:

"While hardware manufacturers and software developers are not operators of essential services, nor are they digital service providers, their products enhance the security of network and information systems. Therefore, they play an important role in enabling operators of essential services and digital service providers to secure their network and information systems."

Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016

We have since come to understand that the exact opposite is true. Software does not inherently improve the security of our network, information systems, and essential services that it may underpin. Instead, because software is inextricably intertwined with these systems, it is actively targeted by malicious actors who want to maximise the blast radius of their attack. As a result, software arguably poses the largest threat to business operations beyond any other element of the supply chain.

Current guidelines governing SCRM in the UK & Europe

We have recently observed a change in Europe’s attitude towards the security risk posed by the supply chain. As described in the European Commission's strategy on ‘Shaping Europe’s digital future’, a vital factor of economic success stems from enabling organisations to trust the digital products they are consuming, including the software components that may be embedded within those products. Although this focus on security and digital trust has not materialised into any formal legislation or mandatory requirements for the software supply chain, a variety of research and guidance has been released over the last 24 months which indicates a recognition of the issue and need for change:

Threat Landscape for Supply Chain Attacks

Who: The European Union Agency for Cybersecurity, ENISA, is the EU's agency dedicated to achieving a high common level of cybersecurity capabilities across Europe.

When: Published July 29, 2021

What: ENISA performed an in depth study of supply chain attacks that were discovered from January 2020-July 2021, investigating attack techniques used, supplier types and assets targeted, and threat actors involved. The study also aims to develop a standard taxonomy for classifying supply chain attacks in order to better analyse and compare them in a systematic manner.

Key Takeaways:

  • In 62% of the supply chain attacks analysed, malware was the attack technique employed
  • When considering targeted assets, in 66% of the incidents, attackers focused on the suppliers’ code in order to further compromise targeted customers
  • Organisations need to update their cybersecurity methodology with supply chain attacks in mind, as well as incorporate all their suppliers in their protection and security verification

Read the report

Call for Views on Supply Chain Cyber Security

Who: The Department for Digital, Culture, Media & Sport (DCMS) helps to drive growth, enrich lives and promote Britain abroad. A key objective of DCMS is to drive the UK’s connectivity, telecommunications and digital sectors in a secure manner.

When: 11 July 2021

What: DCMS research (including the 2021 Cyber Security Breaches Survey) had identified that businesses of all sizes were not adequately protecting themselves against cyber attacks, particularly attacks originating in their supply chains. As a result, while the government prepared a new National Cyber Strategy, DCMS was assigned the responsibility to gather industry input on how organisations within the UK manage supply chain cyber risk and what additional government intervention would enable organisation’s to do this more effectively.

Key Takeaways:

  • The main barriers preventing organisations from more effectively managing supplier cyber risk are:
    • Low recognition of supplier risk
    • Limited visibility into supply chains
    • Insufficient expertise to evaluate supplier cyber risk
    • Insufficient tools to evaluate supplier cyber risk
    • Limitations to taking action due to structural imbalances
  • More detailed policy solutions are needed to address the threat of supply chain security

Read the paper

Vendor Security Assessment: Assessing the security of network equipment

Who: The National Cyber Security Centre (NCSC) is a government agency set up to help protect the UK's critical services from cyber attacks, manage major incidents, and improve the underlying security of the UK Internet through technological improvement and advice to citizens and organisations.

When: 22 March 2022

What: Referenced in the draft version of Telecommunications Security Code of Practice (measures 5.01 and 10), this publication provides guidance for how to assess the security of networking equipment, including the software embedded within it.

Key Takeaways:

  • The security of software must be maintained throughout the lifecycle of the product to provide confidence that products can be patched against security issues discovered across releases
  • All changes to software versions must be tracked to support the effective investigation of supply chain attacks.
  • All software must be rigorously tested before a version is released to ensure internal security requirements have been met.
  • Third-party tools (e.g. code compilers), software components, and software libraries that are used within and in the development of the product must be inventoried and evaluated for security vulnerabilities throughout the lifecycle of a product
  • Software signatures must be verified before binaries are executed to ensure software is not tampered with
  • No credentials (e.g. hard coded credentials) must be left embedded within software which would cause the equipment to be highly vulnerable to exploitation.

Read the report

How to assess and gain confidence in your supply chain cyber security

Who: The National Cyber Security Centre (NCSC) is a government agency set up to help protect the UK's critical services from cyber attacks, manage major incidents, and improve the underlying security of the UK Internet through technological improvement and advice to citizens and organisations.

When: 12 October 2022

What: This guidance describes practical steps to help organisations better assess cybersecurity in their supply chains. It’s aimed at medium to large organisations who need to gain confidence or assurance that mitigations are in place for vulnerabilities associated with suppliers.

Key Takeaways:

  • A core component of this guidance centres around the need to tailor supply chain security oversight activities to the unique nature of products and services that are consumed from a supplier, rather than taking a "one size fits all" approach. This is especially important when considering the security risk posed by software suppliers, which this guidance speaks to in depth.

Read the guidance

Cybersecurity Threats Fast-Forward 2030

Who: The European Union Agency for Cybersecurity, ENISA, is the EU's agency dedicated to achieving a high common level of cybersecurity capabilities across Europe.

When: 11 November 2022

What: Following an eight-month threat foresight exercise, ENISA published an analysis of the top 10 top cybersecurity threats likely to emerge by 2030.

Key Takeaways:

  • Supply chain compromise of software dependencies was identified as the #1 threat that the security industry will face by 2030. This is primarily due to the increased volume of components and services that are provided by third-party suppliers, creating complexities which could lead to novel and unforeseen compromises to both the software supplier and customer.

Read the press release

Emerging requirements coming down the pipeline for UK & Europe

Noted within the DCMS Call for Views on Supply Chain Cyber Security, it is broadly recognized that more detailed policy enforcement is required from oversight bodies to enact change. Both the UK and EU have taken notice of this need and are in the process of rolling out new regulatory and legislative requirements surrounding software supply chain security to take effect in coming years. Below, we highlight a few examples of emerging change on the horizon:

Network and Information Security (NIS) 2 Directive

Who: European Commission


  • 16 January 2023, the Directive (EU) 2022/2555 (known as NIS2) entered into force replacing Directive (EU) 2016/1148.
  • 17 October 2024, Member States must adopt and publish the measures necessary to comply with the NIS 2 Directive.

What: The long awaited update to NIS (the first piece of EU-wide legislation on cybersecurity) is being implemented to ensure more stringent supervisory measures and stricter enforcement requirements (as a fragmented adoption by member states caused failure with NIS 1).

Impact: Member States are granted discretion to levy administrative fines for breaches of up to 10M EUR or 2% of total worldwide annual turnover (whichever is higher) for instances of infringement with the directive.

Relevance to Software Supply Chain: The need to “address the security of supply chains” is a fundamental driving force behind the refresh of current NIS guidelines. The proposed language states, “Addressing cybersecurity risks stemming from an entity’s supply chain and its relationship with its suppliers is particularly important given the prevalence of incidents where entities have fallen victim to cyber-attacks and where malicious actors were able to compromise the security of an entity’s network and information systems by exploiting vulnerabilities affecting third party products and services”. This need to address cyber risk would extend to the software which underpins these products and services.

Read the directive

Cyber Resilience Act

Who: European Commission

Why: Existing EU cyber legislation has substantial gaps regarding the security of products with digital elements


  • Proposal for a regulation was presented September 15 2022
  • The European Commission opened a public feedback period from 19 September 2022 - 23 January 2023 with the aim of feeding into the legislative debate
  • Once adopted, economic operators and Member States will have two years to adapt to the new requirements. The obligation to report actively exploited vulnerabilities and incidents will apply after one year.

What: This proposal for a regulation on cybersecurity requirements for products with digital elements bolsters cybersecurity rules, ensuring more secure hardware and software products. Although the nature of how the act will be enforced is still pending review, the preferred option noted within the draft proposal involves the mandatory third-party assessment for critical products (including their embedded software) based on a cost/benefit analysis and the desire for market transparency.

Impact: The non-compliance with the essential cybersecurity requirements laid down in Annex I and the obligations set out in Articles 10 and 11 shall be subject to administrative fines of up to 15M EUR or, if the offender is an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher.

Relevance to Software Supply Chain: Annex I of the proposed regulation outlines a list of cybersecurity requirements expected to be achieved for products which contain a digital element. This list includes various elements surrounding the security and integrity of software including, but not limited to, ensuring that software is:

  • Delivered with a secure by default configuration, including the possibility to reset the product to its original state
  • Designed, developed and produced to limit attack surfaces, including external interfaces
  • All vulnerabilities and components contained in the product are identified and documented, including drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product;
  • Measures are taken to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements.

Read about initiative

Note: The examples above are not an exhaustive representation of the current or future landscape of cybersecurity laws and regulations. For example, the examples provided do not include industry or sector specific requirements, such as the Digital Operational Resilience Act (DORA) for financial institutions or The Electronic Communications (Security Measures) Regulations 2022 specific to network and service providers.

What can you do to bring yourself in alignment?

Take a proportionate approach to SCRM

Several regulators within the UK and EU, including the Prudential Regulatory Authority (PRA) and European Banking Authority (EBA), advocate for the principle of proportionality when managing supply chain risk. This principle states that supply chain risk should be overseen with a level of effort and due diligence that is proportional to the risk that a unique supplier presents to an organisation's business operations.

In order to adopt this approach, organisations often design a risk segmentation model. This allocates enterprise suppliers into “tiers” based on a variety of risk elements so that assurance activities can be targeted to oversee the most critical risk business relationships. The traditional scope of segmentation models focuses on two distinct qualifiers:

  1. Is sensitive data shared with a supplier?
  2. Is external network connectivity granted to a supplier?

Although these risk elements are a great foundation for understanding the threat that may be imposed by a third-party, they overlook the commercial off the shelf software (COTS) supplier type which we know from experience poses a significant risk to organisations. As these COTS suppliers traditionally do not have access to data or connectivity to a network, they tend to be allocated into the lowest risk tier, therefore receiving limited oversight.

It is recommended that organisations expand their segmentation approach to cover characteristics that are unique to software. The following is a list of software risk elements included in a draft bill created by the US Congress that can be used as a framework when considering what characteristics to include:

  • the security properties of code in a given software component, such as whether the code is written in a memory-safe programming language;
  • the security practices of development, build, and release processes of a given software component, such as the use of multi-factor authentication by maintainers and cryptographic signing of releases;
  • the number and severity of publicly known, unpatched vulnerabilities in a given software component;
  • the breadth of deployment of a given software component;
  • the level of risk associated with where a given software component is integrated or deployed, such as whether the component operates on a network boundary or in a privileged location;
  • the health of the community for a given software component, including, where applicable, the level of current and historical investment and maintenance in the software component, such as the number and activity of individual maintainers.

Shift away from a “one size fits all” mentality

Once software suppliers are in-scope for monitoring, organisations should evaluate their assessment processes to make sure they address the unique risk presented by a specific supplier type. Far too often, organisations make the mistake of building a one size fits all programme to monitor supplier security risk. Although this may make it easy to compare the security posture of one supplier to another (e.g. apples to apples), it overlooks the uniqueness of the relationship, product, or service that is provided that contributes to its risk profile. In fact, it may be detrimental to compare the security maturity of two suppliers that are inherently different as it may negatively influence procurement decision making if the comparison is built off a correlation with no significance (e.g. apples to oranges).

In fact, the UK NCSC guidance on “How to assess and gain confidence in your supply chain cyber security” suggests exactly this. It states the the following:

"Supply chains can be complex, and may involve many different organizations working in very different ways. As a result, there is not really a ‘one size fits all’ approach to assessing supply chain cyber security risk. You should therefore seek to understand risks to your supply chain based on what your suppliers provide to you and the relationship you have with them."

Focus on risk presented by products and services consumed

A theme introduced by various of the aforementioned oversight bodies, organisations should shift their focus from only using questionnaire based assessments, which primarily focus on business process oriented controls (e.g. background check policy, leavers processes, etc.), to product and service specific risk assessments.

For example, if you engaged with a supplier to acquire a COTS software product, a targeted assessment should include the following activities that are unique to the software product consumed:

  • Generate a software bill of materials for any package you consume. This will enhance your understanding of the third-party and open source components which make up your software ecosystem, thus enabling streamlined incident response efforts in the event of another Log4j
  • Identify malware and vulnerabilities embedded within any software component
  • Identify sophisticated software tampering attacks by analysing suspicious behaviours introduced between subsequent release/update packages
  • Find and eliminate exposed secrets (e.g. credentials, private keys and access tokens) that can be leveraged by an attacker to gain unauthorised access to your software estate
  • Verify appropriate security mitigations are correctly implemented to reduce your attack surface
  • Validate that critical risk remediation actions have been addressed by comparing the posture of subsequent release packages

Achieve Software Assurance Throughout the Lifecycle of Use

History has shown that malicious actors have found success in breaching software supply chains throughout various stages of the software development, packaging, delivery, and use lifecycle. The security risks posed by software suppliers is not stagnant, and will continue to change over time as they begin to adopt new processes, onboard new tool chains to support development, and hire new employees to scale their operations. As such, it is important that organisation’s broaden their scope of assurance activities beyond a single point in time assessment to gain continuous coverage of risk throughout the lifecycle supplier engagement.

This concept of continuous supplier monitoring, materialises throughout various industry control frameworks (e.g. NIST 800-161 Control CA-2), regulatory guidelines (e.g. EBA Outsourcing Guidelines and DORA), and legislative requirements (e.g. Executive Order 14028). A simple way of demonstrating continuous monitoring in the context of COTS providers can be achieved by the following two-step process:

  1. Perform “pre-deployment validation” to validate the security and integrity risks of software prior to deployment to your production environment
  2. For any new update/patch/release that occurs post deployment, validate the security and integrity risks posed by any additions or modifications to the software package

Need help taking the first step?

ReversingLabs, the market leader in software supply chain security, has teamed up with PricewaterhouseCoopers LLP (a limited liability partnership incorporated in England) (“PwC”)) to help businesses gain visibility and control over their software supply chain. PwC provides market leading advisory and managed services in Third Party Risk Management (TPRM) and works with many of the world’s largest and most complex organisations. Working together, ReversingLabs and PwC will help customers modernise traditional TPRM programs that struggle to keep pace with the complexities and interconnectedness of the modern software supply chain.

If you have questions about how to effectively manage software supply chain security risk, please contact us for help.

Contact us

Penny Flint

Penny Flint

Partner, Financial Services and Third Party Risk Management, PwC United Kingdom

Tel: +44 (0)7803 858309

Ian Trinder

Ian Trinder

Director, Resilience & Risk Management, PwC United Kingdom

Tel: +44 (0)7483 401097

Charlie Jones

Charlie Jones

Director of Product Management, ReversingLabs, PwC United Kingdom

Tel: +44 (0)7483 421805

Follow us