How to Secure by Design, Including AI-Assisted Development
Secure by Design is used in many different ways by different organisations, but there is broad agreement on one principle: security decisions should be made during design rather than being deferred until after implementation. In the design process, a method is used to determine which security controls should be added to a system. This article walks through one such approach and considers how AI is involved.
Traditionally, Secure by Design has been a pre-implementation activity. Many modern Secure by Design frameworks extend beyond design into implementation, validation and ongoing assurance. These activities are essential, but they also broaden the scope beyond the design activity itself, often conflating it with the secure software development lifecycle where automated scanners are used to highlight weaknesses and vulnerabilities post-implementation. If you want to dive into the history, this article has a recap:
In this article, we will stick to a more traditional design-time view and treat activities such as vulnerability management, penetration testing and control validation as part of a separate secure-in-reality process.
Steps
The key steps to securely designing a system are:
- Design the system
- Define security objectives
- Determine controls
This is the 3D method for Secure by Deisgn.
Design the System
Before a system can be secured, it must first be understood. Security analysis depends on a sufficiently accurate representation of the intended system, typically expressed through architectural models, diagrams or specifications.
As AI-assisted development becomes more capable, it may be tempting to rely on AI to infer the architecture from the implementation. While useful for documentation, this changes the basis of trust. One AI generates the implementation, while another interprets that implementation to reconstruct the design. Security analysis then depends on successive probabilistic interpretations rather than a governed representation of architectural intent.
Secure by Design therefore begins with a deliberate architectural representation that can be analysed independently of the implementation. AI can help create and maintain this representation, but it should remain the authoritative description of the intended system against which security objectives, controls and implementation are evaluated.
The main challenge is choosing the right level of detail. That topic deserves its own article, but the short version is that the model needs enough detail to support security analysis without becoming too difficult to maintain.
Define Security Objectives
Once we have a representation of the system and its key assets, we can begin defining our security objectives. There are several common approaches, and they do not need to be mutually exclusive:
1. Threat modelling
2. Risk assessment
3. Control assessments and organisational policies
Threat Modelling
Threat modelling helps us understand why particular controls are needed. By identifying threats, trust boundaries and attack paths, we can derive security requirements that are specific to the system being designed.
In practice, I have found threat modelling to be particularly valuable for understanding architectural decisions and identifying non-obvious risks. Most systems exhibit similar security concerns, but a small proportion contain unique characteristics that only become apparent through detailed threat analysis. For this reason, when scaling a Secure by Design process across many systems, I tend to favour more repeatable approaches, using detailed threat modelling where the architecture or risk justifies the additional effort.
Because threat modelling often involves structured brainstorming, it lends itself well to AI assistance. AI can accelerate the process by suggesting threats, abuse cases and attack paths, and by mapping them to frameworks such as STRIDE or CAPEC. This helps broaden coverage and identify threats that might otherwise be overlooked.
Risk Assessment
Risk assessments can be performed at different levels of detail.
Some organisations assess risk at the level of individual threats. While this can produce very detailed results, it can also become difficult to scale and introduces a degree of subjectivity when estimating likelihood and impact.
An alternative is to assess risk at the asset level. For each asset, the organisation determines the required levels of confidentiality, integrity and availability, together with any privacy, regulatory or business requirements. This approach scales well because it focuses on the security outcomes required for each asset rather than attempting to quantify every possible threat.
Control Assessments and Policies
Security policies, standards and control catalogues provide another important source of security objectives. They are straightforward to apply and help ensure consistency across systems.
However, policies alone are often separated from the context of the architecture. Applying every available control regardless of the system or asset can result in unnecessary complexity while providing little additional security.
The most scalable approach I have found is to combine asset-level risk assessment with architecture-aware control policies. Risk determines where controls are required, while the asset type determines which controls are appropriate. This provides a repeatable and context-aware method of selecting controls without requiring detailed threat modelling for every system.
Regardless of the approach taken, the objective is the same: to produce an analysis that can be used to determine the security controls required by the system. That analysis may consist of identified threats, asset-level security objectives, policy requirements, control gaps, or a combination of all four.
Determine Controls
The controls are the primary output of the Secure by Design process. Risks, threats and policy assessments are valuable because they help determine which controls are required, but the objective is ultimately the same: to identify the architectural and security controls needed to reduce or avoid unacceptable risk.
Implementation vulnerabilities remain important, but they are addressed after implementation has begun. Secure by Design is concerned with determining what controls are required, not whether they have been implemented correctly.
Controls require context to be understandable and maintainable. We need to understand not only what control has been selected, but also why it was chosen and what it applies to.
That context can be preserved in different ways depending on the analysis method:
- Risk assessment – the risk treatment explains why the control is required.
- Control assessment or policy – the asset and policy explain why the control applies.
- Threat modelling – the threat, trust boundary or attack path provides the rationale for the control.
Regardless of the approach, preserving this context allows controls to be understood, reviewed, challenged and maintained as the system evolves. Without it, controls become isolated requirements that are difficult to justify or adapt.
As AI-assisted development becomes more common, preserving this context becomes increasingly important. Traditional structured approaches can naturally retain the relationship between assets, objectives, threats and controls. AI-assisted workflows can also preserve this context, but only if they are explicitly designed to record and communicate it. Otherwise, architectural decisions risk becoming embedded within transient prompts and conversations, making them difficult to review, govern or reuse.
At this point the Secure by Design process is complete. The system has been described, security objectives have been defined and the controls required to achieve those objectives have been determined together with the rationale behind them. The remaining challenge is ensuring those decisions are faithfully realised in the implemented system—a separate activity that I refer to as Secure in Reality.
The next steps then are to:
- Manage vulnerabilities and weaknesses in the secure software development lifecycle
- Test that the controls are actually in place and that the design is realised
Acknowledgments
This article was predominantly written by the author, with AI used for editing and statement validation.