UK Software Security Code of Practice: the 14 principles as engineering practice

The Code sets out what a software vendor should do so that the software it sells is secure to build, ship and run. It is issued by the Department for Science, Innovation and Technology, co-designed with technical experts at the NCSC and an industry and academic group, and it is voluntary. It applies to “all organisations that develop and/or sell software to businesses or other organisations” and is aimed at senior leaders in those vendors, because each principle is something a Senior Responsible Owner must gain assurance about rather than a task for one team.

It is not a law. The UK's Cyber Security and Resilience Bill, introduced on 12 November 2025 and still before the House of Lords in October 2026, would bring medium and large managed service providers under the NIS Regulations, but it does not make this Code mandatory. Customers can, however, ask for conformance in procurement, and the NCSC's implementation guidance and self-assessment template make the evidence easy to request.

The first column quotes each principle. The practice column is one way to meet it; the SSDF column names the SSDF 1.1 practices or tasks that cover the same ground, and the CRA column the Regulation (EU) 2024/2847 provisions that overlap, for teams selling in the EU as well.

Theme 2 is where the Code goes further than many questionnaires. Principle 2.1 means nobody, human or machine, can change what the pipeline builds without authorization: CI jobs use short-lived identity tokens instead of stored secrets, runners for release builds are isolated from untrusted pull requests, administrators use MFA and tokens carry only the permissions a job needs. Principle 2.2 means every change to the build itself, such as a workflow file, a runner image or a signing key, goes through review and leaves a log you keep.

The guides on /domains/supply-chain/ci-cd/github-actions-hardening/ and /domains/supply-chain/ci-cd/build-integrity/ cover the controls; the evidence is the ruleset that protects workflow files, the identity configuration, runner isolation settings and audit logs retained for your review period.

Principles 3.2 to 3.5 describe the vulnerability lifecycle end to end. Publish how to report a vulnerability (3.2), with a security.txt file as RFC 9116 describes and a policy that says what reporters can expect. Detect problems in your components before someone reports them (3.3), by scanning against the SBOM of each release and recording exploitability decisions as VEX (/domains/supply-chain/vex/producer-and-consumer-decisions/). Report to the people who need to know (3.4), such as the maintainer of a vulnerable component you use. And ship fixes on timelines you publish, with an advisory that tells customers what to do (3.5).

Principle 4.3 adds incidents: tell customers about notable incidents that may significantly affect them. Write the templates and name the owner before you need them; the same process serves CRA Article 14(8), which requires manufacturers to inform impacted users of exploited vulnerabilities and severe incidents.

Principles 4.1 and 4.2 are the most concrete in the Code: say what support each version gets, and give customers at least a year's notice before it ends. Publish the policy as data on your site, so customers can monitor it and you can check it in CI. The same file can carry the EU dates: from 11 December 2027 the CRA requires a support period of at least five years unless the product is expected to be in use for less (Art. 13(8)), and the end date, at least the month and year, must be clear at the time of purchase (Art. 13(19)).

{
  "vendor": "Example Software Ltd",
  "published_at": "https://example.com/security/support-policy.json",
  "versions": [
    {
      "product": "Ledger Desktop",
      "version": "5.x",
      "support": "security and bug fixes",
      "end_of_support": "2033-03-31",
      "end_announced": "2025-06-02",
      "eu_first_placed": "2028-01-15"
    },
    {
      "product": "Ledger Desktop",
      "version": "4.x",
      "support": "security fixes only",
      "end_of_support": "2027-06-30",
      "end_announced": "2026-05-04"
    },
    {
      "product": "Ledger Sync API",
      "version": "v1",
      "support": "security fixes only",
      "end_of_support": "2027-09-30",
      "end_announced": "2026-09-01"
    }
  ]
}

The script flags a version with no stated level of support, an end date announced less than a year ahead, and, for products first placed on the EU market from 11 December 2027, a support period shorter than five years or the stated expected use. It prints support policy OK for the file above. Move the 4.x announcement to 1 August 2026 and it fails, because 30 June 2027 is less than a year later.

"""Check a published support policy: UK Code principles 4.1 and 4.2, and CRA Art. 13(8).

Usage: python3 check_support_policy.py support-policy.json
"""

import json
import sys
from datetime import date

# The CRA support period applies to products placed on the EU market from this date.
CRA_APPLIES = date(2027, 12, 11)


def add_years(day, years):
    try:
        return day.replace(year=day.year + years)
    except ValueError:  # 29 February in a year that has none
        return day.replace(year=day.year + years, day=28)


def problems(policy):
    found = []
    for v in policy["versions"]:
        name = f"{v['product']} {v['version']}"
        if not v.get("support"):
            found.append(f"{name}: no level of support stated (UK Code 4.1)")
        end = date.fromisoformat(v["end_of_support"])
        announced = date.fromisoformat(v["end_announced"])
        if end < add_years(announced, 1):
            found.append(f"{name}: end {end} announced on {announced}, under a year (UK Code 4.2)")
        placed = v.get("eu_first_placed")
        if placed and date.fromisoformat(placed) >= CRA_APPLIES:
            years = min(5, v.get("expected_use_years", 5))
            if end < add_years(date.fromisoformat(placed), years):
                found.append(f"{name}: support ends within {years} years of EU placing (CRA 13(8))")
    return found


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        issues = problems(json.load(f))
    print("\n".join(issues) or "support policy OK")
    sys.exit(1 if issues else 0)

The Code follows the NCSC's principles-based assurance approach. The NCSC's implementation guidance explains each principle, and a separate Assurance Principles and Claims document expresses conformance as outcome-related claims; the self-assessment template can be kept internally or shared with customers. The Code says the government is developing a certification scheme; until one exists, make the self-assessment specific enough that a customer can check each claim against its evidence.

Write the self-assessment the way you would write an SSDF evidence matrix (/frameworks/ssdf-product-lifecycle/): one row per principle, the claim, the evidence and the owner, reviewed by the Senior Responsible Owner. Since January 2026 DSIT and the NCSC also run a Software Security Ambassadors Scheme, in which signatory organizations commit to model and promote the Code; joining it is a commitment, not an assessment of your products.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. DSIT: Software Security Code of Practice (publication page). Published 7 May 2025; updated 15 January 2026.
2. DSIT: Software Security Code of Practice (HTML). 7 May 2025, updated 15 January 2026.
3. NCSC: Software Security Code of Practice implementation guidance. Version 1.0 (7 May 2025).
4. DSIT: Software Security Ambassadors Scheme. Published 15 January 2026; updated 1 October 2026.
5. DSIT: Cyber Security and Resilience (Network and Information Systems) Bill factsheets. Published 12 November 2025; updated 30 June 2026.
6. UK Parliament: Cyber Security and Resilience (Network and Information Systems) Bill, stages. HL Bill 49, as amended in Grand Committee (7 September 2026).
7. NIST SP 800-218: Secure Software Development Framework (SSDF). Version 1.1 (February 2022).
8. Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13. OJ L 2024/2847, 20 November 2024.
9. RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. April 2022.

Reference information

Tags

Secure defaults and frameworksVulnerability disclosureAppSec programsRegulation

SDLC phase

MaintenanceSecurity program

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring