Secure by Design은 어디에서 끝나나요? 3D/4D 모델

I’ve been thinking about a surprisingly intricate question:

Where does Secure by Design actually end?

The term now covers everything from threat modelling and architecture reviews to secure development, vulnerability scanning and assurance.

All of these are important, but I think there is value in separating designing a system to be secure from demonstrating that the implementation actually is secure.

I’ve been using a simple model for this.

The 3D Method for Secure by Design

The design-time process has three steps:

1. Design

Create a sufficiently accurate representation of the intended system so that it can be analysed.

This might be an architecture diagram, model or specification. The important point is that it represents architectural intent, rather than being reconstructed from whatever was eventually implemented.

This distinction becomes particularly important with AI-assisted development. If probabilistic AI creates the implementation and another probabilistic AI reconstructs the architecture from that implementation, our security analysis is increasingly based on inferred rather than governed intent.

2. Define

Define the security objectives for the system.

There are several ways to do this, including:

• threat modelling
• risk assessment
• security policies and control assessments

I don’t think these approaches need to compete.

Threat modelling is particularly useful for discovering non-obvious risks. Asset-level risk assessment can provide a scalable way of establishing security objectives, while policies can provide repeatable organisational expectations.

3. Determine

Determine the controls required to meet those objectives.

This is where I think context becomes particularly important.

A control shouldn’t just say what must happen. Ideally we retain why the control exists and what architectural element it applies to.

That gives us something that can be communicated to human developers, AI coding assistants and eventually autonomous development agents.

At this point, I would argue that Secure by Design is complete.

We have described what we intend to build, established its security objectives and determined the controls required to achieve them.

But we haven’t demonstrated that the resulting system actually does any of those things.

The Fourth D: Demonstrate

This leads to an optional fourth step:

4. Demonstrate

Demonstrate that the implemented system actually realises the design and its controls.

That could include:

• control validation
• architectural conformance
• security testing
• assurance evidence
• evaluation of AI-generated implementations

This creates a distinction I’ve found useful:

3D determines what a securely designed system should be. 4D extends this into secure delivery by demonstrating that the implementation actually realises the design.

So:

3D Method — Secure by Design

Design → Define → Determine

and:

4D Method — Secure Delivery

Design → Define → Determine → Demonstrate

I think this distinction becomes more useful as AI agents take a larger role in software delivery.

An agent doesn’t just need a list of controls. It needs enough architectural context to understand what those controls apply to and why they exist.

And if an agent participates in implementation, we need a way of evaluating whether what it produced still conforms to those decisions.

Does the distinction hold?

This is the part I’m interested in getting feedback on.

Would you consider Secure by Design complete once the required controls have been determined?

Or should demonstrating that those controls were implemented correctly remain part of Secure by Design itself?

I’ve written up the longer version, including how it evolves with AI:

The 3D Method for Secure by Design