Design-Time DevSecOps: Security Before the First Commit
AI Security & Development
The biggest shift in DevSecOps is not better automation downstream.
It is controlling intent upstream.
DevSecOps set out to bring security into delivery. For a while, it worked. We added scanners, validated dependencies, shifted tests left, and enforced policy in CI/CD. But the model stayed reactive. We secured code after it existed. We scanned what was already written. We found risks after architecture had locked in the damage.
That approach made sense when development was linear. Plan. Design. Code. Build. Deploy.
AI broke that model.
Code is now generated instantly. Agents act immediately. Behavior changes without commits. Execution can happen without a traditional deploy step at all.
Security that starts after code is already late.
This is why security must move earlier. Before architecture. Before build systems. And well before the first commit. This is the shift from runtime DevSecOps to design-time DevSecOps, accelerated by Spec-Driven Development. See my Spec-Driven Development breakdown here.
Why classical DevSecOps is no longer enough
DevSecOps evolved when humans wrote most code. Vulnerabilities came from human choices or dependency decisions. Pipelines scanned those artifacts and blocked bad releases.
Today, the riskiest code is often the code we never wrote.
It is generated by LLMs.
Executed by agents.
Applied through infrastructure-as-conversation patterns.
In many systems, the attack surface appears before a single commit.
Upstream of CI, we now see risks like:
prompt injection in retrieval flows
misaligned tool permissions
unconstrained function calling
ungoverned agent execution
RAG-based data exposure
insecure execution boundaries
missing identity enforcement
Traditional DevSecOps never sees these. There is no code yet to scan. By the time scanners run, the system may already be unsafe.
The rise of vibe coding
Most engineering leaders recognize this pattern. AI-assisted development has created a new habit: vibe coding.
A developer asks an AI to generate an API. Or scaffold a service. Or write a Kubernetes manifest. The output looks fine. It runs locally. It ships.
But the AI is not just writing code. It is making architectural decisions. And those decisions are happening without guardrails.
Vibe coding collapses design. Instead of intentional architecture, we assemble fragments and hope they behave safely. Hope is not a strategy. DevSecOps cannot secure what was never deliberately designed.
This tension is the same one I explored in AI Security Gaps: We’re Building Faster Than We’re Securing.
How AI moved security upstream
AI changed where execution begins. Security is no longer triggered by code. It is triggered by intent.
Before the first commit, we now define:
behavior
identity
tool access
execution permissions
data scope
retrieval paths
model capabilities
None of these are code. All of them shape the attack surface.
We used to discover these issues during threat modeling or static analysis. But when agents can act immediately, waiting is no longer acceptable.
Spec-Driven Development changes the security timeline
Spec-Driven Development makes intent explicit.
Instead of jumping to implementation, we define:
purpose
scope
identity model
allowed tools
compliance requirements
governance boundaries
architectural patterns
Intent becomes a first-class artifact. Once intent is structured, security can attach to it. Security moves to design time instead of pipeline time.
Why the spec becomes the first security control
In AI systems, prompts are execution.
Agents are execution.
RAG is execution.
Function calling is execution.
We now deploy cognition, not just code.
The specification becomes:
a permissions boundary
a compliance profile
a threat model
a data governance perimeter
an identity constraint
A system cannot be secure if the spec is not secure. Code cannot fix a broken intent.
The new DevSecOps pipeline starts with design
The modern lifecycle begins before implementation.
Teams start by expressing intent. Roles are clarified. Architectural boundaries are defined in a formal spec. That design is validated early. Threat modeling happens before generation. Policies enforce least privilege before tools or agents are allowed to act.
Only then is code or behavior generated.
Execution shifts from assumption to condition. Code becomes a result of secure design, not the starting point. Agent execution becomes gated, not automatic.
This inversion changes everything.
Why enterprises cannot rely on downstream gates anymore
Across industries, the pattern is the same.
Developers generate infrastructure and application logic through AI tools without architectural review. Models suggest defaults that bypass identity controls. Function calling adds convenience with unchecked permissions. Retrieval systems surface insights while quietly pulling sensitive data into prompts.
The risk is not one dramatic failure. It is the slow normalization of unsafe defaults.
Traditional scanning misses this because the problem starts before code exists. Downstream gates assume they still control execution. In AI-driven systems, they often do not.
Security at design time must validate intent, not artifacts
With design-time security, the spec is validated before anything is built.
Intent is evaluated for:
identity enforcement
tool permissions
least privilege
compliance
threat surfaces
retrieval boundaries
PHI and data controls
Generated artifacts become secure by default, not patched after the fact.
Automated enforcement becomes mandatory
AI development moves faster than humans can review.
Manual architecture oversight does not scale. Design-time guardrails must be automated:
pattern linting
threat scoring
policy validation
identity-based rules
secure function usage
safe persona enforcement
Security must exist before code exists.
What this looks like in practice
When Spec-Driven Development becomes standard, design-time DevSecOps stops feeling special. It becomes normal.
Teams begin with structured intent. That intent goes through threat modeling and security review. Only approved specs are allowed to generate code, agents, or infrastructure. Even then, execution is constrained by the rules defined in the spec.
Security becomes proactive, not reactive.
This is the beginning of AI-native security
Standards bodies are already moving in this direction. NIST, ISO, the EU, the UK, and Canada are all emphasizing design-stage controls.
AI governance is becoming design-first:
provenance
explainability
traceability
guardrails
identity
controlled autonomy
Design-time validation is no longer optional.
Why this matters to architects, engineers, and security teams
Spec-Driven Development reshapes responsibility.
Security decisions become architectural decisions. Architects regain control over system composition. Developers get clear constraints instead of late rejections. DevSecOps shifts from policing to enabling.
This is not about slowing teams down. It is about clarity, safety, and trust.
Pain point: vibe coding versus intentional engineering
We cannot secure systems by pasting function calls into ChatGPT and hoping for the best. AI development without design is speculation. DevSecOps cannot secure speculation.
Spec-Driven Development turns speculation into specification.
Design-time DevSecOps turns specification into enforceable security.
The future: security before generation
The next phase of secure development is not better scanning. It is governing what is allowed to be built.
Secure development becomes:
controlled generation
identity-bound permissions
compliant intent
guardrail-aware execution
The way we build software has changed. Security must change with it.
Conclusion
AI moved execution upstream. Agents act before pipelines. Code appears before architecture. Traditional DevSecOps cannot secure systems whose intent was never validated.
Design-time DevSecOps places security at the start of the lifecycle and transforms:
planning into security modeling
architecture into enforcement
design into policy
specification into governance
Security does not start after the commit.
It starts before the first line exists.
This is the necessary evolution of DevSecOps in the age of autonomous software.
Want the full deep dive? Check out my full article on Medium.
🚀 Stay tuned for more posts in AI Security & Development! Follow for more insights on securing AI, cloud, and Web3.
AI Security & Development - AI table of contents included.