The UK's software security code turns good practice into evidence
Fourteen principles now give software vendors a practical baseline. The useful response is an evidenced delivery system, not a policy document nobody runs.
The UK Software Security Code of Practice sets out fourteen voluntary principles for organisations that develop or sell software to businesses. Published in May 2025 and updated in January 2026 with an ambassador scheme, it covers four themes: secure design and development, build environment security, secure deployment and maintenance, and communication with customers.
Its most useful effect is to make software security an accountable operating responsibility. A vendor should be able to show how the organisation knows its software is secure enough, who decides, and which evidence supports that decision.
Give senior ownership a working mechanism
Naming a senior responsible owner is meaningful only if information reaches them. Define a regular view of unresolved high-risk findings, unsupported components, production incidents, recovery exercises and exceptions to the secure delivery process.
Keep the pack decision-sized. A thousand low-context scanner results do not create governance. Show material risk, ownership, due date and the evidence that will close it.
Know what goes into the product
Dependency management is broader than running a vulnerability scanner. Record direct and transitive components, source, version, licence, maintenance state and where the component is deployed. Generate a software bill of materials from the build that produced the release.
Create a policy for new dependencies: what value justifies them, what maintenance signals matter, and how the organisation responds if a project becomes unmaintained. An old component is not automatically unsafe; an unknown and unowned component is difficult to defend.
Protect the build path
The build environment can turn a small credential leak into a compromised release. Require phishing-resistant authentication for privileged access, minimise long-lived secrets, protect branches and release approvals, isolate sensitive build jobs and retain trustworthy provenance for artefacts.
Recovery deserves equal attention. Rehearse rebuilding from known source and rotating affected credentials. Verify backups instead of assuming they are usable.
Make updates safe and communicable
Security does not end at release. Define supported versions and periods, monitor vulnerability sources, provide a clear disclosure route and make updates authentic, reliable and recoverable. Test the update mechanism as a product feature.
Customer communication should explain impact, affected versions, mitigation and corrective action without minimising uncertainty. Prepare the format before an incident so the team does not invent it under pressure.
Turn each principle into evidence
For every applicable principle, identify an owner, implementation, evidence source and review interval. Evidence might include threat models, pipeline configuration, test results, access reviews, component inventories, restore exercises, incident records and customer notices.
Do not create duplicate paperwork if an existing control already produces credible evidence. The goal is a delivery system people actually use and leaders can examine.
The code is voluntary, but customers increasingly need confidence in their software supply chain. Clear evidence makes security easier to buy, operate and improve.