Government response to the call for views on software resilience and security for businesses and organisations
Published 23 January 2024
© Crown copyright 2024
This publication is licensed under the terms of the Open Government Licence v3.0 except where otherwise stated. To view this licence, visit nationalarchives.gov.uk/doc/open-government-licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: psi@nationalarchives.gov.uk.
Where we have identified any third party copyright information you will need to obtain permission from the copyright holders concerned.
This publication is available at https://www.gov.uk/government/publications/government-response-on-software-resilience-and-security/government-response-to-the-call-for-views-on-software-resilience-and-security-for-businesses-and-organisations
Ministerial foreword
Software is the lifeblood of the digital economy. It underpins all of the digital services we rely on, driving productivity and growth across the UK. However, increasing organisational use of and reliance on software has increased its appeal to malicious actors. These actors may want to extort money from organisations through ransomware attacks or could be aiming to disrupt services or steal information on behalf of a hostile state. High-profile incidents have illustrated the impact that insecure software has on businesses and organisations. In June 2023, a cyber-attack on MOVEit file transfer software, which is widely used by businesses for common business operations such as payroll, allowed hackers to access personal details of staff and employees at a wide range of UK organisations, and only last year NHS 111 services were impacted by an attack on Advanced software.
Software insecurity poses a huge risk to the resilience and security of UK organisations, and by extension to the services which UK citizens rely upon on a daily basis. Organisations and businesses in the UK face a complex and dynamic cyber security landscape. 32% of UK businesses have experienced a cyber breach or attack in the past year, with this increasing to more than 50% of medium and large businesses. Strengthening security across the software lifecycle will be key to minimising the opportunities malicious actors have to compromise organisations, and can also limit the scale of the damage when attacks do occur.
We must ensure that the foundations of software security are in place, so that we are able to react quickly to challenges posed by new and emerging technologies, such as artificial intelligence. These technologies pose their own distinct cyber security risks, but cannot be addressed unless we get the fundamentals of cyber security right. Almost all current and emerging technology relies on software to function. Establishing a baseline of clear expectations for software security across our economy will be key. We also need to ensure that UK organisations know how to hold software vendors to these expectations, and make use of these incredible advances safely and securely.
To this end, I am pleased to publish this government response to the call for views on software resilience and security for businesses and organisations. This response sets out a package of policy interventions that the government intends to take forward in the coming months and years. These interventions will empower organisations who develop, sell and buy software to better understand their responsibilities and take action to reduce risk, thereby improving standards of software security throughout our supply chains.
Our proposed Code of Practice for software vendors will set out the security obligations for organisations that sell software commercially. It will place clear responsibilities on those best-placed to meet the software security challenges affecting our supply chains; namely, those organisations profiting from the sale of software rather than unpaid open source developers or customers. This will be accompanied by interventions offering additional support and guidance to help suppliers meet these expectations, as well as further resources and accountability mechanisms for customer organisations to use in their procurement and maintenance of software. The package also includes additional provisions for high risk contexts such as government and critical national infrastructure, to ensure that the UK’s most essential services and systems are appropriately protected.
I would like to thank all of the organisations and individuals who shared their views on this critical issue. Your contributions have been crucial to shaping Government’s approach to software resilience policy, and helping us understand what organisations need in order to improve software security throughout supply chains. We will continue to collaborate closely with academia, civil society and the private sector to ensure that our interventions are proportionate, feasible and effective.
Viscount Camrose
Minister for AI and Intellectual Property
Department for Science, Innovation and Technology
1. Executive summary
In February 2023, the Department for Science, Innovation and Technology (DSIT: formerly the Department for Digital, Culture, Media and Sports) published a call for views to better understand the range of risks linked to software, what is already being done to manage the associated risks, and to seek views on what further government action would be most effective at driving improvements. Since then, the new Department for Science, Innovation and Technology was created to cement the UK as a Science and Technology superpower, including strengthening the UKs cyber security and resilience. The cyber security landscape has also continued to shift, with governments across the world raising questions about the security implications of Artificial Intelligence (AI). In November, the UK held the world’s first AI Safety Summit to engage industry and international partners to examine the security implications of AI.
Software-based cyber attacks continue to affect hundreds of organisations across the UK, and recent, high profile attacks such as the breach of the file transfer software, MOVEit, demonstrate the urgency and importance of improving software security at scale in order to improve cyber resilience in all technologies across all sectors of the UK
The call for views ran for 12 weeks from 6 February to 1 May 2023, during which time the government engaged with over 200 stakeholders from a wide range of organisations and sectors through a variety of workshops, webinars and bilateral meetings. Submissions to the call for views were received from 136 software vendors, developers and customers, academics, insurance bodies, cyber security experts and other industry stakeholders. This breadth of views has formed the basis for the analysis, and has shaped the government’s approach to software security and resilience moving forward.
This document provides an overview of the responses to the call for views and the key themes that emerged, as well as outlining the government’s response to the views heard. It also sets out the government’s proposed approach to improving software security and resilience across the UK. This package of policies is aimed at raising the baseline expectations of software security to improve resilience to cyber threats across the economy.
Proposed interventions: policy framework
As displayed in Figure 1 below, the policy measures set out in this government response collectively aim to address three key themes that emerged through the call for views:
- Setting clear expectations for software vendors - Government will clearly outline the levels of secure practices that organisations creating and selling software should meet as standard. This should include minimum expectations for: securing code and the build environment; distributing software securely; communicating appropriately with customers; and responding adequately to incidents and vulnerabilities.
- Strengthening accountability in the software supply chain - the purchasers of software need to be better able to hold their software suppliers accountable through procurement and contractual requirements, a core aspect of which is facilitated through greater transparency. To do this, organisations procuring software need both accountability mechanisms as well as an understanding of their own security posture and need to be able to effectively manage risks.
- Protecting high risk users and addressing systemic risks - as government deals with sensitive information and delivers key services to citizens, it is vital that government takes appropriate steps to understand and mitigate risks in government systems and supply chains. There are also systemic risks, for instance the resourcing constraints faced by the open source community, that could have a considerable impact on the UK society if exploited within critical supply chains. To address these systemic risks and protect critical supply chains, it is important that government departments lead by example by modelling best practice in software development and holding government suppliers to high standards of software security.
Addressing these three themes collectively will seek to ensure the suite of measures achieves the required impact on the baseline security and resilience of software at development, sale and deployment.
Alternatives to rule-based regulation can be more flexible and amenable to highly innovative and changing environments. Therefore, a new voluntary code of practice for software vendors will form the heart of the policy framework, leveraging existing national and international standards. This code will make clear the requirements expected in secure development, as well as transparency and communication with their customers. By setting expectations for vendors, we will be raising the baseline level of security practices in commercial software development from the outset. The code of practice would also be a helpful indication for organisations procuring software of what levels of security they should reasonably demand from their suppliers as standard.
Rather than immediately imposing regulation to ensure uptake, the code will be supported by a suite of accountability measures, driven by customers and buyers of software, as is demonstrated in Figure 1. Organisations who buy software will play a key role in delivering accountability through using their purchase power to drive market change, and enforcing higher levels of security through contractual agreements. This will work in conjunction with, and complement, the National Cyber Security Centre’s excellent guides for small businesses and SMEs for approaching cyber security. Government, equally, is a major purchaser and developer of software, and by ensuring our own standards are high, we can set a clear benchmark for developers and purchasers of software to follow.
The proposed measures are set out below, according to the three key themes above, and are covered in greater detail in the following sections of this government response. Following close monitoring of uptake and improvement in software security, government will undertake a review of the impact they collectively have had and consider the need to regulate high risk vendors and developers in light of continued security risks, at a later stage.
Figure 1: The government’s proposed policy approach to improving software security and resilience across the UK
1.1 Scope
This approach focuses on the development and use of software, rather than the technology itself in which the software is being deployed. Software is a general purpose technology and its uses cut across varied purposes.
Software vendors
The policy package outlined in this document aims to address software risks at scale by focusing primarily on those who are most able to impact on the security and resilience of software. For this purpose, there is a strong focus on the actions of those who sell software, namely software vendors and resellers, many of whom also develop software (henceforth referred to collectively as software vendors). We are including software-as-a-service and platform-as-a-service providers in the scope of this definition, as they are involved in selling and maintaining software for organisations in the UK. We also aim to take a holistic approach that considers the wider context in which software vendors and resellers operate, including their use and absorption of free and open source software components within and alongside proprietary software. The policy package also aims to support the software industry to develop the skills and tools required and to support software customers in holding their software vendors accountable for their security actions.
Software types
Through this work, government aims to address the most pressing issues affecting the security and resilience of software across the UK economy. For that purpose, we have focused on the issues affecting software used by businesses and organisations rather than in general use by consumers. A cyber breach linked to software used by businesses and other organisations has the potential to multiply across digital supply chains and is likely to also impact their customers, which may include critical national infrastructure, government systems, and individual consumers.
This proposed package of measures aims to address some of the largest and most impactful issues that are common across all major types of software - enterprise, productivity, app development and system infrastructure. We intend for these measures to raise the baseline level of security and resilience for software used by and sold to businesses and organisations.
Technology evolves at a rapid pace, but the vast majority of existing and emerging technologies (including AI) have software at their foundations. As such, software resilience is fundamental to securing a wide range of technologies with different applications. In taking this approach, our software policy package will also be technology neutral in that it will help to improve the cyber security of any product or technology that is based on software, but will not address any issues specific to individual technologies or sectoral use cases. For example, by establishing good software security practices through our proposed policy package, we will help to ensure that the code that underpins AI technologies is more secure. However, this work will not address the specific risks and opportunities that are unique to AI. Likewise, this work will further support the aims of existing government policy on technologies such as Internet of Things (IoT) devices and app stores by improving the security of software that is used in these technologies, without addressing issues specific to these use cases. Furthermore, the policies laid out here represent general recommendations for software sold across the economy, whereas additional requirements may be necessary in certain sectors, such as the work underway by the Department for Health and Social Care and the Medicines and Healthcare Products Regulatory Agency to review requirements for software and AI as a medical device. Linkages to existing and future technology policy will be articulated throughout the detailed design and implementation of these policies.
1.2 How does the growth of AI affect this policy area?
One of the key themes from our engagement with stakeholders was the impact that artificial intelligence (AI) will have on a wide range of software-related developments. At its core, AI is a type of software. ‘Traditional’ software and AI software have various similarities and distinctions. While ‘traditional’ software performs a predetermined task, AI software learns to perform the task through programming. Consequently, AI offers unique opportunities and challenges going forward, and respondents were enthusiastic that government should engage with industry to address future security impacts in this space. We know that AI is already being used in malicious cyber activity, and that AI will accelerate the volume and impact of these attacks going forward.
Just like the software development lifecycle, AI systems are vulnerable to both intentional and unintentional failures, including those relating to the software code within those AI systems. Intentional failures amount to malicious attacks, where adversaries subvert machine learning systems to undermine the results, or to gain access to the algorithm, ultimately having an impact on the system’s (i) confidentiality, (ii) integrity, or (iii) availability. As well as this, unintentional failures, such as those seen in software development, also create significant vulnerabilities. Consequently, the government is keen to engage with industry to better understand how secure by design approaches can be implemented in the AI lifecycle, with a particular focus on foundation models. This echoes the approach we are taking with our broader proposed policy package on software resilience and security laid out in this publication, as well as the approach taken to secure IoT products in the recent Product Security and Telecoms Infrastructure Act.
It is vital that, from a policy perspective, the meaningful differences between traditional software and artificial intelligence systems are thus reflected and understood. Government is gathering evidence to better understand this relationship.
Commonalities:
AI and traditional software commonalities
Just as software code is vulnerable to malicious actors during the design phases, the security of AI models, particularly during the early development and deployment of AI models, are at risk of being compromised and manipulated. Traditional security threat mitigation is more important than ever and the code of practice for software vendors will be essential to establishing a security foundation for AI embedded in software domains across a wide range of technologies and sectors. Like software, AI should be secure by design, resilient to attack when deployed, and the development environment itself should be secure from compromise. Ensuring AI systems are resilient to attack once deployed, as addressed below, differs in several ways to traditional software. However, the core principles of the proposed Software Code of Practice for Software Vendors will aim to improve the resilience of the software, including those software elements that underpin AI systems.
AI-generated traditional software code
AI-generated code is consistently improving and is helping developers to write and produce code more rapidly, as well as debug human and AI-generated code. This gives developers more time to focus on more complex tasks and takes away a large brunt of the work required to develop simple code. However, AI is only as good as the rules it learns. Just as humans learn and repeat poor practices, so an AI system trained on poor development practices can repeat poor practices, such as not incorporating appropriate checks on third party code. The code of practice for software vendors proposed here aims to ensure foundational practices of checking and testing code, whether developed by humans or AI, are integrated into the software development process.
Differences:
While traditional secure software development practices, such as those covered by the proposed code of practice, are critical, they will not be wholly effective or sufficiently mitigate the AI threat landscape. This is because software programming tools used to understand where ‘traditional’ software code may be faulty cannot be applied to all aspects of AI models. AI-specific mitigations will be required to address AI security that go beyond software resilience. These include:
- Software testing methodologies and standards used for non-AI systems are inadequate to address the testing required for AI. AI development and programming differs from traditional software programming in several ways: while software is programmed to perform a task, AI uses models to learn to perform the task. Unlike in standard software, where the logic is defined by a human, AI, by definition, involves a system defining its own logic based on the training data. That makes data a key asset and vulnerability in a way that is different from standard systems and contributes to the issue of opacity. This makes identifying vulnerabilities and capabilities in a systematic way increasingly difficult.
- Another differentiation for the security of AI programming is its dynamic nature, whereby it adapts to new situations and environments without manual intervention. Changes to its programming, theoretically may or may not be in line with original levels of security designed from the outset.
- The fact that AI models are largely unable to differentiate between malicious input and anomalous or unexpected data poses severe security risks, which previously were more easily monitored. When training data is sourced from public datasets and open to third parties, attackers don’t need to compromise datasets to influence AI as they can publicly release data that is already compromised which then is used for model training. Data compromise, in some ways, thereby becomes a much simpler attack than before which requires different mitigations above and beyond those which would be required in traditional software secure development.
- AI algorithms can be challenging to interpret, and the decision-making process is often opaque and difficult to understand. Traditional software developers can produce expected results from code, and identify explicitly the code that is causing issues, for example, which code is producing a vulnerability. However, data scientists and machine learning engineers must tackle and prepare for a wide and indeterminate range of modelling outcomes, which makes developing a secure and resilient AI model particularly challenging.
- In traditional software security, vulnerabilities in one software package typically cannot be exploited in another, different package, designed for the same task. In contrast, research has shown that attacks developed against one AI model can transfer to other models with similar, but not identical functionality.
- It is an open research question as to how vulnerabilities in AI models can be patched without retraining - something that requires significant resources (time, money, and compute) to achieve.
Solutions to these particular security risks are not wholly yet available and industry must be supported and consulted in proactively addressing them in the coming years. As part of the UK’s National Cyber Strategy, the government have been examining the cyber security of AI so we can deliver work to secure AI systems. In collaboration with other countries, we are examining the risk landscape and assessing how industry can be incentivised to prioritise security so that users are better protected. This is a global topic that requires global alignment. We are looking at how to ensure there is effective international alignment and consensus on what effective cyber security of AI looks like. Consequently, the UK hosted the world’s first AI Safety Summit, held in November 2023, and cyber security considerations was an important strand of this event.
Alongside this, the National Cyber Security Centre published principles for the security of machine learning in August 2023 and Guidelines for secure AI system development at the end of November, building on the momentum of the Summit.
In addition, the Centre for Data Ethics and Innovation is developing considerable work on AI assurance and certification. We are also aware of various work in standards development organisations and will be continuing to monitor this.
2. Key themes from the call for views
The call for views emphasised how critical the security of software is to the UK’s organisational resilience. An 86% share of respondents indicated that their organisation would be unable to continue its day-to-day operations for more than 7 days if their essential software could not be used, with 41% being unable to function in less than 24 hours, as shown in Figure 2. These risks are clearly evident across the software supply chain, with 75% of respondents claiming their organisation would be unable to function for more than seven days if one of their critical suppliers could not operate.
Figure 2. Length of continued day-to-day operations
“How long could your organisation continue its day-to-day operations…?”
| Time period | If essential software could not be used? | If critical suppliers could not operate? |
|---|---|---|
| Less than 24 hours | 41% | 38% |
| 1 - 7 days | 44% | 37% |
| 1 - 4 weeks | 8% | 14% |
| 1 month or more | 6% | 10% |
The below themes outline different core risks and opportunities which we heard from stakeholders throughout the call for views. The government’s response to these views is set out underneath each theme.
2.1 Secure software development is key to strengthening the UK’s organisational resilience
As shown in Figure 3, a central and consistent theme throughout the call for views was the need to improve the quality and consistency of secure software development.
Figure 3. Respondent views on the impact software risks may have on their organisation
“To what extent do you think issues in each of the software risk areas outlined above impact the security and resilience of your organisation?’
| Issue | Don’t know | No impact | Low impact | Medium impact | High impact | Very high impact | Respondents |
|---|---|---|---|---|---|---|---|
| a. Software development security: i. accidental vulnerabilities in software | 3% | 1% | 6% | 17% | 36% | 37% | (115) |
| a. Software development security: ii. intentional compromises of software | 4% | 2% | 13% | 10% | 28% | 44% | (114) |
| a. Software development security: i. insecure development environments | 5% | 0% | 11% | 18% | 37% | 30% | (114) |
| b. Barriers in the open source community | 18% | 4% | 23% | 32% | 18% | 5% | (111) |
| c. Security and resilience in the distribution of software | 3% | 2% | 18% | 22% | 34% | 22% | (113) |
| d. Transparency and communication of software material, vulnerabilities | 2% | 2% | 11% | 23% | 30% | 33% | (113) |
| e. Procurement, supplier assurance and supplier management | 4% | 2% | 15% | 24% | 27% | 29% | (112) |
Many stakeholders argued that software vendors - whether small or large organisations - are not financially incentivised to prioritise security when developing software. However, a number of software vendor respondents noted that while customers generally expect minimum security provisions, secure development is rarely a key consideration for organisations purchasing software, meaning that it is not an area which they can invest significant resources into. A majority of respondents agreed that government could do more to influence the market incentives to drive up secure software development.
Respondents identified a wide range of specific risks within software development security and were concerned about the introduction of accidental and intentional vulnerabilities in software code, as well as the security of development environments. Respondents also raised concerns related to specific types of software, such as AI and machine learning.
A number of stakeholders believed that security needs to be a more fundamental part of training and education in software development, in both academic and professional contexts. The role of guidance and frameworks in setting clear expectations was identified as a key means of driving up the level of software security - however, there were differing views on how to best gain assurance against these expectations. Several stakeholders spoke of both the benefits and the challenges of using accreditation and certification, noting that if implemented badly, accreditation can incentivise worse security behaviours while also being costly and burdensome.
2.2 Government response
The government recognises the critical role that software vendors and developers play in maintaining the UK’s organisational security and resilience. Government has already taken steps to ensure secure software development in specific areas, such as the Code of Practice for App Developers and App stores, and requirements for connected devices to be secure by design in the Product Security and Telecommunications Infrastructure Act. However, it is also clear that levels of security are inconsistent, and that government can play a role in driving the uptake of good software security practices across the full spectrum of software development.
To address this, we will be publishing a code of practice for software vendors. A code of practice for software vendors (including those who develop software) will provide a clear and unified approach to ensuring software developed for any variety of uses and any variety of technologies will be more secure. It will also highlight the importance of clear communication with customers in order to facilitate risk management and incident response. This code will make it clear what is good practice in terms of responsible and secure software development, and is at the heart of the suite of measures being taken forward to respond to the evidence and views gathered throughout the consultation.
Provisions relating to secure software development may include:
- The use of suitable existing secure development frameworks for software and formal standards, as well as following secure by design principles wherever possible.
- The appropriate security testing of all third party software code incorporated during development.
- Clear expectations for communication and information sharing on incident and risk management between customer and vendor.
- Regular vulnerability testing and reporting as part of a rigorous risk management lifecycle process.
This work takes into account the fact that the majority of software vendors operate internationally, and the UK is only one of many markets in which they operate. The code of practice will, as much as possible, be aligned with relevant international approaches and existing standards in this space, such as the US government’s Secure Software Development Framework[footnote 1] and relevant sectoral or international standards. We will continue to engage with and influence international standards in this space, and build on the foundations these provide, particularly around emphasising expectations around transparency and communication between vendors and their customers.
We also acknowledge that there are many specific risks associated with certain kinds of software.[footnote 2] The code of practice will act as a foundation which government can build upon with targeted interventions that address security risks associated with specific technologies. This will contribute to a unified approach to ongoing and future government work strengthening the security of technology such as apps (via the recent Code of Practice for App Stores and App Developers), or artificial intelligence (as set out in the AI Governance White Paper, published in March 2023, and being explored further through ongoing policy work).
The code of practice will also be the foundation for additional policies to promote greater accountability of software vendors. This will enable vendors to demonstrate they are meeting best practice and make it easier for customers to make risk-based decisions depending on suppliers’ security posture. We will work closely with industry to design and test policies to promote greater accountability to ensure that these policies provide customers with sufficient assurance and incentivise vendors to follow good security practices appropriate to their organisation. These policies may include a self attestation model and/or an accreditation scheme against the code of practice.
Government will also support ongoing work to ensure that the UK’s cyber workforce possesses the necessary software security and secure development skills. In this space, the government is currently working on two interventions. The first is being taken forward by the National Cyber Security Centre to address software security skills in university education, and the second is focused on professional skills in the work force and is being led by the UK Cyber Security Council and Department for Science Innovation and Technology:
- The National Cyber Security Centre is currently exploring the feasibility of expanding their existing certification programme for undergraduate and postgraduate degrees. The aim could be to recognise those degrees that sufficiently address secure software lifecycle and software security. The existing certification of university degrees assesses universities for their coverage of the Cyber Security Body of Knowledge (CyBOK) Knowledge Areas – this currently applies to close to 80 postgraduate and undergraduate degree courses across the UK. However, compared to other CyBOK Knowledge Areas, secure software lifecycle and software security are rather underrepresented in National Cyber Security Centre certified degrees. Preliminary analysis shows that these Knowledge Areas are also not well represented in undergraduate degrees in computing. A new National Cyber Security Centre certification standard would recognise university degrees that provide sufficient coverage of these skills, and would be developed in line with the expectations for software resilience set out in this policy package.
- The UK Cyber Security Council is developing professional standards for cyber security and will be able to grant Professional Titles (including Chartership) based on those standards. This will make it easier to determine the quality of cyber security professionals in the market. The Council is developing standards for a range of cyber security specialisms, and recently launched professional standards for Governance and Risk Management and Secure System Architecture and Design. The Council is considering launching further standards in areas such as vulnerability management. Ensuring that those responsible for developing and maintaining secure software have the relevant skills will be fundamental to the success of the government’s proposed code of practice for software vendors and other interventions.
2.3 Improved management of free and open source software could help protect organisations while still ensuring they benefit from its innovation and efficiency, and there is a role for government to support a focus on security within the open source community
The views shared about risks associated with open source software were more measured, with respondents identifying barriers to security in the open source community as the least high impact of the risks outlined in the call for views (see Figure 3). However, nearly a quarter of respondents (23%) still believed that barriers to resilience in the open source community posed a high or very high risk to their organisation’s security, and qualitative feedback suggested that vulnerabilities and malware stemming from open source software components remain a key systemic risk in the software ecosystem. In addition, around a third of respondents (32%) believed that barriers to resilience in the open source community posed a high or very high impact to the wider UK economy (Figure 4).
Figure 4: Respondent views on the impact software risks may have on the UK economy
“To what extent do you think issues in each of the software risk areas outlined above impact the security and resilience of the wider UK economy?’
| Issue | Don’t know | No impact | Low impact | Medium impact | High impact | Very high impact | Respondents |
|---|---|---|---|---|---|---|---|
| Software development security: i. accidental vulnerabilities in software | 4% | 0% | 9% | 11% | 33% | 44% | (103) |
| Software development security: ii. intentional compromises of software | 5% | 0% | 7% | 11% | 23% | 54% | (103) |
| Software development security: i. insecure development environments | 4% | 0% | 9% | 25% | 25% | 38% | (101) |
| Barriers in the open source community | 19% | 1% | 16% | 33% | 22% | 10% | (101) |
| Security and resilience in the distribution of software | 3% | 1% | 9% | 28% | 27% | 31% | (102) |
| Transparency and communication of software material, vulnerabilities | 3% | 1% | 10% | 25% | 32% | 29% | (102) |
| Procurement, supplier assurance and supplier management | 5% | 2% | 10% | 25% | 26% | 33% | (112) |
| Maintenance, configuration and use of the software by the customer | 5% | 1% | 11% | 16% | 31% | 36% | (98) |
Up to 90% of software contains free and open source components, and their maintenance, as well as the use of unmonitored third party open source libraries, were both identified as major barriers to wider development security.[footnote 3] Our reliance on free and open source software is such that its resourcing of maintenance and security is a crucial challenge to address if we are looking to improve the resilience of software supply chains.
Many respondents emphasised that open source software was an essential part of the innovative software development ecosystem and stressed that any action taken should be supportive of the open source community, and not seek to hinder the high levels of innovation stemming from open source software development. Figure 5 shows that, out of the policy proposals provided, more than 80% of respondents (a total of 86 for this question) agreed that all proposals would be either somewhat or very effective at helping to address risks in open source development. In particular, 92% of respondents viewed funding industry led initiatives as being a very or somewhat effective measure for addressing risks specific to open source development.
Figure 5: Respondent views on how effective government interventions would be in addressing risks relating to open source.
“To what extent do you think the following government interventions would be effective in addressing risks specific to open source software development?”
| Intervention | Don’t know | Not all effective | Somewhat effective | Very effective | Respondents |
|---|---|---|---|---|---|
| Guidance on how to increase secure development of software in the open source community | 3% | 16% | 56% | 24% | (86) |
| Funding for industry-led initiatives (e.g. those aimed at maintaining critical open source components or those that develop security tools for use by the open source community | 5% | 3% | 43% | 49% | (86) |
| Develop government-backed teams dedicated to maintaining critical open source software components and to support remediation of incidents affecting critical software | 6% | 14% | 38% | 42% | (86) |
| Work with industry to develop mapping tool to understand which open source components are most critical | 2% | 10% | 48% | 40% | (86) |
Nevertheless, concern was expressed about how effectively organisations test and maintain open source components when they use open source code in the development of new software products and services. Government’s use of open source code also emerged as a theme, with several respondents suggesting that the government’s use of open source software is often inconsistent with best security practices. Overall, stakeholders agreed that more is needed to understand the risks associated with using open source components in software development, and that the UK should continue to engage in this discussion at an international level.
2.4 Government response
Free and open source software is an essential part of the software ecosystem, and one of the major contributors to innovation in the sector. Respondents were clear that government should focus on supporting the open source community to address security challenges in a way that does not stifle creativity and innovation. As such, we are not currently considering introducing additional requirements on open source software developers and maintainers for how they should develop or maintain open source software code. Instead, we intend to focus on the responsibilities of organisations that incorporate free and open source code into their own software that they then sell.
Checking the safety of third party code (be it free and open source or proprietary) should be a key step in the development practices of organisations that develop and sell software, as well as managing any risks or vulnerabilities that may arise in relation to that code. The Code of Practice for Software Vendors will underline the expectation that vendors who incorporate or use free and open source software in their products or services hold responsibility for ensuring that the code is safe and secure.
The aim of the code of practice will be to improve the uptake of good secure development practices such as the proper management of third party code. In doing so, the government aims to reduce the impact of vulnerabilities or malicious code spread through open source projects and repositories. Another key aspect of the concerns around securing free and open source code is the resourcing of open source maintenance and vulnerability management. This is a significant challenge due to the reliance on voluntary participation for the important work of updating, fixing and maintaining open source components and securing and managing repositories.
We recognise that industry is already making inroads into improving the security of free and open source software at source. Private sector organisations, open source foundations and advocacy groups with expertise in free and open source software security are introducing initiatives, tools and guidance to support the open source community in developing and maintaining code securely. Much of this work aims to provide greater resources, including channelling funding and providing new tools or assurance schemes, to the open source community. This work is making good progress but is far from complete and the impact free and open source software has on our global supply chains means that this is a challenge faced by organisations not only across the nation but also globally. Because of the far-reaching impact of free and open source software resilience, government is exploring how it can best support the open source community without duplicating the effective work of industry, or pre-existing government measures which support the reporting of software vulnerabilities, such as the US’ National Vulnerability Database. In particular, we are exploring how government could help by channelling additional resources into the open source community.
Government’s role in supporting the resilience of free and open source software
Both the public and private sectors benefit from the innovation, adaptability and efficiency of free and open source software. Open source code helps organisations to produce agile and adaptive software, increasing the efficiency of software development. Free and open source software also enables innovative software development at a lower cost to organisations and, for government, at a lower cost to the taxpayer. However, the sensitivity and importance of government and other critical supply chains means that, as with any software or digital products, extra care must be taken to ensure the security of free and open source code used in the software and services that the UK relies on.
To address these risks and ensure consistent high standards, we will explore how the government can lead by example and support the private sector by modelling and promoting best practice for how organisations should use, produce, secure and licence free and open source software. To do so, we will collaborate with industry and the open source community to explore the feasibility of creating a new government initiative designed to address the resilience of free and open source software in the UK’s most critical systems and services. Industry is currently making progress in developing best practice for open source security, licensing and productivity management in the private sector. We are considering how innovative private sector structures and processes might be adapted for use in government, and how learnings from this application in government can be shared with other sectors.
Another aspect of open source resilience is exploring how organisations could or should channel resources into the open source ecosystem. The resilience of free and open source software impacts the entire technology landscape but, due to the reliance on voluntary participation, open source maintenance and security is systemically under-resourced. Without placing additional burden on open source maintainers, government is exploring how this resourcing pressure could potentially be addressed by organisations that use free and open source software. Part of ongoing work will be to explore how government can lead by example in its engagement with the open source community, and we will work with stakeholders to explore potential solutions.
If it is pursued, this initiative would support and build on existing government guidance on in-house development and securing government systems such as those laid out in the Digital, Data and Technology playbook, the Technology Code of Practice and the Government Secure by Design Framework. Together these structures and frameworks would contribute towards key objectives within the Government Cyber Security Strategy, including helping government organisations understand the cyber risks facing them including through its supply chain and supporting them to embed proportionate cyber security measures within the technology they use.
Internationally, other governments have demonstrated the advantages of safely benefitting from their use of free and open source software. The European Commission established an Open Source Programme Office in 2020, and has this year published guidelines for how Commission-built open source software projects should manage contributions from third-party developers. In September 2022, the US government introduced the Securing Open Source Software Act, which would include developing a risk assessment framework for open source components, and the US government has also launched its Open Source Software Security Initiative (OS3I). Germany has established a fund for improving the resilience of certain open source software projects, and other governments are also exploring how to channel resources into the open source ecosystem. There is still significant work needed to identify the most suitable structures for understanding and managing free and open source software resilience across governments and critical sectors, but this exploratory work will be an important first step.
2.5 More transparency is required across the software supply chain
A key issue identified through the call for views was the need to improve transparency and communication of cyber incidents. Respondents frequently highlighted the issue of commercial and reputational pressures that prevented software vendors from disclosing vulnerabilities to the users of their software, and the public. Figure 6 shows that 76% of respondents supported both increased industry and government action in this area, highlighting the need for software vendors to be more transparent about their incident management and overall security strategies.
Figure 6: Respondent views on where government and industry intervention is required to address risks.
“In which of the risk areas do you think there is a need for greater government and/or industry intervention?”
| Risk area | Neither | Government | Industry | Both | Respondents |
|---|---|---|---|---|---|
| Software development security | 2% | 3% | 30% | 65% | (94) |
| Barriers in the open source community | 22% | 10% | 22% | 46% | (91) |
| Security and resilience in the distribution of software | 4% | 4% | 31% | 60% | (90) |
| Transparency and communication of software material, vulnerabilities and incident management | 2% | 11% | 12% | 76% | (94) |
| Procurement, supplier assurance and supplier management | 4% | 13% | 22% | 61% | (93) |
| Maintenance, configuration and use of the software by the customer | 14% | 3% | 33% | 51% | (95) |
Overall, a majority of respondents believed that government interventions would be effective in strengthening transparency and communication in software supply chains - with more than 80% of respondents arguing that each of the proposed interventions would be somewhat or very effective (Figure 7). In addition to the proposed interventions, a number of stakeholders argued for the establishment of reliable security and transparency metrics which allow companies to demonstrate that good practice was being followed.
Figure 7: Respondent views on government interventions relating to transparency and communication.
| Intervention | Don’t know | Not all all effective | Somewhat effective | Very effective | Respondents |
|---|---|---|---|---|---|
| Technical guidance on Software Bill of Materials (SBOMs) and comparable tools | 1% | 11% | 47% | 40% | (87) |
| Guidance on best practice in promoting transparency (e.g. attestation, code of practice for vendors, recommended contractual clauses etc | 1% | 7% | 54% | 38% | (85) |
| Certification of software developers and vendors who adhere to best practice in promoting transparency | 2% | 15% | 36% | 46% | (85) |
| Establish secure mechanisms to share information on vulnerabilities and malicious code between software | 6% | 7% | 30% | 57% | (87) |
| Develop a secure central database of SBOMs that can be queried to inform risk or vulnerability management and responses to incidents | 7% | 10% | 34% | 48% | (87) |
| Develop regulation that requires software developers and vendors to meet a minimum standard of transparency | 3% | 10% | 35% | 51% | (86) |
Qualitative feedback from several stakeholders noted that there were significant commercial and business pressures on vendors that prevented them from disclosing where there had been a breach, and where their software had become vulnerable. Fear of penalisation, reputational damage and loss of custom can deter businesses (especially smaller vendors) from reporting software vulnerabilities, and respondents agreed that more should be done to ensure that organisations disclose information quickly to stop the spread of infection.
Many respondents also shared their views on Software Bills of Materials (SBOMs). An SBOM is an inventory of all of the components that make up a software package. This helps users better understand the open source and third party components that may be present in a software package. Overall, stakeholders saw the value in using SBOMs in specific circumstances, but many suggested that SBOMs are not sufficient in themselves to ensure transparency or security of software components. Several stakeholders challenged the premise that transparency was something to be pursued in all cases, noting that the scale and complexity of information (e.g. in software source code packages) often means that businesses and end customers are unable to interpret information provided. Overall, a clear majority of respondents (87%) thought that government guidance on SBOMs and comparable tools would be either somewhat or very effective.
2.6 Government Response
The government agrees that there are key barriers to transparency in software supply chains, and that more must be done to address them. Transparency plays a key role in driving accountability across the software ecosystem, as customers cannot hold software vendors to account if they are not provided with the information required to do so. This is particularly crucial for smaller organisations who might have fewer resources dedicated to cyber security, or do not feel they have sufficient negotiating power to request more information from software vendors.
Transparency is also key to enabling the effective management of security incidents. The complex nature of software supply chains makes software a possible attack vector for malicious actors to quickly spread malware to many organisations. It is critical that organisations are able to quickly react to incidents, and fix vulnerabilities when they have been identified. While many organisations do communicate this information quickly through their supply chains, there must be more consistency.
The Code of Practice for Software Vendors will include requirements which address both of these issues and promote increased transparency and communication. This will include provisions which address the communication of incidents with customers, and the need to collaborate with customers following an incident to ensure they remain protected. In order to further reduce barriers to transparency and accountability, we will also develop policies to increase the level of assurance. We will work closely with industry partners to explore potential supporting policies to drive uptake, such as an accreditation scheme. If pursued, the intention of an accreditation scheme or other assurance-based policy would be to make it easier for customers to identify which suppliers adhere to good practice, as outlined in the code of practice.
The government also recognises that SBOMs are being increasingly used in many settings. However, we have also clearly heard from stakeholders that they are still a nascent tool and are only useful for organisations procuring software in specific contexts. It is often only organisations that already have high levels of cyber security maturity that are able to effectively respond to and act upon the information provided through a SBOM. On the other hand, they are a helpful tool for organisations developing software to track dependencies and keep a record of software components in their software products. This helps with managing vulnerabilities and speeds up remediation times. In order to support the proportionate use of SBOMs as one potential tool to create greater transparency, government will work with the National Cyber Security Centre to publish content for organisations on how and when to use SBOMs.
2.7 There is a need to strengthen accountability in the software supply chain
Overall, the majority of respondents felt more clarity is required to establish stronger accountability for software security in the supply chain. Some respondents suggested that software developers often deprioritise security due to lack of skills or for commercial reasons. Several argued that software resellers and vendors should be held more accountable for security given their key position in the software lifecycle, linking developers with end users.
Many respondents agreed that the procurement of software is a key process in determining where accountability should lie. In procurement processes, the grounds for vendor or customer liability may depend on several factors, including whether the software is custom-produced or sold for general purpose. Respondents were of the view that procurement contracts are generally the clearest and most effective method of defining accountability between vendor and customer.
A key theme across a range of respondents was a need for improved cyber awareness and skills among customers to ensure that they are able to hold suppliers to account. If customers have the knowledge base to ask the right questions when procuring software, then they will be able to drive higher standards in the market. This is especially important in both supplier selection and contract management processes, where respondents often noted there are significant information asymmetries between the software vendor and the end customer. Figure 8 shows that only 72% of respondents included cyber security requirements in their contracts with suppliers, and several stakeholders indicated that this number would be much lower for customers across the entire economy. However, as this question was only asked of software developers, vendors and resellers, only 25 respondents answered this question.
Figure 8: Ways in which organisations implement security in their selection of suppliers.
“Which of the following security controls and processes does your organisation implement?”
| Control | |
|---|---|
| Require suppliers to hold certification (e.g. Cyber Essentials) | 40% |
| A questionnaire to assess supplier risk | 64% |
| A requirement for suppliers to implement some or all of the controls listed above | 64% |
| Cyber security requirements and/or responsibilities included in contracts with suppliers | 72% |
| A requirement for software suppliers to adopt good development practices | 65% |
Figure 9 highlights that 93% of respondents (77 out of 83 who responded to this question) believed that government training resources aimed at procurement and contract professionals would be somewhat or very effective at helping to mitigate risks in procurement processes. Many respondents also noted that government could use its own buying power to play a role in strengthening accountability in the software industry, noting that the US government has been successfully driving cyber security standards through this.
Figure 9: Respondent views on government interventions aimed at addressing procurement risks.
“To what extent do you think the following government interventions would be effective in addressing cyber risks linked to software procurement, supplier assurance and supplier management?”
| Intervention | Don’t know | Not all effective | Somewhat effective | Very effective | Respondents |
|---|---|---|---|---|---|
| Tools to help businesses implement guidance on securing their own supply chains (e.g. recommended clauses to include in contracts | 2% | 6% | 51% | 41% | (83) |
| Training resources aimed at procurement and contract management teams | 2% | 5% | 57% | 36% | (83) |
| Work with industry to develop and promote tools that support businesses in securing their own supply chains | 5% | 4% | 42% | 49% | (83) |
However, several respondents gave examples where, despite having well informed procurement processes and clear security requirements in their contracts, their suppliers still did not meet the required security standards. Stakeholders from customer organisations often shared challenges they had faced when trying to verify the security of a software supplier, with many software vendors being resistant to sharing information about their supply chains or security practices. Some argued that the concentrated software market is a barrier to this, as only a few major suppliers comprise a significant market share, making it difficult for customers to demand change.
A majority of respondents suggested that more needs to be done to ensure customers are able to hold vendors accountable - with 90% of respondents identifying regulation of software vendors as a very or somewhat effective driver of compliance (Figure 10). However, many stakeholders noted the importance of taking a proportionate approach, and expressed concern about the cost burden placed on small businesses. Others pointed to the global nature of software supply chains and noted that alignment with international regulation will be key to ensure an effective global approach to this issue. There was, however, greater support for vendor attestation to help simplify procurement processes and improve customer assurance.
Figure 10: Respondent views on the efficacy of government intervention to address risk linked to software vendor actions
“To what extent do you think the following government interventions would be effective in addressing cyber risks linked to the actions of those who sell or resell software or software licences, or those who manage software services?”
| Intervention | Don’t know | Not all effective | Somewhat effective | Very effective | Respondents |
|---|---|---|---|---|---|
| Tools to help businesses implement guidance on securing their own supply chains (e.g. recommended clauses to include in… | 5% | 20% | 56% | 20% | (86) |
| Training resources aimed at procurement and contract management teams | 5% | 12% | 48% | 36% | (86) |
| Work with industry to develop and promote tools that support businesses in securing their own supply chains | 3% | 7% | 42% | 48% | (88) |
2.8 Government response
A significant number of respondents were supportive of introducing regulation of software vendors to drive compliance. However, government sees regulation as an avenue to explore if other, softer policy levers are insufficient. At present, the only accountability mechanism available to organisations procuring software are procurement contracts. Along with the code of practice, there is more work that government can do to increase market demand for security before reviewing the need for regulation in this space.
In order to increase accountability in the software market, all participants need to have the information required to hold each other to account. UK businesses often rely on a wide range of different software products, and the government recognises the challenges which customers can face in trying to verify the security practices of their suppliers. Cyber Essentials and Cyber Essentials Plus are helpful tools for assessing suppliers’ cybersecurity practices more generally but, when procuring software, organisations require more specific information about the software products and services supplied and how they were developed. In order to help organisations manage these challenges, government, in collaboration with the National Cyber Security Centre, will be developing cyber security training aimed at UK procurement professionals. Procurement professionals are key actors in creating clear accountability in the software market, particularly through contracts.
Government is also committing to developing standardised procurement clauses that will be available for organisations working across all sectors of the economy to put into their contracts with software suppliers. These clauses will help to create a consistent software ecosystem for both customers (who will be able to more easily make consistent requests for security information from their suppliers) and software vendors (who will be able to more efficiently adhere with consistent requests). This will also allow organisations of any size, including those without dedicated procurement professionals, to easily include clear cyber security requirements in their contracts with suppliers.
The standardised clauses will be based on the requirements of the Code of Practice for Software Vendors. For the code of practice to be effective, customers need to be able to identify whether vendors are meeting it or not. Alongside standardised clauses, accreditation may be an effective way of allowing customers to more easily hold their software suppliers to account. However, we recognise that accreditation can have adverse consequences if implemented poorly, and will work closely with stakeholders to understand whether it would be practical.
We also recognise the power which government has to stimulate change by holding its own suppliers to account. We are therefore working with the Cabinet Office and Crown Commercial Service to explore the creation of minimum security requirements for software suppliers to government.
2.9 Government must play a collaborative role
Overall, a clear majority of the respondents were in support of further government action to address the risks associated with software. Regulation was identified as a particularly effective solution in most risk areas, but respondents also expressed a clear preference for joint action from both government and industry to address these risks. Of those who responded, 98% were in favour of increased government and/or industry intervention in software development security, and improved transparency and communication of software material, vulnerabilities and incident management (Figure 6).
While views were clear on the efficacy of potential regulation, the call for views also highlighted a perception from industry that government should be tentative with any aims to legislate in this area, for fears that this may stifle innovation in what is a fast-paced area of technology. Many respondents were clear that the technical expertise of industry should be present throughout any future government action, and that government should encourage industry to seek solutions before considering stronger interventions such as legislation.
A consistent theme from stakeholders was that an international perspective is key, with almost half of the respondents suggesting that any new regulation must be consistent with other government regulation, and international technical standards. Respondents were also clear that international government collaboration was vital in order to make any policies in this area successful. This could improve the ease of doing business and the sharing of innovative tech with international partners.
From our engagements with industry leaders, academics and the software development community, it is clear that the government cannot do this alone and that collaboration with these partners and stakeholders will be crucial to developing policies that address the cyber risks posed by software in business while maintaining a pro-innovation stance.
2.10 Government response
The interventions that we are exploring will all require collaboration to achieve an effective outcome, and we will ensure that experts in industry, academia and the cyber security are all consulted as these interventions are developed and implemented.
We will be working closely with experts on software development and security from industry, academia and the cyber security community to co-design and ensure that the Code of Practice for Software Vendors is practical. Engagement will be particularly important when considering potential means of driving uptake of the code of practice. We will be taking a collaborative approach when considering potential accreditation of the code of practice, where stakeholder input will be key in determining whether it is a viable means of driving update of the code. The code of practice will be developed collaboratively, and we would continue to engage stakeholders if we decide that legislation is required to enforce the code in future.
The creation of standardised procurement clauses will also require significant engagement with organisations who buy and sell software, as they must be both effective and easy to use if they are to be adopted widely.
We appreciate the global nature of the software market and the risks involved in it, and are actively working with international partners to ensure that our approach is aligned. Wherever possible we will align the provisions of our code of practice with recognised international standards, and we will also engage extensively with other countries who are developing guidance and regulation on software security risks to ensure that we are creating a coherent international regulatory environment.
3. Conclusion and next steps
The Call for Views has identified a range of areas in which government can help improve software security practices and protect the security and resilience of organisations across the UK.
Following the views we have heard, and ongoing engagement with experts from a range of fields, we have identified several key proposals which will begin to mitigate the risks identified, and drive change in the software market. We have identified three key areas of priority moving forwards in this space, which reflect the key themes heard in the call for views:
Setting clear expectations for software vendors - we need secure and consistent standards for companies which create and sell software.
Government will be addressing this through a code of practice for software vendors, which will set clear baseline expectations for software security which will mitigate risks from development to distribution and communication of vulnerabilities and incidents. This code of practice will be voluntary, but we have not ruled out the possibility of legislative backing if industry uptake is insufficient.
Government will help software vendors to meet these new expectations through a range of interventions, including:
- Government will work with the cyber security council to professionalise secure software development.
- The National Cyber Security Centre is exploring the expansion of their certification programme for university degrees to include an additional standard for software security.
- Government is exploring the possibility of providing additional support to industry-led software security initiatives.
Strengthening accountability in the software supply chain - the purchasers of software need to have effective security practices and mechanisms to hold software vendors accountable through contractual requirements.
Government will help software customers hold their suppliers to account by:
- Developing cyber security training aimed at UK procurement professionals, ensuring that organisations are using their buying power to drive improved practices in the software market.
- Creating standardised procurement clauses, for organisations to easily insert into their contracts, reducing the burden for smaller organisations who might have limited resources to commit to procurement of software.
- Working with the National Cyber Security Centre to publish content on the use of Software Bills of Materials, to ensure customers understand how they might use them to assess the security of their suppliers.
Once we have published our code of practice, we will also explore whether accreditation could be a useful means of enabling customers to easily hold their suppliers to account.
Protecting high risk users and addressing systemic risks - public sector software development and use is a particular priority in terms of its higher risk context. It is also important that government leads by example in its own practices in order to support the improvements that our proposed interventions seek to drive across all sectors. Of particular importance will be assessing and improving the resilience of free and open source software which is vital to protecting technologies developed for use in both public and private sector contexts.
The government will take the following actions to protect high risk users and address systemic risks.
The code of practice for software vendors will take clear steps to promote secure development processes in all contexts of software development, by requiring software vendors to take appropriate steps to test any third party components that they incorporate or use. Government is also in a powerful position to be able to drive good practice across the economy by leading by example and also by leveraging its buying power.
In order to support the safe use of software in critical contexts (whether purchased or developed in-house), government will:
- explore the creation of minimum security requirements for organisations supplying software to government. This will help to ensure the resilience of government systems and services and also provide a clear example of security expectations that software suppliers should meet.
- work with industry to incorporate best practice into government and identify which innovative solutions to free and open source risk management from the private sector could be implemented within government.
- explore the development of a government initiative to assess and improve the resilience of free and open source software used in high risk contexts.
Annex A - closed question survey findings and charts
This annex contains charts and quantitative data from responses to all closed questions in the call for views survey. They are provided in this annex to demonstrate full transparency of the quantitative data.
Part 1 - Software risks
Q8: To what extent do you think issues in each of the software risk areas outlined above impact the security and resilience of your organisation?
Figure 1. Respondent views on the impact software risks may have on their organisation
| Issue | Don’t know | No impact | Low impact | Medium impact | High impact | Very high impact | Respondents |
|---|---|---|---|---|---|---|---|
| a. Software development security: i. accidental vulnerabilities in software | 3% | 1% | 6% | 17% | 36% | 37% | (115) |
| a. Software development security: ii. intentional compromises of software | 4% | 2% | 13% | 10% | 28% | 44% | (114) |
| a. Software development security: i. insecure development environments | 5% | 0% | 11% | 18% | 37% | 30% | (114) |
| b. Barriers in the open source community | 18% | 4% | 23% | 32% | 18% | 5% | (111) |
| c. Security and resilience in the distribution of software | 3% | 2% | 18% | 22% | 34% | 22% | (113) |
| d. Transparency and communication of software material, vulnerabilities | 2% | 2% | 11% | 23% | 30% | 33% | (113) |
| e. Procurement, supplier assurance and supplier management | 4% | 2% | 15% | 24% | 27% | 29% | (112) |
Q9: To what extent do you think issues in each of the software risk areas outlined above impact the security and resilience of the wider UK economy?
Figure 2: Respondent views on the impact software risks may have on the UK economy
| Issue | Don’t know | No impact | Low impact | Medium impact | High impact | Very high impact | Respondents |
|---|---|---|---|---|---|---|---|
| Software development security: i. accidental vulnerabilities in software | 4% | 0% | 9% | 11% | 33% | 44% | (103) |
| Software development security: ii. intentional compromises of software | 5% | 0% | 7% | 11% | 23% | 54% | (103) |
| Software development security: i. insecure development environments | 4% | 0% | 9% | 25% | 25% | 38% | (101) |
| Barriers in the open source community | 19% | 1% | 16% | 33% | 22% | 10% | (101) |
| Security and resilience in the distribution of software | 3% | 1% | 9% | 28% | 27% | 31% | (102) |
| Transparency and communication of software material, vulnerabilities | 3% | 1% | 10% | 25% | 32% | 29% | (102) |
| Procurement, supplier assurance and supplier management | 5% | 2% | 10% | 25% | 26% | 33% | (112) |
| Maintenance, configuration and use of the software by the customer | 5% | 1% | 11% | 16% | 31% | 36% | (98) |
Q10: Which, if any, of these risk areas do you see as the biggest problem?
Figure 3: Respondent views on the most problematic risk area
Q12: Are there any other risks that are linked to software but not covered in the risk areas above?
53% of respondents believed that there were other risks linked to the software than those covered in the questions above.
Q14 & Q15: How long could your organisation continue its day-to-day operations if any of the essential software or IT services on which you directly depend could not be used / if one of your most critical suppliers could not operate due to issues with their software?
Figure 4. Length of continued day-to-day operations
| Time period | If essential software could not be used? | If critical suppliers could not operate? |
|---|---|---|
| Less than 24 hours | 41% | 38% |
| 1 - 7 days | 44% | 37% |
| 1 - 4 weeks | 8% | 14% |
| 1 month or more | 6% | 10% |
| Time period | If essential software could not be used? | If critical suppliers could not operate? |
|---|---|---|
| Less than 24 hours | 41% | 38% |
| 1 - 7 days | 44% | 37% |
| 1 - 4 weeks | 8% | 14% |
| 1 month or more | 6% | 10% |
Part 2 - Existing industry measures
Q16a: Do you or your organisation follow specific standards, guidance, frameworks or accreditation schemes for software development?
A large majority of individuals (88%) who worked as a software developer, software and/or system vendor, software and/or system reseller in an organisation reported that their organisation did use some form of guidance for software development.
Q16b: Which of the following standards, guidance and frameworks do you/your company already refer to when developing software?
Figure 5: Respondent views on the standards, guidance and frameworks their organisation uses in software development
Q17: Which of the following standards, guidance and frameworks do you/your company already refer to when developing software?
Figure 6: Respondent views on their organisation’s controls for general cyber security posture and resilience
Figure 7: Respondent views on their organisation’s controls for vulnerability management
Figure 8: Respondent views on their organisation’s controls for software development
Figure 9: Ways in which organisations implement security in their selection of suppliers.
Q18a: Does your organisation refer to existing guidance, frameworks, standards or certifications when procuring software?
A large majority of individuals who worked as a software developer, software and/or system vendor, software and/or system reseller (79% of the 24 who provided a response to this question) reported that their organisation did use some form of guidance for software development.
Q18b: If any, which of the following do you or your organisation already refer to when procuring software?
Figure 10: Respondent views on existing guidance, frameworks, standards or certifications already used by their organisation
Q19: Which of the following controls or processes do you or your organisation use? Controls or processes: i) for selecting software suppliers; ii) to ensure that software is configured and used securely.
Figure 11: Respondent views on their organisation’s controls or processes for selecting software suppliers
Figure 12: Respondent views on their organisation’s controls or processes to ensure secure use and configuration of software
Q20: What are the main reasons for your organisation not implementing further measures to secure the cyber security of your software?
Figure 13: Respondent views on barriers to further secure their organisation’s software
Part 3 - Future government action
Q21: In which of the risk areas do you think there is a need for greater government and/or industry intervention?
Figure 14: Respondent views on whether industry or government should be addressing key risks
| Risk area | Neither | Government | Industry | Both | Respondents |
|---|---|---|---|---|---|
| Software development security | 2% | 3% | 30% | 65% | (94) |
| Barriers in the open source community | 22% | 10% | 22% | 46% | (91) |
| Security and resilience in the distribution of software | 4% | 4% | 31% | 60% | (90) |
| Transparency and communication of software material, vulnerabilities and | 2% | 11% | 12% | 76% | (94) |
| Procurement, supplier assurance and supplier management | 4% | 13% | 22% | 61% | (93) |
| Maintenance, configuration and use of the software by the customer | 14% | 3% | 33% | 51% | (95) |
Q22: Do you think further action is needed to address software risks that are not covered in the risk areas outlined above?
In total, 31% of respondents thought that further action is needed to address further software risks, in addition to the risks areas outlined in Q21.
Q24a: To what extent do you think the following interventions would be effective in addressing cross-cutting or other cyber risks linked to software?
Figure 15: Respondent views on proposed interventions to address cross-cutting risks
Q25: To what extent do you think the following government interventions would be effective in addressing risks linked to secure software development (in both open source and proprietary software contexts)?
Figure 16: Respondent views on proposed interventions to address software development risks
Q26a: To what extent do you think the following government interventions would be effective in addressing risks linked to open source software development?
Figure 17: Views on how effective government interventions would be in addressing risks relating to open source.
Q27a: To what extent do you think the following government interventions would be effective in addressing cyber risks linked to the actions of those who sell or resell software or software licences, or those who manage software services?
Figure 18: Respondent views on the efficacy of government intervention to address risk linked to software vendor actions
Q28a: To what extent do you think the following government interventions would be effective in addressing risks linked to visibility and communication of software materials, vulnerabilities and incident management?
Figure 19: Respondent views on government interventions relating to transparency and communication.
Q29: To what extent do you think the following interventions would be effective in addressing cyber risks linked to software procurement, supplier assurance and supplier management?
Figure 20: Respondent views on government interventions aimed at addressing procurement risks.
Q30: To what extent do you think the following interventions would be effective in addressing cyber risks linked to the ongoing maintenance, configuration and use of software?
Figure 21: Respondent views on proposed interventions to address risks linked to software maintenance, configuration and use
-
NIST Secure Software Development Framework: Recommendations for Mitigating the Risk of Software Vulnerabilities ↩
-
For example, software (including Artificial Intelligence, or ‘AI’) plays an essential part in health and social care. In the UK, many of these products are regulated as medical devices. With regard to regulatory requirements for software as a medical device, please refer to UK Medical Device Regulation and to Regulation (EU) 2017/745 for Northern Ireland, and plans outlined in the Software and AI as a Medical Device Change Programme – Roadmap. ↩
-
The Linux Foundation estimates that Free and Open Source Software (FOSS) constitutes 70-90% of any given piece of modern software. Source: https://www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-open-source-software-application-libraries-the-world-depends-on ↩