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

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:

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:

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:

^{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:

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.