A Walk Through SDLC, SSDLC and System Design
When I think about the root causes of major system failures, I realize that most of these problems didn’t appear out of thin air during production.
No.
They existed long before the system ever went live.
And yet, somehow, most teams still discover them only when it’s too late — when the system has already entered the real world.
I find that rather odd.
As Murphy’s Law reminds us: Anything that can go wrong, will go wrong.
And when dealing with complex systems, it usually does.
So why do we continue treating security as something that can be added easily after a system is already “born”?
After all, if we were building a human, we wouldn’t wait until adulthood to design its immune system.
What If Our System Were a Human Body?
A useful way to understand secure system design is to stop thinking about systems as software components.
Instead, imagine something far more complex: the human body.
A living organism where every part is connected — from the brain and organs to the blood and immune systems.
Each organ depends on another.
The heart cannot function without the lungs.
The brain cannot function without oxygen.
And the immune system protects the entire body.
A failure in one area can quickly affect the entire organism.
Secure systems are no different.
This is where SDLC, SSDLC and Design Reviews come into play.
SDLC: How Systems Grow
The human body develops through distinct phases, just like systems evolve through a lifecycle of their own.
This growth unfolds in clear stages:
**Requirements **define the genetic blueprint (such as a DNA) — the foundation of what the system becomes.
**Design **defines how internal systems connect and interact — showing how the “organs” work together.
**Development **is where those parts form into a functioning organism.
**Testing **validates that everything works together as expected.
**Deployment **is when that system begins operating under real conditions.
This is known as the Software Development Life Cycle (SDLC).
But even in this structured process, there is a key limitation:
Security is often introduced too late.
So by the time the system is built, architectural decisions are already in place, dependencies are formed and changing the structure becomes more difficult.
In many ways, it’s like trying to influence how a human body develops after its form has already been defined.
SSDLC: Let Security Grow With the System
Security in modern systems should not be treated as a final layer added at the end.
Instead, it must be part of how the system is shaped from day one.
Much like an immune system that develops alongside the body rather than being attached later in life.
**Secure Software Development Life Cycle (SSDLC) **ensures that security is embedded while the system is still being designed.
That way, security requirements are defined alongside functional requirements.
Threat modeling becomes part of design, allowing risks to be identified before decisions are locked in.
Security considerations influence architecture early rather than being applied later as “fixes”.
**Validation **happens continuously throughout development.
In this model, security is not added to a finished system.
It evolves together with the system itself.
Design Reviews: The Health Checkpoints
If SDLC represents system growth, Design Reviews act as health checkpoints along the way.
Just as physicians monitor development through stages of life, architects use Design Reviews to ensure systems evolve correctly.
These reviews turn security from a reactive step into a built-in part of design.
At SRR (System Requirements Review), the focus is understanding what is being built before it takes shape.
If requirements are the genetic blueprint, SRR validates it.
We clarify purpose, assumptions, limitations and risks.
We start asking: What is the system meant to do? What exactly are we protecting? What risks are already present?
At PDR (Preliminary Design Review), the system begins to take form.
Components start emerging, data flows become clearer and trust boundaries start to surface.
We reach a point where security naturally shifts into an architectural perspective.
Now, we can start asking how things actually connect by gathering the right information: How do components communicate with each other? How is identity represented throughout the system? Where are the trust boundaries and how they might be challenged?
Last, but certainly not least, we have CDR.
In CDR (Critical Design Review), the system is getting close to production.
At this point, the architecture should already feel complete and consistent.
Security controls are no longer theoretical — they are expected to already be in place.
Open risks should be clearly understood and not still being uncovered.
This is no longer about exploring design options, but about validating that the system is ready to move forward.
After this stage, changes become significantly harder to absorb.
FYI, Across all these stages, Security Architecture helps surface risks, challenge assumptions and keep security embedded as the system evolves.
This article doesn’t include the full list of Design Reviews, but feel free to explore them and read more online!
When Growth Happens Without Guidance
As you can see, without SDLC, SSDLC and Design Reviews working together, problems tend to surface much later in the process.
Risks that could have been identified during planning are only discovered during implementation.
Security controls are added unevenly across different parts of the system.
Design assumptions remain unquestioned until they become real constraints.
From the outside, the system may appear healthy.
But underneath, weaknesses have already started to form.
Much like the human body, individual parts may function perfectly well on their own.
The problem begins when those parts were never designed to work together as a complete organism.
By the time these weaknesses become visible, fixing them is often far more expensive than preventing them in the first place.
And we all know how high hospital bills can be.
A Reality Check…
On a personal note, I can’t count the number of gaps I’ve encountered in projects where security involvement came too late in the process.
At that stage, systems are already highly defined and decisions are deeply embedded in implementation.
Changes are no longer theoretical — they require real engineering effort, budget adjustments or even architectural redesigns.
Sometimes it means adding new features that were never part of the original scope, just to align the product with security requirements.
Other times, it means revisiting parts of the design and making adaptations just so it will fit the secure environment.
All of this translates into additional time, resources and effort.
This is exactly the point where influence is still possible, but every decision comes with a very real cost.
Just Remember
A system, much like the human body, carries the consequences of how it was allowed to develop.
Every decision leaves a mark.
Some become strengths. Others become weaknesses.
By the time a system enters production, much of its character has already been formed.
At that point, security is not introduced, it’s simply revealed.
Top comments (0)