Cyber Update: New Software Security Code of Practice

Background

In May 2025 the Department for Science, Innovation and Technology used the government’s flagship cyber security event, CYBERUK, to announce and publish a Software Security Code of Practice and supplementary technical guidance (together the Software Security Code or Code). Developed in collaboration with the National Cyber Security Centre (NCSC), the Software Security Code aims to support software vendors in mitigating software supply chain cyberattacks. While the Code is voluntary, it builds on the 2022 Product Security and Telecommunications Infrastructure Act and associated regulations (PSTI), which mandate baseline security requirements for the manufacturers, importers and distributors of Internet of Things (IoT) devices, including IoT software.

The Software Security Code

The 14 principles under the Software Security Code are separated into four thematic areas: (i) secure design and development; (ii) build environment security; (iii) secure deployment and maintenance; and (iv) communication with customers.

Secure Design and Development

Organisations are encouraged to follow an established secure development framework (such as the NIST Secure Software Development Framework) when engineering software products to reduce the likelihood of error and vulnerabilities when products are first provided to customers. They should also have a clear and regular process for testing software and software updates. The Software Security Code recommends a ‘secure by design’ approach, noting that software vendors should engage in threat modelling, multi-factor authentication for privileged users and updating default passwords in the software toolset. 

The Software Security Code specifically cites the significant increase in the number of cyber attacks stemming from vulnerabilities within the supply chain and suggests software vendors take certain steps to identify and assess the risks associated with third-party components used throughout the development lifecycle of software products.

Build Environment Security

The Code includes principles aimed at securing the build environment, including advising that build environments should be isolated from software vendors development environments. The principles in this area centre on protecting the build environment from unauthorised access by having appropriate user management controls and the retention of auditable logs to assist with understanding and remediation of issues.

Secure Deployment and Maintenance

The Code suggests that software vendors should ensure software is securely deployed to customers given the risks of tampering and spoofing software which can occur during the distribution process. For example, software could be hosted at a trusted central location.

The Code mentions how software vendors could also implement a policy that enables the confident and transparent reporting of vulnerabilities (itself a requirement for IoT devices under PSTI). The NCSC has developed a Vulnerability Disclosure Toolkit which contains an overview of the components required to implement an effective vulnerability disclosure process. This ties in with the Code’s recommendations for software vendors to promptly notify customers, global vulnerability databases, regulatory bodies and third party vendors where vulnerabilities are identified and to monitor public vulnerabilities (including conducting scanning and testing of software, including third-party components, for known vulnerabilities). 

The Software Security Code further advises that software vendors should provide timely security updates, patches and notifications to customers. It notes that updates and patches should not be a premium feature of software, with security fixes provided as standard for a ‘reasonable’ support period.

Communication with Customers

The final thematic section of the Software Security Code considers the approach software vendors should take to ensure customers are provided with sufficient and accessible information in an open and transparent manner. This includes software vendors declaring an end-of-support policy that specifies the length of time software is supported for, and the notice period that will be given if the product containing the software reaches its end of life (which must be at least one year). Again, this builds on PSTI which requires that certain IoT devices must have a published a defined support period.

The Code is clear that customers must be made aware of software issues, their impact and what actions can be taken to remediate, recover from and reduce the likelihood of incidents. The technical guidance suggests notifications of incidents should involve a prompt notification to users as soon as possible in a clear and concise way, communicating what happened, the expected impact and what is being done to resolve it. It should be noted that these principles are additional to the firm incident reporting obligations that may arise for software vendors under legislation such as the UK GDPR and NIS Regulations.

Comment

The Software Security Code provides advice on the practical steps that software vendors can take to reduce risk and facilitate good practice, with much of the detail sitting in the supplementary technical guidance. It indicates the ongoing concerns the Government has on cybersecurity and supply chain vulnerability and forms part of an increasingly large suite of UK and EU cyber guidance (see our recent blog). For example, DSIT are in the midst of a call for views on its draft voluntary UK Code of Practice for Enterprise Connected Device Security which will conclude on 7 July 2025 and may eventually cover the PSTI overlap in further detail. 

While the Code is a useful resource, the fact it does not expressly reference where there are overlapping legal and regulatory requirements (such as PSTI) suggests it is predominantly a practical resource for technical experts rather than aimed at compliance and legal professionals.