UK Software Security Code of Practice: 14 Principles

Enterprise customers increasingly ask software suppliers to prove they build, ship and maintain software securely, and the UK Software Security Code of Practice is now the reference those questions point to. The Code was published by the Department for Science, Innovation and Technology (DSIT) on 7 May 2025, launched at CYBERUK 2025, co-designed with the National Cyber Security Centre (NCSC) and co-sealed by the Canadian Centre for Cyber Security; the GOV.UK page shows a last update of 15 January 2026, which added details of the new Software Security Ambassadors Scheme. As of November 2026 the Code says a certification scheme is still being developed. It sets 14 principles in four themes. This guide goes principle by principle, explains who each principle applies to, how the NCSC Assurance Principles and Claims (APCs) and self-assessment template work, and which principles turn on identity and machine credentials in the build and release pipeline. It is for software vendors' senior leaders, product security and engineering teams, and the buyers who assess them. For the wider policy debate on liability and secure by design, see the Software Liability and Secure by Design Guide.

Key takeaways

Voluntary, but a procurement baseline. The Code is not law; it becomes binding when a customer contract or supplier questionnaire cites it, and buyers are named as an intended audience.
A named senior owner is expected. Vendors should appoint a Senior Responsible Owner (SRO) at top-tier leadership level who is accountable for the principles being followed.
Fourteen principles, four themes. Secure design and development (1.1 to 1.4), build environment security (2.1, 2.2), secure deployment and maintenance (3.1 to 3.5) and communication with customers (4.1 to 4.3).
Evidence follows the NCSC claims. The NCSC APC document breaks each principle into outcome-based claims; a vendor that evidences all of a principle's claims can say it meets that principle, and the self-assessment template records the evidence.
Build pipeline identities are in scope. Principle 2.1 expects least privilege, MFA, secure credential storage and no default credentials for every account that can reach the build environment, and 1.4 asks vendors to avoid hard-coded credentials.

What it is and who it applies to

The Code is a voluntary baseline for software security and resilience. Its stated aim is to reduce the likelihood and impact of software supply chain attacks and other resilience incidents, many of which come from avoidable weaknesses in development and maintenance, and to improve communication between vendors and their customers. It was refined through a public call for views from May to August 2024. The Code says it reflects best practice including that outlined in the US Secure Software Development Framework (SSDF) and the EU's Cyber Resilience Act, and it should be read alongside the UK Cyber Governance Code of Practice Guide and technology-specific codes such as the UK AI Cyber Security Code of Practice Guide.

The Code defines software vendors as organisations that develop and sell software or software services. Software covers code, programmes and applications on IT and OT hardware and cloud services, including SaaS. Its main focus is proprietary software sold business to business.

Stakeholder	Principles that apply	Notes
Developers and distributors (develop and sell)	All 14	The primary audience
Resellers (sell, do not develop)	Themes 3 and 4	Should encourage their developers to follow the Code
Developers only, such as in-house teams	Themes 1 and 2, and theme 3 where within their responsibility	Useful as an internal engineering baseline
Open source developers and maintainers	Not the primary audience	Risk in open source code is managed by the proprietary developers and end users who consume it
Organisations buying software	Use the Code in supplier negotiations and contracts	Can ask for the self-assessment as assurance

The SRO can be a senior executive, board member, C-suite member or equivalent. Deep technical expertise is not required, but the SRO must prioritise the Code and make sure teams have the resources, tools and skills to implement it.

Structure and key requirements

For each theme the Code says the SRO should gain assurance that the organisation achieves the principles listed. The practical detail sits in the NCSC implementation guidance, published as one page per theme plus an appendix on secure development frameworks.

Principle	Requirement (summarised)	What the NCSC guidance and claims expect
1.1	Follow an established secure development framework	One framework across projects covering threat modelling, requirements, governance and roles, secure coding, test strategy, data and configuration management; developers trained in it
1.2	Understand software composition and assess third-party component risk	Inventory of direct, transitive, internal and open source components, plus compilers and build systems; an SBOM is one suitable format; all components identified and documented
1.3	Have a clear process for testing software and updates before distribution	Static and dynamic analysis, peer review by at least two people, unit and integration testing including fuzzing, and point-in-time manual assessment such as penetration testing
1.4	Follow secure by design and secure by default principles	Threat modelling early; phishing-resistant MFA opt-out for privileged users; no default passwords; input validation; no hard-coded credentials; encryption of sensitive data
2.1	Protect the build environment against unauthorised access	Access policy, removal process, least privilege, MFA for all build accounts, secure credential storage, no default credentials, regular access review
2.2	Control and log changes to the build environment	Log all access and changes in protected storage, retain for an agreed period, define who may change what and for how long, revoke when no longer needed
3.1	Distribute software securely to customers	Trusted download location, TLS for automatic deployment, code signing through the pipeline, integrity verifiable in the customer environment, ability to roll back
3.2	Implement and publish an effective vulnerability disclosure process	Published policy and confidential reporting route; triage by harm; NCSC Vulnerability Disclosure Toolkit referenced
3.3	Detect, prioritise and manage vulnerabilities in components	Scanning, monitoring vulnerability databases and advisories, risk-based severity process, tested response playbook, root cause analysis
3.4	Report vulnerabilities to relevant parties where appropriate	Internal teams, customers, CVE and NVD, regulators where required, affected third parties and open source projects
3.5	Provide timely security updates, patches and notifications	Fixes prioritised by risk, out-of-band updates for critical issues, signed and tested updates, security fixes not sold as a premium feature
4.1	Tell customers the level of support and maintenance provided	Clear, published support terms
4.2	Give at least one year's notice before end of support	Claim: customers given at least one year's notice
4.3	Make information on notable incidents available to customers	Information on incidents that may significantly affect customer organisations

The NCSC notes that the principles are meant to protect against remote attackers using public tools with modest resources, and are not sufficient on their own against a sophisticated, highly motivated attacker. Treat them as the floor. The NIST Secure Software Development Framework (SSDF, SP 800-218) Guide goes deeper on practices for principle 1.1.

Identity and NHI requirements

Several principles depend directly on how the vendor manages human and non-human identities in its engineering estate. Build systems, CI/CD runners, signing services and package registries all authenticate with tokens, keys and service accounts, and those credentials are the route to tampering with releases.

Build access (2.1): the guidance asks for least privilege on every account, separation of external-facing access management components, secure credential storage and no default credentials. The APC claim that users with build access are regularly reviewed for legitimate need applies equally to pipeline service accounts and deploy tokens. See the CI/CD Pipeline Identity Security Guide.
Strong authentication (2.1, 1.4): MFA for every account that can reach the build environment, an extra factor from an unfamiliar device, and recovery processes that cannot be used to bypass MFA. For the product itself, phishing-resistant MFA should be opt-out for privileged users.
Credentials in code (1.4): identify credentials that could cause harm if exposed, store them securely and avoid hard-coding them. A secrets manager and pre-commit and pipeline secret scanning give evidence for this. See the Secrets Management Guide.
Change logging (2.2): logs should attribute each change to an identity, so shared automation accounts weaken the evidence. Give each pipeline and job its own identity, preferably with short-lived federated tokens.
Signing keys (3.1, 3.5): code signing through the pipeline means the signing key is one of the most sensitive machine credentials the vendor holds. Keep it in an HSM or managed key service, restrict which pipeline identities can request signatures and log every use. See the Code Signing Security Guide.
Default credentials in shipped products (1.4): administrators should set their own strong password during installation or use a stronger authentication method; this also covers API keys and service credentials the product creates.

Implementation steps

Appoint the SRO and scope products. Name the SRO, list products and services sold to organisations, and decide which stakeholder category applies to each (developer and distributor, reseller, developer only).
Download the claims and template. Use the NCSC APC document and the self-assessment template as the working checklist, one row per claim.
Baseline the build estate first. Inventory build systems, runners, registries, signing services and every human and machine identity with access. Enforce MFA, remove default and shared credentials, and turn on change logging to protected storage (2.1, 2.2).
Pick and publish a development framework. Map existing practice to one framework such as the SSDF and record which practices are implemented (1.1). The guidance suggests considering publishing which framework you follow.
Stand up composition and vulnerability handling. Generate SBOMs per release, monitor components, publish a vulnerability disclosure policy and agree internal response times (1.2, 3.2 to 3.4). See the SBOM Guide.
Secure release and update delivery. Sign artefacts and updates, document how customers verify integrity, keep rollback to a specific version, and consider staged rollouts (3.1, 3.5).
Publish customer-facing terms. State support and maintenance levels, commit to at least one year's end-of-support notice and set up a route for notable incident information (4.1 to 4.3).
Complete and refresh the self-assessment. Record evidence per claim, list gap-closing actions where a claim cannot yet be fully evidenced, and review at least at each major release or annually.

Evidence and assessment

The government provides a self-assessment based on the NCSC's Principles Based Assurance approach. The APCs are sets of ideal-scenario claims; evidence can vary by organisation, and the NCSC lists document inspection, interviews and audits of test plans and results as forms it can take. Where a claim cannot be fully evidenced, the vendor should identify the steps needed to close the gap. Assurance can also come from audit and independent testing through the NCSC Cyber Resilience Test Facilities scheme. The Code says the government is developing a certification scheme based on this compliance process, with details to follow; the status should be checked on GOV.UK before relying on it.

Principle	Example claim (NCSC APC)	Evidence that supports it
1.1	Developers are trained in the use of the framework and tools	Framework document, training records, mapping of practices to projects
1.2	All third-party components are identified and documented	SBOM per release, dependency policy, component update test results
2.1	Users with access to the build environment are regularly reviewed	Access review records covering human and service accounts, MFA enforcement report
2.2	Access and changes to the build environment are logged	Log configuration, retention setting, sample audit trail tied to named identities
3.1	Integrity of software, including updates, can be verified in the customer environment	Signing process, published verification instructions, key custody records
3.2	A vulnerability disclosure policy and process is published	Public policy URL, triage procedure, report handling metrics
3.5	Security updates are distributed as soon as is practicable	Fix time by severity, out-of-band release records, release notes marking security fixes
4.2	Customers are given at least one year's notice of end of support	Published lifecycle policy, customer notices with dates

Measures worth reporting to the SRO: share of claims fully evidenced, share of build identities with MFA or short-lived credentials, median days from critical vulnerability confirmation to fix release, share of releases with an SBOM and signature, and number of products with a published end-of-support date.

Mapping to other frameworks

The mapping is indicative and drawn from the principle text; neither DSIT nor the NCSC publishes it as an official crosswalk on the pages checked. EU market obligations are covered in the EU Cyber Resilience Act Guide.

Code principle	NIST SSDF (SP 800-218) group	NIST CSF 2.0	NIST SP 800-53 Rev 5
1.1 Secure development framework	PO Prepare the Organisation	PR.PS-06	SA-15
1.2 Composition and third-party risk	PW Produce Well-Secured Software, PS Protect the Software	GV.SC-05	SR-3, SR-4
1.3 Testing before distribution	PW	PR.PS-06	SA-11
1.4 Secure by design and default	PW	PR.PS-06	SA-8
2.1 Build environment access	PO, PS	PR.AA-01, PR.AA-05	AC-2, AC-6, IA-2
2.2 Build change control and logging	PS	PR.PS-04	CM-3
3.1 Secure distribution	PS	PR.PS-06	SR-11
3.2 to 3.4 Vulnerability disclosure, management and reporting	RV Respond to Vulnerabilities	ID.RA-08	RA-5
3.5 Timely updates	RV	ID.RA-08	SI-2
4.1, 4.2 Support terms and end-of-support notice	None direct	GV.SC-05	SA-22

Common pitfalls

Treating it as a policy exercise. Claims such as "integrity can be verified in the customer environment" need working mechanisms and customer instructions, not a statement of intent.
Reviewing only human build access. Deploy keys, runner tokens and registry credentials outlive staff changes; leave them out and the 2.1 access review claim is not met. See the Service Account Security Guide.
Shared automation accounts. One pipeline account used by many jobs makes the 2.2 change log unattributable.
SBOM without action. Producing SBOMs but not monitoring components against new vulnerabilities leaves 1.2 and 3.3 half done.
Charging for security fixes. The guidance says security fixes should not be a premium feature and should run for a clearly communicated support period.
Short end-of-support notice. Lifecycle announcements with less than a year's notice fall short of 4.2 and are what customers' procurement teams check first.

Practitioner checklist

Appoint and record the Senior Responsible Owner.
Classify each product by stakeholder type and note which principles apply.
Complete the NCSC self-assessment template with evidence per APC claim.
Enforce MFA and least privilege for every human and machine identity with build access, and review it on a schedule.
Remove default, shared and hard-coded credentials from build systems and shipped products.
Log build environment access and changes to protected storage with an agreed retention period.
Generate an SBOM and signature for every release and publish verification steps.
Publish a vulnerability disclosure policy and track fix times by severity.
Publish support terms and give at least one year's notice before end of support.

Standards and references

This guide summarises the UK Software Security Code of Practice and is not legal advice. Related NHI Mgmt Group resources: Software Liability and Secure by Design Guide · Software Supply Chain Security Guide · CI/CD Pipeline Identity Security Guide · UK Government Secure by Design Guide

UK Software Security Code of Practice: the 14 principles and how to evidence them