|
Welcome to the August edition of the Demix Monthly Newsletter |
| | We at Demix are proud to spotlight the UK’s new Software Security Code of Practice in this month’s newsletter.
As a company committed to delivering resilient, enterprise-grade solutions, we recognize that today’s software supply chains demand rigorous, standardized security measures.
|
|
| This voluntary framework, developed by the UK Department for Science, Innovation & Technology (DSIT), the National Cyber Security Centre (NCSC), and international partners, lays out fourteen actionable principles covering secure design, build-environment protection, deployment and maintenance, and transparent customer communication. |
|
|
|
|
|
|
|
|
|
|
| | | | In May 2025, the UK’s Department for Science, Innovation & Technology (DSIT), in partnership with the National Cyber Security Centre (NCSC) and the Canadian Centre for Cyber Security, published a voluntary Software Security Code of Practice. This Code sets out fourteen fundamental principles—grouped under four themes—that all software vendors selling to business customers should adopt to reduce supply-chain risk, bolster resilience, and improve overall software security. |
| | | The acceleration of software supply-chain attacks in recent years—whether through weaponized third-party libraries, build-environment compromises, or unpatched vulnerabilities—has highlighted avoidable weaknesses in how software is developed, built, deployed, and maintained. A lack of standardized baseline expectations across vendors exacerbates these risks, as does uneven communication between vendors and their customers.
To address this, DSIT commissioned a co-design process led by the NCSC alongside industry and academic experts. The draft Code was refined through a public call for views held from May to August 2024, gathering feedback from suppliers, integrators, and customers alike. This collaborative approach ensures the Code reflects both real-world constraints and international best practices, while remaining achievable for organizations of all sizes. |
| | | To operationalise the connection between strategy and execution, we propose a 3-step approach using CMMI: |
| Government Sponsors:UK Department for Science, Innovation & Technology (DSIT): Overall shepherd of the Code within UK cyber-security policy. National Cyber Security Centre (NCSC): Technical lead and co-designer, providing both the Principles Based Assurance framework and deep engineering expertise. Canadian Centre for Cyber Security: Co-sponsor, ensuring cross-Atlantic alignment and international applicability.
|
|
| |
|
|
|
|
|
|
|
|
| | Industry & Academic Experts:
A working group of practitioners from independent software vendors, SaaS providers, managed-service firms, and academic researchers. Their input shaped the wording of the principles, implementation guidance, and self-assessment criteria. |
|
|
|
|
|
|
|
|
|
|
| Public Stakeholders:
Over 3 months (May–Aug 2024), more than 100 organizations submitted comments through the public consultation, leading to refinements that balanced rigor with practicality. |
|
| |
|
|
|
|
|
|
|
|
| | | Primary Audience Senior Leaders in software vendor organizations (e.g., C-Suite, Directors) who must appoint a Senior Responsible Owner (SRO) to oversee Code adherence. Technical Teams (developers, DevOps, security engineers) tasked with implementing each principle.
Secondary Audience: Software Resellers—expected to uphold Principles 3–4 (deployment and communication). In-house Developers—Principles 1–3 apply when producing proprietary software. Procurement Teams—can use the Code to negotiate security requirements into contracts.
Open-source maintainers and non-commercial projects were deliberately scoped out, since the Code focuses on business-to-business relationships, where vendors bear ongoing maintenance and support obligations
|
| | Code Structure: Four Themes & Fourteen Principles |
|
| |
|
|
|
|
|
|
|
|
| Secure Design and Development
1.1 Adopt an established secure development framework (e.g., SSDF).
1.2 Conduct software composition analysis and risk assessments for third-party components.
1.3 Implement robust testing processes (unit, integration, fuzzing) before distribution.
1.4 Enforce secure-by-design and secure-by-default throughout the SDLC.
Build Environment Security
2.1 Protect build systems from unauthorized access (least-privilege, network isolation).
2.2 Log and control all changes to the build environment (audit trails, configuration management).
Secure Deployment and Maintenance
3.1 Distribute binaries and updates via secure channels (signed packages, integrity checks).
3.2 Provide and publish a clear vulnerability-disclosure policy.
3.3 Proactively detect, triage, and manage vulnerabilities in all components.
3.4 Report critical vulnerabilities to relevant parties (customers, CVE databases) when appropriate.
3.5 Deliver timely security patches and notify customers of updates.
Communication with Customers
4.1 Clearly state levels of support and maintenance for each product.
4.2 Give at least one year’s notice before end-of-support.
4.3 Share information on notable incidents that could significantly impact customer environments .
Each principle is accompanied by implementation guidance—detailing practical options (e.g., open-source tooling for composition analysis) and signposting to deeper standards. |
|
|
|
|
|
|
|
|
|
|
| | Assurance and Self-Assessment |
| To help organizations demonstrate compliance, the NCSC has produced a self-assessment form based on a Principles-Based Assurance (PBA) model. The form breaks each principle into Assurance Principles & Claims (APCs), against which vendors collect evidence—ranging from process documents to automated tool outputs. A formal certification scheme is planned for rollout later in 2025. |
| | | For Vendors: Provides a clear, government-backed baseline to structure security investments, reduce liability, and differentiate offerings in procurement processes.
For Customers: Offers confidence that suppliers adhere to consistent, verifiable security practices—minimizing surprises from unnoticed build-environment breaches or unpatched library vulnerabilities.
For the Ecosystem: By harmonizing across borders and frameworks, it streamlines global supply-chain resilience efforts and reduces duplication of audits. |
|
|
|
|
|
|
|
|
|
|
| | | The Software Security Code of Practice represents a milestone in public-private collaboration on supply-chain security. Its voluntary, principle-based approach balances rigor with flexibility and aligns with international standards—from the SSDF to the EU’s Cyber Resilience Act. By embedding these fourteen practices into your software lifecycle—from design through customer communication—you can significantly reduce risk, build trust with enterprise customers, and position your organization as a leader in secure, resilient software delivery. |
|
| |
|
|
|
|
|
|
|
|
| | Schedule a meeting with us to explore the Software Security Code of Practice and discover how Demix can guide you to full compliance. |
|
| |
|
|
|
|
|
|
|
|
| | | |
|
|
|
| |
|
