As organisations deliver more of their services through software they build and run in the cloud, the security of that software becomes part of the resilience of the business. Weaknesses introduced during development can reach customers quickly, and recent UK guidance and EU legislation set clearer expectations for how software is built and maintained. Boards can ask management how security is built into the organisation's own development work and how it is assured in the software the organisation buys.
What security leaders are reporting
A survey published by Westcon-Comstor in January 2025, of 500 chief information security officers and senior security executives in organisations with at least 1,000 employees across France, Germany, Italy, the UAE and the UK, found that 83% planned to invest in cloud security technologies over the following 12 months. In the UK the figure was 84%. Three quarters of respondents agreed on the need to adopt a DevSecOps approach.
The survey comes from a technology distributor and records intentions, so it indicates a direction of travel. It is consistent with the regulatory developments described below, which give boards firmer grounds for asking how software security is managed.
What DevSecOps means for the business
DevSecOps describes building security checks into each stage of creating and releasing software. Security requirements are set when a feature is designed, code is checked automatically for known weaknesses as it is written, the components the software depends on are tracked and kept up to date, and the systems used to build and release software are themselves protected.
The business case rests on timing. A weakness found while software is being designed or written can be fixed by the team working on it. The same weakness found after release may require an emergency fix, a customer notification or, in some sectors, a regulatory report. Where an organisation releases changes frequently, security checks that run automatically as part of each release help it keep pace with that rate of change.
For a board, the useful test is evidence. Management can show which checks run, how many weaknesses are found and fixed before release, how long serious weaknesses in live systems take to fix, and who decides when a release goes ahead with a known risk.
The rules shaping software security
In the UK, the Department for Science, Innovation and Technology and the National Cyber Security Centre published the Software Security Code of Practice on 7 May 2025. It is voluntary and aimed at organisations that develop or sell software to other organisations. Its fourteen principles cover secure design and development, the security of the environments used to build software, secure deployment and maintenance, and communication with customers. Customers can ask suppliers to self-assess against it or to provide independent assurance.
In the EU, NIS2 includes security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure, among the cybersecurity risk-management measures that essential and important entities must take. The management bodies of those entities must approve those measures and oversee their implementation.
The EU Cyber Resilience Act entered into force on 10 December 2024 and sets security requirements for products with digital elements placed on the EU market, across their lifecycle. Its reporting obligations for manufacturers apply from 11 September 2026 and its main obligations from 11 December 2027. Organisations that sell software or connected products into the EU can use the period before those dates to assess which of their products fall within scope.
International frameworks provide a common reference point for this work. The US National Institute of Standards and Technology's Secure Software Development Framework, published as NIST SP 800-218, describes practices that organisations can map their development processes against.
Software the organisation buys
The same questions apply to software and cloud services the organisation buys. Where a critical business process depends on a supplier's software, a weakness in that software can disrupt the organisation as directly as a weakness in its own code.
The Software Security Code of Practice gives buyers a reference for what to ask. Procurement can request evidence of how a supplier develops and maintains its software, how it handles reported vulnerabilities, how quickly it issues fixes and how it tells customers about security issues. Contracts for critical software can set expectations on those points.
What leadership should require
The board should expect management to know which of the organisation's important services depend on software it builds and which depend on software it buys. For software built in-house, management can describe the security practices applied at each stage, measured against a recognised framework, and report how quickly serious weaknesses are fixed.
For software bought from suppliers, management can show how security is assessed before purchase and monitored afterwards. Where the organisation sells software or connected products into the EU, management can set out its assessment of the Cyber Resilience Act and a plan to meet its obligations by the dates that apply.
Questions for the board
- Which of our important services depend on software we develop, and which depend on software we buy?
- How is security built into our development process, and which recognised framework do we measure it against?
- How long do serious security weaknesses in our live systems take to fix, and is that improving?
- Who can approve a release that goes ahead with a known security risk, and how is that decision recorded?
- How do we assess the security practices of suppliers whose software supports critical processes?
- Do any of our products fall within scope of the Cyber Resilience Act, and what is our plan for the obligations that apply?
- How do we protect the systems we use to build and release software?
Epitechnic's Cloud and Digital Security Governance practice covers DevSecOps governance, including how security controls are built into the delivery pipeline, how vulnerabilities and releases are governed, and the evidence auditors and regulators expect.
References
- Westcon-Comstor, "CISOs plan 2025 cloud security investment", 30 January 2025.
- Department for Science, Innovation and Technology and National Cyber Security Centre, "Software Security Code of Practice", 7 May 2025.
- Taylor Wessing, "UK government publishes Software Security Code of Practice for software vendors", May 2025.
- European Parliament and Council, Directive (EU) 2022/2555 (NIS2), 14 December 2022.
- European Parliament and Council, Regulation (EU) 2024/2847 (Cyber Resilience Act), 23 October 2024.
- National Institute of Standards and Technology, "Secure Software Development Framework (SSDF) Version 1.1", NIST SP 800-218, February 2022.