The UK Department for Science, Innovation and Technology (DSIT) and the National Cyber Security Centre (NCSC) launched the Software Security Code of Practice on 7 May 2025 at CyberUK, the NCSC's annual conference. Announced by the Chancellor of the Duchy of Lancaster Pat McFadden, the Code is voluntary, co-developed with industry, and co-sealed by the Canadian Centre for Cyber Security. It establishes 14 principles grouped into four thematic areas, intended as a baseline that software vendors are expected to implement and that their customers can use as a procurement criterion. The Code sits alongside the existing AI Cyber Security Code of Practice, the PSTI Act regime, and the proposed Cyber Security and Resilience Bill — together forming the UK's emerging principles-based approach to software supply chain security.
What is the Code's structure?
The Code organises 14 principles into four thematic areas. Theme 1, Secure Design and Development, covers principles 1-4 on threat modelling, secure development practices, third-party component management, and source integrity. Theme 2, Build Environment Security, covers principles 5-7 on build pipeline integrity, secret management, and signed artefacts. Theme 3, Secure Deployment and Maintenance, covers principles 8-11 on vulnerability handling, update mechanisms, configuration baselines, and end-of-life handling. Theme 4, Communication with Customers, covers principles 12-14 on vulnerability disclosure, advisory communications, and customer-facing transparency about security posture. The four-theme structure deliberately tracks the software lifecycle so that vendors can map the Code onto existing SDLC processes rather than overlaying a new control taxonomy.
What does each principle actually require?
Drawing from the DSIT publication, the operational expectations include the following. Principle 1 requires threat modelling at design time, repeated when material changes occur. Principle 2 requires secure coding practices including code review and use of memory-safe languages where appropriate. Principle 3 requires SBOM generation and vetting of third-party components against known vulnerability sources. Principle 4 requires source integrity controls including signed commits and access governance for source repositories. Principle 5 requires build pipeline integrity including reproducible builds where feasible, hardened build agents, and SLSA-style provenance. Principle 6 requires hardware-backed or equivalent secret management with rotation policy. Principle 7 requires signed artefacts with verifiable provenance shipped alongside releases. Principle 8 requires a documented vulnerability handling policy with defined SLAs. Principle 9 requires authenticated, integrity-protected update channels. Principle 10 requires hardened default configurations. Principle 11 requires defined end-of-support communications. Principle 12 requires a published vulnerability disclosure policy aligned to ISO/IEC 29147. Principle 13 requires timely security advisories. Principle 14 requires customer-accessible security posture information.
Who is the Code aimed at?
The Code is voluntary and applies to any organisation that develops or sells software intended for organisational use. It does not impose obligations on consumer software in the way the PSTI Act does for consumer connectable products. The scope is intentionally broad: enterprise software publishers, SaaS providers, embedded software vendors for industrial systems, and the firmware components of products that themselves carry obligations under other regimes. Customers — particularly UK public sector buyers under government procurement frameworks — are expected to use the Code as a baseline question in vendor due diligence.
What is the Software Security Ambassadors Scheme?
DSIT runs the Software Security Ambassadors Scheme as the implementation vehicle for the Code. Industry partners that have signed on as ambassadors commit to implementing the Code internally and to advocating for adoption across their supply chain. The Scheme is a soft enforcement mechanism: ambassadors are publicly listed, which creates reputational stake in compliance, but there is no penalty for non-compliance with the Code itself. Where DSIT has indicated future evolution is through a forthcoming certification scheme aligned to the NCSC's Principle Based Assurance (PBA) approach, which would let vendors evidence Code conformance through accredited third-party assessment.
# Indicative self-assessment template structure aligned to the Code
vendor: Example Software Ltd
assessment_date: 2025-09-15
assessment_scope:
product_lines: [acme-enterprise, acme-cloud]
principles:
- id: 1
theme: secure_design
statement: Threat modelling performed at design and on material change
evidence: [STRIDE_workshop_minutes_2025-Q3, threat_model_v4.2.pdf]
status: implemented
- id: 3
theme: secure_design
statement: SBOM generated; third-party components vetted
evidence: [sbom-cyclonedx-1.6.json, sca-pipeline-config.yaml]
status: implemented
- id: 8
theme: maintenance
statement: Vulnerability handling policy with defined SLAs
evidence: [psirt-policy-2025.pdf, advisory-archive-link]
status: implemented
How does the Code align with international frameworks?
The Code maps cleanly onto several existing standards. Principles 1-2 align with NIST Secure Software Development Framework (SSDF) practices PS.1 and PW.4-PW.7. Principles 5-7 align with SLSA build provenance levels 2 and 3. Principle 3 aligns with the SBOM expectations in OMB M-22-18 and CISA Secure by Design guidance. Principles 12-13 align with ISO/IEC 29147 and 30111 on vulnerability disclosure and handling. The deliberate alignment lowers the marginal cost of compliance for vendors that have already invested in those frameworks and creates a path forward for mutual recognition with US federal procurement requirements and EU Cyber Resilience Act conformity routes.
What is the regulatory trajectory?
The Code is currently voluntary. Several signals point to potential future hardening. First, the UK Cyber Security and Resilience Bill introduced to Parliament on 12 November 2025 expands the regulatory perimeter to medium and large managed service providers (RMSPs) and data centres, and the secondary legislation under the Bill could elevate the Code's principles to mandatory baselines for in-scope providers. Second, the NCSC's PBA-aligned certification scheme — currently under development — would let vendors and customers move from self-assertion to accredited assurance. Third, the Crown Commercial Service has consulted on referencing the Code in public sector procurement frameworks. A vendor that delays adoption is therefore betting that voluntariness will persist beyond 2026, which the policy trajectory does not strongly support.
How should vendors approach implementation?
Three practical steps. First, perform a gap assessment using the DSIT self-assessment template against current SDLC and customer-facing artefacts; most established vendors will find that 8-10 of the 14 principles are at least partially in place. Second, prioritise principles 3, 5, 7, and 12 — SBOM, build integrity, signed artefacts, and vulnerability disclosure — because they generate the most procurement leverage and align with parallel obligations under the EU CRA and US federal mandates. Third, establish ambassador-scheme participation if appropriate, and prepare for the eventual certification route by documenting evidence in the format the PBA approach contemplates.
How Safeguard Helps
Safeguard generates the evidence base for at least seven of the Code's 14 principles directly from CI/CD telemetry: SBOM production and vetting (Principle 3), build pipeline integrity attestations (Principle 5), signed artefact provenance with SLSA-compatible records (Principle 7), vulnerability handling SLAs and ticketing (Principle 8), update channel integrity verification (Principle 9), and disclosure workflow tooling (Principles 12-13). The platform's self-assessment export maps existing controls into the DSIT template format so vendors can complete the Code submission without manual transcription. As the NCSC's PBA certification scheme matures, Safeguard's evidence packs are structured to support accredited third-party assessment rather than requiring rework.