NCSC hits vendors with a 14-strong list of secure software best practices - will anyone listen?
It's voluntary, of course...
Security
The UK’s NCSC has published a new voluntary Software Code of Practice.
This spans 14 principles that vendors are “expected to implement to establish a consistent baseline of software security and resilience.”
The NCSC developed the code of practice alongside the Canadian Centre for Cyber Security, with industry input between May and August 2024.
The Code of Practice, sans padding
The NCSC's Software Code of Practice is not hugely technical.
It spans 14 principles split across 4 themes.
Here they are.
1.Secure design and development
These principles ensure that the software is appropriately secure when provided.
The Senior Responsible Owner in vendor organisations shall gain assurance that their organisation achieves the following in relation to any software or software services sold by their organisation:
1.1 Follow an established secure development framework.
1.2 Understand the composition of the software and assess risks linked to the ingestion and maintenance of third-party components throughout the development lifecycle.
1.3 Have a clear process for testing software and software updates before distribution.
1.4 Follow secure by design and secure by default principles throughout the development lifecycle of the software.
2.Build environment security
These principles ensure that the appropriate steps are taken to minimise the risk of build environments becoming compromised and protect the integrity and quality of the software.
The Senior Responsible Owner in vendor organisations shall gain assurance that their organisation achieves the following in relation to any software or software services sold by their organisation:
2.1 Protect the build environment against unauthorised access.
2.2 Control and log changes to the build environment.
3.Secure deployment and maintenance
These principles ensure that the software remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities.
The Senior Responsible Owner in vendor organisations shall gain assurance that their organisation achieves the following in relation to any software or software services sold by their organisation:
3.1 Distribute software securely to customers.
3.2 Implement and publish an effective vulnerability disclosure process.
3.3 Have processes and documentation in place for proactively detecting, prioritising and managing vulnerabilities in software components.
3.4 Report vulnerabilities to relevant parties where appropriate.
3.5 Provide timely security updates, patches and notifications to customers.
4.Communication with customers
These principles ensure that vendor organisations provide sufficient information to customers to enable effective risk and incident management.
The Senior Responsible Owner in vendor organisations shall gain assurance that their organisation achieves the following in relation to any software or software services sold by their organisation:
4.1 Provide information to the customer specifying the level of support and maintenance provided for the software being sold.
4.2 Provides at least 1 year’s notice to customers of when the software will no longer be supported or maintained by the vendor.
4.3 Make information available to customers about notable incidents that may cause significant impact to customer organisations.
Its release comes as government agencies continue to mount pressure on vendors to improve their product security – and as software vulnerability exploits outstrip phishing and credential theft as initial threat vector.
It also comes as governments regularly face having to protect critical infrastructure from the exploitation of vulnerabilities in software and hardware like SSL/VPNs that are ostensibly there to help protect it.
See also: Sophos attackers breached intelligence agency, wrote code to survive firmware updates
Many have been found to be built on extensively vulnerable code bases.
An early 2024 Ivanti appliance tear-down by supply chain security specialist Eclypsium revealed that its Pulse Secure boxes were running an 11-year-old version of Linux that hadn’t been supported since November 2020, as well as numerous (903!) insecure and EOL software packages.
Eclypsium also noted a “a huge security hole in the logic of their script: it excludes over a dozen directories from being scanned, meaning an attacker could theoretically leave their persistent C2 implants in one of these paths and the device will still pass the integrity check…”
(Ivanti’s CEO subsequently promised an improved bug bounty programme and “rigorous threat modelling... embedding security into every stage of the software development lifecycle” among other improvements.)
The Big Interview: Eclypsium CEO Yuriy Bulygin
“‘The Code’ marks the first step in establishing clear expectations for a market baseline with regards to cyber security,” the NCSC said.
“It signals – to both software vendors and their customers – what can reasonably be expected from software suppliers and defines the minimum set of actions that should be in place to ensure products and services are resilient to a cyber attack from a commodity threat. We have tested the efficacy of each of the actions, ensuring they are proportionate to both the vulnerabilities they mitigate and the likely budget available.”
James Neilson, SVP International at security firm OPSWAT added in a comment emailed to The Stack that it was “a clear call to developers and DevSecOps professionals to sharpen their focus on ‘security by design’ through secure design, build, testing, and deployment.”
Whether yet another voluntary code of practice will make the slightest bit of difference in improving upstream software development practices is, politely, an open question. Governments have been deeply resistant to legislating around this issue or mandating behavioural changes for fear of being seen as stymieing innovation and putting pressure on smaller firms that don’t have the resources to tick every box that might need ticking.