Raising the cyber resilience of software 'at scale'
New ‘Code of Practice for Software Vendors’ will ensure that security is fundamental to developing and distributing products and services.
Software is the lifeblood of our digital economy. But alongside the benefits it provides, it introduces risks that need to be managed across our software supply chains, to ensure our systems remain resilient against cyber attacks.
In a recent blog, Ollie Whitehouse explained that cyber security shouldn’t be a premium feature, just as seatbelts have never been a price differential in the car industry. The voluntary Code of Practice for Software Vendors is a systemic intervention by the UK government, designed to ensure that security is ‘baked into' software, rather than a costed extra.
The Code is aimed at software vendors*, setting out the minimum set of actions that should be in place to ensure their products and services are resilient to a cyber attack from a commodity threat. It will begin as voluntary code, but further policy interventions to support its uptake and impact are currently being explored. You can respond to the call for views by visiting the Code of Practice for Software Vendors page on the gov.uk website.
Shift to the left
Talk to any security professional and you’ll get the same message; considering security at the development stage of a product’s life cycle (or ‘shifting security to the left’) is a more efficient way to manage cyber risk than bolting-on security solutions on at the end. This ethos of ‘Secure by Design’ is a core tenet the Code of Practice which puts the responsibility for cyber security on the vendor throughout the life cycle (a theme recently discussed during a session at CYBERUK 2024).
The Code of Practice for Software Vendors is made up of 21 provisions over 4 principles:
-
Principle 1: Secure design and development
ensures that the product or service is appropriately secure when provided.
-
Principle 2: Build environment security
ensures that the appropriate steps are taken to minimise the risk of build environments becoming compromised, and to protect the integrity and quality of the software.
-
Principle 3: Secure deployment and maintenance
ensures that the product or service remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities.
-
Principle 4: Communication with customers
ensures that vendor organisations provide sufficient information to customers to enable effective risk and incident management.
There are many things that a vendor can do to make their product more secure, but in reality, we know cyber security is just one of many risks an organisation is juggling. Organisations ultimately have a ‘compliance budget’; a limit to the number of things they can afford to do well whilst also making a profit. The Code therefore defines a modest set of provisions, and working collaboratively with industry we have tested the efficacy of each control, ensuring they are proportionate to both the vulnerabilities they remove and the likely budget available, given that the 98% of the UK’s private-sector comprises small businesses (ie with less than 49 employees). For this reason, we particularly welcome any thoughts on the proportionality and impact the code would have on vendors of all sizes and sectors, through the call for views.
Build environment security is included in the Code, since this is critical to the cyber resilience of the software product or service. It is drawn out as a separate principle as we recognise its importance as a distinct area of focus with its own complexities. We would expect any software vendor in the critical supply chain market (that is, facing an elevated threat) to have taken significant steps to improve the cyber resilience of their organisational, development and build environments, as directed by their customers. However, for vendors whose products and services require basic cyber resilience (that is, against a commodity threat), the cost of this exceeds the benefit to the consumer.
For this reason, the provisions under Principle 2 focus on the interactions between the developers and the build environment, and we will pursue other interventions that will support software vendors to build trust in their development and build environments.
Guidance for developing secure software is not new
All systems contain vulnerabilities. In fact, the number of Common Vulnerabilities and Exposures (CVEs) in commodity technology continues to rise, and this is a trend we expect to continue. Hence, the UK government’s focus is on resilience; ensuring software products and services are ‘secure by design’ and maintained through their lifetime. Resilience needs to be the responsibility of the vendor, not passed onto the customer.
We know many vulnerabilities are complex and hard to avoid. But those vulnerabilities that are trivial to find, that occur time and time again, are ones we are aiming to drive down at scale. But just as vulnerabilities have been around for decades (as this 1972 planning paper by the Electronics Systems Division illustrates), so has security advice. Many, many standards, principles, and guides on secure software development now exist, and have done for years.
So, given there are so many security frameworks to choose from, why do we still see the same ‘unforgivable’ vulnerabilities?
Part of the answer lies in the observation that software developers are not necessarily security experts. Our research showed that many developers found it hard to identify where and how to make effective security decisions, and the tools to do this are often inaccessible and complicated. Vulnerabilities are hard to avoid, but we can eradicate many using the right tools and approaches.
Improving the resilience of our software and hardware technology stacks in ways that we can scale globally is a multi-faceted, sociotechnical challenge. We continue to collaborate with our international partners on a number of key enablers, such as the use of memory-safety languages.
Together, we are working to supplement the Code of Practice for Software Vendors by establishing:
- guidance (such as CISA Secure by Design)
- assurance regimes (such as Cyber Resilience Test Facilities, or CRTFs)
- initiatives (such as software measurability and understanding from the White House’s Office of the National Cyber Director)
- technology solutions (such as the University of Cambridge’s CHERI [Capability Hardware Enhanced RISC Instructions] project)
These will all help us to build a more secure technology ecosystem.
Our work on the Code has also highlighted key areas where we need to develop more targeted, international interventions in the longer-term. The code is designed to reduce the most common vulnerabilities we see being exploited. For those products and services that are part of a critical supply chain (facing an elevated threat), risk owners may require additional assurances from vendors.
Market behaviours and incentives
A voluntary code of practice marks the first step in establishing clear expectations for what should be a market baseline. It signals to both software vendors and their customers what can reasonably be expected from software suppliers, but is only the first step in incentivising change across the market.
In a recent blog, the NCSC’s CTO Ollie Whitehouse argued that – where there is an absence of regulation, legislation, or procurement requirement – market incentives do not currently exist to produce or sustain secure software/hardware that is sufficient to meet the modern threat. Creating the right market incentives for software and hardware vendors products is one of our key priorities, and we explored the reasons behind current market behaviours in a recent blog.
We know that executive and organisational behaviours are driven by a number of factors, and that no single intervention or incentive is likely to achieve the behaviour change in software vendors we’re aiming for. Instead, a suite of incentives at various levels will be required that are coherent with other international approaches.
Improving the security of software at scale will significantly contribute to the cyber resilience of our supply chains in the UK. The Code will establish the right foundations on which compliance and assurance regimes can be built upon. Make sure you share your views on it by visiting the Code of Practice for Software Vendors website.
Helen L
CTO Cyber Growth, NCSC
* Note that we don’t expect open source developers to adapt the code.
Share and print this article
Written by
