The software development lifecycle was designed for human development speeds. AI may have already rendered that assumption obsolete.

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For decades, organizations have invested heavily in building secure software development lifecycles.

• Threat modeling.
• Code reviews.
• Architecture reviews.
• Static analysis.
• Dynamic testing.
• Penetration testing.
• Security gates.
• Compliance checks.

The objective was simple.

Ensure that software becomes more secure before it reaches production.

The Secure Software Development Lifecycle (Secure SDLC) became one of cybersecurity’s most successful governance models.

It worked because it reflected a fundamental assumption about software development:

• Humans write software.
• Humans review software.
• Humans approve software.
• Humans deploy software.

The entire model was built around human speed.

Artificial Intelligence is beginning to challenge that assumption.

Not because Secure SDLC is wrong.

But because AI may be changing software creation faster than Secure SDLC can adapt.

And for many organizations, the most significant software security challenge of the next decade may not be vulnerabilities.

It may be the growing mismatch between machine-speed development and human-speed governance.

The Original Logic of Secure SDLC

Secure SDLC emerged from painful lessons.

Organizations realized that security could not be added after deployment.

It had to be integrated into development itself.

The principle was revolutionary at the time.

Security shifted left.

Instead of discovering vulnerabilities after release, organizations attempted to prevent them during design and implementation.

The model relied on checkpoints:

• Requirements.
• Architecture.
• Development.
• Testing.
• Release.
• Operations.

Each stage provided an opportunity to identify risk.

The approach was effective because software development followed a relatively predictable rhythm.

Projects progressed at human speed.

Security reviews could keep pace.

Today, that rhythm is changing.

AI Changes the Economics of Change

Historically, software creation was expensive.

Developers represented the limiting factor.

Every feature required effort.

Every service required planning.

Every integration consumed resources.

As a result, organizations naturally limited the volume of software they produced.

AI changes this equation.

The cost of creating software is falling dramatically.

Teams can generate:

• code
• tests
• documentation
• APIs
• infrastructure
• automations

at speeds previously unimaginable.

Most discussions focus on productivity gains.

Few focus on governance capacity.

Because while development accelerates, review processes remain fundamentally human.

This asymmetry is becoming increasingly important.

Security Review Is Becoming the Bottleneck

In many organizations, development is no longer the slowest activity.

• Security review is.
• Architecture review is.
• Risk assessment is.
• Compliance validation is.
• Threat modeling is.

The situation creates an uncomfortable reality.

AI can generate software faster than organizations can evaluate it.

This does not mean security teams are failing.

It means they are operating within a model designed for a different era.

A model where software generation was constrained.

A model where security could reasonably inspect what development produced.

That assumption may no longer hold.

The Volume Problem

Most security controls scale poorly.

• A code review takes time.
• A threat model takes time.
• A penetration test takes time.
• An architecture review takes time.

Human expertise remains essential.

Unfortunately, human expertise does not scale exponentially.

Software generation increasingly does.

Imagine a development organization that doubles software output through AI-assisted development.

What happens to:

• security reviews
• architecture reviews
• penetration testing
• governance approvals

Do they double as well?

Usually not.

The result is predictable.

Review capacity becomes saturated.

Queues grow.

Controls become rushed.

Exceptions increase.

Eventually, governance becomes perceived as an obstacle rather than a safeguard.

This is where Secure SDLC begins to fracture.

The Threat Model Crisis

Threat modeling has long been one of the most valuable security activities.

It forces teams to think before they build.

• Trust boundaries.
• Attack paths.
• Failure scenarios.
• Data flows.
• Security assumptions.

All become visible.

The challenge is that threat modeling is fundamentally a thinking exercise.

AI can generate systems quickly.

Understanding those systems still requires human reasoning.

As architectures become more dynamic and software creation accelerates, organizations face a difficult question:

Can threat modeling keep pace with software generation?

For many enterprises, the answer may increasingly be no.

Not because threat modeling lacks value.

But because volume overwhelms capacity.

Code Review Was Never Designed for This

Code review assumes something important.

A human wrote the code.

Another human reviews it.

Both understand the context.

AI introduces a new dynamic.

The author may not fully understand every generated implementation detail.

The reviewer may not fully understand every generated implementation detail.

Yet both are expected to approve the result.

The review process remains intact.

Its effectiveness changes.

Organizations may begin conducting reviews that verify functionality without fully validating understanding.

That distinction is critical.

Security failures rarely emerge from syntax.

They emerge from misunderstood assumptions.

The Coming Architecture Review Breakdown

Architecture reviews face a similar challenge.

Historically, architecture evolved deliberately.

Major decisions were visible.

Design discussions occurred.

Trade-offs were documented.

AI encourages a different pattern.

Incremental generation.

Rapid iteration.

Continuous change.

Small local decisions accumulate rapidly.

The architecture remains functional.

Until nobody understands the architecture as a whole.

At that point, architecture reviews become reactive rather than preventive.

The review process still exists.

Control begins to disappear.

The Audit Illusion

Many organizations will respond by strengthening documentation.

More evidence.

More approvals.

More records.

More reports.

This creates a dangerous illusion.

The appearance of governance.

Not governance itself.

An auditor may confirm that:

• reviews occurred
• approvals exist
• controls were followed

Yet none of those facts guarantee that software remains understood.

Secure SDLC can become audit-ready while simultaneously becoming less effective at controlling risk.

The distinction is subtle.

It is also critically important.

Audit-ready is not risk-ready.

The same principle increasingly applies to software development governance.

Why Automation Is Not Enough

The obvious response is automation.

Automated reviews.

Automated testing.

Automated security analysis.

Automated compliance validation.

These capabilities are valuable.

Organizations will need them.

But automation cannot fully replace judgment.

A scanner can identify vulnerabilities.

It cannot determine whether a service should exist.

A tool can identify misconfigurations.

It cannot evaluate architectural intent.

An AI can detect patterns.

It cannot assume accountability.

Secure SDLC ultimately depends on human decisions.

And human decisions remain difficult to automate.

The Governance Challenge

The deeper issue is not technical.

It is organizational.

Most governance functions operate at human speed:

• security
• compliance
• audit
• architecture
• risk management

AI-assisted development increasingly operates at machine speed.

The resulting mismatch creates a governance challenge.

Not because controls disappear.

Because controls cannot scale indefinitely.

Eventually, organizations encounter a choice.

Either governance evolves.

Or governance becomes overwhelmed.

The latter outcome is surprisingly easy to miss.

Everything appears operational.

The processes remain.

The documents exist.

The approvals continue.

Meanwhile, actual understanding quietly declines.

What the Next Secure SDLC Must Become

The future Secure SDLC cannot simply be a faster version of today’s model.

It must become a different model.

One that assumes:

• AI-assisted development
• continuous generation
• dynamic architectures
• autonomous tooling
• increasing software volume

Future governance will likely focus less on reviewing individual artifacts and more on governing the systems that create them.

In other words:

The object of governance changes.

Instead of reviewing every output, organizations must increasingly govern the mechanisms that produce outputs.

This is a profound shift.

And many organizations have not yet recognized it.

The Future of Security Review

For years, security review focused on software.

The future may require security review to focus on software generation itself.

How is software created?

Which guardrails exist?

Which architectural constraints apply?

Which security assumptions are enforced automatically?

Which risks require human escalation?

These questions become increasingly important as AI expands throughout software development.

Because the greatest risk may not be insecure code.

The greatest risk may be believing that governance can continue operating exactly as it did before.

The Real Challenge

Secure SDLC is not becoming obsolete.

Its underlying principles remain valid.

Security still belongs in development.

Governance still matters.

Architecture still matters.

Review still matters.

The challenge is scale.

The model was built for developers.

It was built for human development velocity.

AI is introducing something fundamentally different.

Machine-assisted software creation operating at speeds governance was never designed to manage.

The organizations that succeed will not be those that generate the most software.

They will be those that redesign governance before governance becomes the bottleneck.

Because security review was designed for developers.

Not for machines.

And the organizations that fail to recognize that distinction may discover it during their next major incident.

Publication Note & Disclaimer
This article was originally published on LinkedIn on January 30, 2026 and may have been edited or updated for publication on this site.

It reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.