Secure by Design and AI: Building Assured Software at Pace

"How can AI-accelerated development possibly meet JSP 440 and Secure by Design requirements?"

It's the question we hear most from MOD procurement teams, security officers, and programme managers. The assumption underneath is usually: "AI development is fast but insecure, and Secure by Design is thorough but slow - you can't have both."

This article shows you how to get both - and why AI-accelerated development, when done properly, can actually make Secure by Design easier to achieve.

What Secure by Design Actually Requires

Before we talk about AI, let's be clear about what MOD Secure by Design under JSP 440 actually demands. The first requirement is that security requirements must be defined early, not treated as something to add later. This means identifying and documenting security requirements before significant development work begins, ensuring that every architectural decision is informed by security considerations from day one. Second, threat modelling must be conducted to understand who might attack your system, what they are after, and how they might do it. This understanding informs architectural decisions and ensures defences are built against realistic threat scenarios rather than generic best practices that may not address your specific risks.

Third, secure architecture patterns must be baked into the design from the outset. Defence-in-depth, least privilege, separation of duties, and secure defaults are not features to be added; they are foundational architectural decisions that shape how the entire system is built. Fourth, security controls must be implemented and tested to defined standards. Authentication, authorisation, encryption, and audit logging must all be built according to recognised standards and verified through testing that proves they work as intended under both normal operation and attack conditions. Finally, assurance evidence must be maintained throughout the development process, documenting that security was considered at each stage, requirements were met, and testing was conducted. This is what accreditation requires, and without it, your system will not be approved for operational use. None of this is optional. The question is whether AI can help achieve these requirements rather than hinder them.

Where AI Actually Helps with Secure by Design

The first area where AI provides tangible benefit is in faster threat model implementation. In traditional development, the security team creates a threat model, developers interpret it weeks later, implementation may not match the original intent, and the gap is only discovered during security review when it is expensive to fix. With AI-accelerated development, the security team still creates the threat model-this remains human expertise work-but AI can then generate candidate controls based on that threat model. SC/DV cleared engineers review and refine these controls immediately, and controls are implemented while the threat model is still fresh in everyone's minds. The result is tighter alignment between the threats identified and the controls actually implemented, reducing the risk that security requirements are lost in translation between security architects and developers.

The second area is consistent application of security patterns. The problem with manual coding is that every developer implements authentication slightly differently. Some forget error handling. Some accidentally log sensitive data. This inconsistency creates vulnerabilities that are difficult to detect in code review because each instance looks slightly different. AI helps by allowing you to define secure patterns once, using human expertise to get them right, and then applying them consistently across the codebase. Automated tools catch deviations immediately, and peer review can focus on whether the pattern itself is correct rather than repetitively checking that each developer remembered all the details. This does not mean trusting AI blindly; it means using AI to enforce consistency after humans have defined what correct looks like.

The third area is continuous compliance checking. AI enables automation that catches security issues the moment they are introduced rather than weeks or months later. Static application security testing tools check every commit against security rules, blocking insecure code before it is merged. Dependency scanning flags vulnerable libraries before they become part of your codebase. Policy-as-code enforces security requirements automatically, ensuring that every deployment meets defined standards. Audit logging captures all security-relevant events, creating the evidence trail that accreditation requires. The critical difference is timing: in traditional development, you find security issues at the end when they are expensive to fix. With AI-accelerated development done right, you find them in minutes or hours when the code is still fresh and the fix is straightforward.

The Week-by-Week Reality: Secure by Design with AI

Let me walk you through what an actual AI-accelerated secure development project looks like week by week. Week one is entirely focused on security requirements and is entirely human-led. There is a threat modelling workshop with your security team where realistic attack scenarios are identified and documented. Security requirements are captured in detail, not as generic statements but as specific, testable requirements. Compliance requirements are mapped against JSP 440, NCSC Cloud Security Principles, and any other applicable standards. An architecture security review is conducted to ensure the proposed approach can actually meet these requirements. AI involvement at this stage is zero. This is human expertise work that requires understanding of your operational context, threat landscape, and regulatory requirements.

Weeks two and three cover secure architecture, and this is where AI assistance begins but remains firmly under human control. SC/DV cleared engineers design the secure architecture, making decisions about how authentication will work, how data will be protected, and how audit requirements will be met. AI generates boilerplate code based on these approved patterns, saving time on the repetitive parts. Security controls for critical paths-authentication systems, encryption implementations, authorisation logic-are implemented manually by experienced engineers, not delegated to AI. Automated security testing is configured so that every subsequent commit is checked against security rules. The AI involvement here is strictly code generation for non-security-critical components, always following patterns that have been defined and reviewed by human experts.

Weeks four to six are feature development, where AI acceleration is most visible but human governance remains constant. AI generates feature code following the security patterns established earlier, significantly speeding up development. However, engineers review every change for security implications before it is merged. Static application security testing runs on every commit, blocking any code that violates security rules. Regular security check-ins, perhaps twice per week, validate that the approach remains sound as the codebase evolves. This is not about trusting AI to write secure code; it is about using AI to write code faster while maintaining multiple layers of human and automated validation.

Weeks seven and eight are security validation, and once again this is human-led work that AI cannot do. Independent penetration testing is conducted by a team that does not know which code was AI-generated and which was written manually-they simply test for vulnerabilities. A security architecture review confirms that the implementation matches the threat model and that no security requirements were compromised during development. Compliance documentation is reviewed to ensure accreditation evidence is complete. Accreditation evidence is prepared and submitted to your information assurance team. The total timeline is eight weeks for a project that would traditionally take twelve to eighteen months. Critically, security is not compromised; it is enhanced through continuous validation rather than being tested once at the end.

JSP 440 Compliance Checklist for AI-Accelerated Projects

If you're commissioning AI-accelerated development for MOD, verify these:

Security Requirements Phase

• Threat model created before development starts
• Security requirements documented and agreed
• Architecture reviewed for security by cleared engineers
• Compliance requirements mapped (JSP 440, NCSC, etc.)

Development Phase

• SC/DV cleared engineers review all code before merging
• SAST tools run on every commit
• Dependency vulnerability scanning active
• Security patterns enforced through tooling
• Audit trail of all security decisions maintained

Validation Phase

• Independent penetration testing conducted
• Security architecture review completed
• Test coverage includes security test cases
• Vulnerability remediation plan in place

Accreditation Phase

• Threat model to controls traceability documented
• Security test results available
• Code review evidence provided
• Residual risk assessment completed

The Reality Check

AI-accelerated development can meet Secure by Design requirements, but only under specific conditions. Security requirements must be defined before AI generates any code, ensuring that every line generated is informed by security considerations from the outset. SC/DV cleared engineers must review everything AI produces, because AI can generate syntactically correct code that introduces subtle security vulnerabilities that only experienced humans can identify. Security-critical code must be written manually by experienced engineers-authentication systems, cryptographic implementations, and authorisation logic are too important to delegate to AI. Automated security testing must catch issues immediately through continuous integration, not weeks later during a separate testing phase. A complete audit trail must exist for accreditation, documenting what was generated, who reviewed it, what changes were made, and why.

If any of these conditions are missing, you are not doing Secure by Design. You are doing vibe coding with a security theatre overlay, and your system will fail either penetration testing or accreditation review. The question for procurement teams is not whether AI-accelerated development is compatible with Secure by Design-it is whether the provider you are evaluating actually meets these requirements or is simply claiming to be secure without the governance to back it up.

---

Want to see our Secure by Design process in action? We offer security-focused discovery workshops where we demonstrate how we integrate threat modelling with AI-accelerated development, how security controls are implemented and validated throughout the process, and how we generate accreditation evidence continuously rather than assembling it at the end. Contact our security-cleared team to discuss a proof of concept focused on your specific security requirements.