Design and Development – A Technical and Organisational Implementation Guide
Overview
The Secure Design and Development section of the UK’s Software Security Code of Practice focuses on embedding security principles and controls into software from the earliest stages of the Software Development Lifecycle (SDLC). It aims to ensure that software is not only functional but inherently secure by design and by default.
This guide provides:
- A breakdown of the requirements
- Step-by-step developer guidance
- Governance-level evaluation mechanisms
- Recommended commercial and open-source tooling
- Strategies for executive and operational enablement
Core Objectives of Secure Design and Development
- Apply structured secure development methodologies
- Manage software supply chain risks (SBOM, dependencies etc.)
- Integrate rigorous security testing into the CI/CD lifecycle
- Deliver default configurations that reduce risk out-of-the-box
Each of these is enforced by the Code through a Claims-based assurance model, which requires organisations to both assert and evidence that controls are in place.
1. Adopt a Secure Software Development Framework (SSDF or SDLC)
What This Means
Software development processes must be underpinned by a recognised secure development framework. Examples include:
- OWASP SAMM: A maturity model for assessing and improving software security practices.
- Microsoft Security Development Lifecycle (SDL): A prescriptive methodology for integrating security across all development phases.
- NIST’s Secure Software Development Framework.
Developer Implementation
- Integrate threat modelling at the design phase (e.g., STRIDE, LINDDUN, PASTA, DREAD, OWASP Top 10 etc.). Threat modelling should be conducted for your intended application(s) but also current / intended environments (Dev / Prod etc.).
- Ensure all user stories and feature specs include security and privacy requirements.
- Maintain documented secure coding guidelines, ideally language-specific.
- Enforce secure code reviews with checklists and linters (e.g., use Bandit for Python, ESLint with security plugins for JavaScript).
Potentially useful tools
- Commercial: Veracode SDLC Integrations (covers SAST, SCA, policy management)
- Open Source: OWASP Threat Dragon (threat modelling tool)
Executive Evaluation
- Has a secure development lifecycle been formalised and adopted across teams?
- How are they suitably trained to understand and implement the chosen SDLC?
- Are they trained once? Or are there regular refreshers?
- Do you periodically verify they can actually find the chosen SDLC should they need to?
- Do you periodically challenge output and processes, verifying proof of alignment with chosen SDLC?
- Can each phase of the SDLC demonstrate security and privacy considerations and sign-offs?
- Is there documented output from threat modelling exercises performed?
- Is quality of threat modelling consistent?
- Who reviews and sign’s off on output from threat modelling?
- Does this output feed in to the business’ wider risk management efforts?
2. Software Bill of Materials (SBOM) & Dependency Governance
What This Means
Organisations must maintain a real-time inventory of third-party and open-source components, versions, and licenses used in their software products. This reduces exposure to known vulnerabilities and license risk.
Developer Implementation
- Generate SBOMs at build time using tools integrated into CI/CD (e.g., GitHub Actions).
- Validate dependencies against a policy that enforces:
- Approved registries (e.g., internal PyPI, npm proxy)
- Allowed licenses
- CVE thresholds
- Continuously monitor for vulnerable components and outdated packages.
Potentially useful tools
- Commercial: Snyk – Real-time SCA, license governance, CI/CD integration
- Open Source: OWASP Dependency-Check, Syft + Grype
Executive Evaluation
- Is there evidence of SBOM generation and storage for each build/release?
- Are high/critical vulnerabilities triaged within defined SLA windows?
- Does your business have proactive threat intelligence efforts in place that accounts for your application’s dependencies and any potential exposure?
- Does this intelligence feed product lifecycle management and risk management operations?
- Are these efforts, and any inherent risk, appropriately visible to suitably senior personnel?
- Is there a central policy and tool for dependency approval?
3. Pre-Release Security Testing
What This Means
Security testing must be an embedded, continuous part of your CI/CD process. This includes both automated and manual testing approaches.
Developer Implementation
- Integrate automated security scans at key pipeline stages:
- SAST (Static Application Security Testing) for early code-level issues
- DAST (Dynamic Application Security Testing) for runtime and API-based vulnerabilities
- Secrets Scanning for exposed credentials
- For high-risk releases, conduct manual assessments:
- Code audits
- Penetration tests (internal or third-party)
- Architecture reviews
- Ensure all findings are tracked in your issue tracker (e.g., Jira, Azure DevOps).
Potentially useful tools
- Commercial: Checkmarx One – Unified platform for SAST/DAST/IAST/SCA
- Open Source:
Executive Evaluation
- Are all releases gated by security testing thresholds?
- Is there a dashboard/reporting mechanism to track findings and remediation velocity?
- Are manual tests conducted for critical modules and changes?
4. Secure by Design & Secure by Default
What This Means
Security must be built into product features and architecture, not added as an afterthought. Default configurations must minimise risk and not rely on users to harden systems.
Developer Implementation
- Enforce the principle of least privilege:
- Limit API tokens, access roles, service account scopes
- Validate all inputs using allowlists
- Ship software with:
- HTTPS enabled by default
- Secure headers (e.g., Content-Security-Policy, Strict-Transport-Security)
- MFA available and enforced for admin roles
- Provide hardening guides for customers deploying on-prem (e.g., CIS Benchmarks).
Potentially useful tools
- Commercial: Palo Alto Prisma Cloud (for configuration hardening, runtime checks)
- Open Source: Open Policy Agent (OPA) (for enforcing runtime access and config policies)
Executive Evaluation
- Are default deployments hardened against common threats (e.g., OWASP Top 10)?
- Is secure configuration documentation provided to customers?
- Is application logging privacy-preserving and tamper-evident?
- Have you verified your products will deploy to, or can be accessed and used by, client environments (fault free) if they are implementing and adhering to good security practices? NCSC’s CAF, MS Zero Trust, CiS Benchmarks etc. (Clients should not have to weaken their own security to use your products).
Organisational Support & Enablement
Tactical Steps
- Ensure the product manager of each development team is accountable for ensuring the security and privacy compliance requirements of the development they’re overseeing.
- Empower them as the security champions
- Ensure they’re suitably trained
- Provide them with direct access to security and privacy SME’s for when they need it.
- Integrate security objectives and KPIs into team OKRs.
- Provide ongoing secure coding training (e.g., Secure Code Warrior or OWASP Top 10 training).
Strategic Recommendations for Leadership
- Appoint the Senior Responsible Owner (SRO) with cross-functional authority (e.g., Head of Engineering or CISO).
- Fund and staff security engineering as a first-class discipline, not just governance.
- Implement a centralised AppSec dashboard to monitor SDLC security KPIs:
- Vulnerability age (MTTR)
- Percentage of components with known CVEs
- Code coverage of security tests
Conclusion
Part 1 of the UK’s Software Security Code of Practice is not simply a checklist, it’s a strategic framework for engineering secure software from the outset. By following this guide, development teams can harden their systems, reduce attack surfaces, and build the evidentiary foundation needed for assurance claims under the UK government’s voluntary model, and likely, future regulatory mandates.
Security must be treated as a design property, not a compliance artifact. This means engineering teams, business leaders, and security specialists must align on both tactical implementation and strategic investment in secure design and development from day one.
You can find part 2 at: https://clearpathsecurity.co.uk/part-2-of-aligning-with-the-uks-software-security-code-of-practice
Comments are closed