Skip to content
Cybersecurity

Cybersecurity as code: how AI is changing both attackers and defenders

AI accelerates phishing, credential stuffing, and recon. It also accelerates detection, hardening, and triage. The discipline did not get easier; it got faster on both sides.

SDEN team10 min read

The premise

Cybersecurity in 2026 reads differently depending on which side of the firewall you are sitting on. Defenders describe a discipline that finally has the tooling and the budget it has been asking for. Attackers describe a market where the cost of running a credible operation has collapsed.

Both descriptions are accurate. AI accelerated the attack side first (phishing, credential stuffing, reconnaissance, malware generation) and it is now accelerating the defence side faster than at any point in the last decade. The net effect is that the discipline got harder, not easier.

This article is about what changed, what did not, and how a senior team approaches security work in this new shape of the threat landscape.

Why this matters now

The asymmetry shifted, but not in the direction we wanted

The cost of running a credible attack dropped faster than the cost of defending against it.

Phishing used to require literacy. It now requires a prompt. The attacker writes one line in their native language; a model produces a perfectly idiomatic, contextually plausible message in the target's language, tailored to their employer, their role, and their public footprint. The cost of producing that message is essentially zero. The cost of an employee falling for it has not changed.

This is not a hypothetical. It is the operational reality we see across our clients' inboxes. The volume of high-quality phishing has gone up by roughly an order of magnitude in eighteen months. The conversion rate has gone up too, though more slowly, because some defences still work.

The defender's job is to make the defences that still work cheaper to deploy, faster to iterate, and harder to bypass. That is engineering work, not awareness work.

Fig.: The asymmetry shifted, but not in the direction we wanted
What the discipline still covers

Security is an engineering discipline, not a compliance ritual

At SDEN, security work takes three shapes. First, security applied inside a delivery: threat modelling at the design stage, dependency scanning in CI, secret scanning, signed releases, secure-by-default architecture. This is the cheapest and most effective form of security work, because it removes whole classes of vulnerability before they exist.

Second, stand-alone engagements: audits, penetration testing scoped to OWASP Top 10 and ASVS levels, remediation roadmaps, and incident response. These are the engagements clients usually call us about, and the audit usually reveals that the cheapest fixes are at the design layer the system was never built with.

Third, compliance work: SOC 2, CCPA/CPRA, and PIPEDA, ISO 27001 readiness, SOC 2 readiness. Compliance is not security; it is the documentation that proves you took security seriously. We treat them as separate disciplines that happen to inform each other.

Fig.: Security is an engineering discipline, not a compliance ritual
Where AI changes the defender's job

Detection, triage, and the cases the human still has to take

On the defence side, AI changes three parts of the job. It changes detection, by surfacing anomalies inside the volume of logs no human team can read manually. It changes triage, by clustering alerts and proposing the most likely chain of events to investigate first. And it changes hardening, by automating the boring parts of code review and configuration audit.

What it does not change is incident response. When the alert is real and the data is leaving the network, the work is judgment under pressure, accountability for the decision, and communication with humans whose careers depend on being told the truth. None of that is delegable.

The pattern is the same as elsewhere in the blog: AI handles the volume; humans handle the judgment. The engineering work is to make sure the seam between them holds under stress.

Fig.: Detection, triage, and the cases the human still has to take
Before / after

How AI is changing the security stack

Four shifts that are visible inside the SOC, the audit room, and the incident response process. Symmetric across both sides of the firewall.

Before

An analyst reads ten thousand alerts a week, most of them false positives, missing the one that mattered around alert number 4,200.

After

A first-pass classifier ranks alerts by genuine novelty, clusters related events, and surfaces the three the analyst should look at first. The analyst still owns the call.

Takeaway · Detection volume stopped being the bottleneck. Attention became the bottleneck, and that one can be redirected.

Before

A phishing campaign is written in a foreign-sounding English that most employees instinctively flag.

After

A phishing campaign is written in the local language, mentions the recent all-hands by name, and arrives from a domain that resembles the company's vendor by one character. The reflex no longer works.

Takeaway · Awareness training is now necessary but no longer sufficient. The defence has to move into the inbox itself.

Before

A penetration tester spends a week mapping the attack surface manually before any meaningful testing begins.

After

A recon assistant produces the attack-surface map in an afternoon, with consistent depth across the engagement. The tester spends the week on actual exploitation, not on bookkeeping.

Takeaway · Penetration testing becomes deeper because the preparation is faster, for both sides.

Before

A code review for security issues is bolted onto the end of a feature and inconsistently performed.

After

An AI security pass runs on every pull request, flags known-bad patterns, and refuses the merge until they are addressed. The human reviewer focuses on the architectural issues the model cannot see.

Takeaway · Mechanical findings disappear from the human reviewer's queue. The queue gets shorter and more interesting.

Fig.: How AI is changing the security stack
How SDEN ships security

Three commitments on every security engagement

Security at SDEN is an engineering discipline, not a checklist. The pillars below are the ones we hold to even when the deadline gets tight.

Secure by default

Encryption, access control, secret management, and data isolation are wired into the architecture from day one. Adding them later costs four times as much and never reaches the same coverage.

Threat modelled at design

Every non-trivial feature gets a written threat model before code is written. We name the assets, the threat actors, the trust boundaries, and the mitigations. The threat model is a living document, not a workshop output.

Incident-ready, not just incident-resistant

We assume incidents will happen. The runbooks, the contacts, the legal posture, the backup integrity tests: all of these are in place before the breach, not improvised during it.

What good looks like

The posture you would want before the bad day

Security maturity is measured on the day the alert is real.

A mature security posture is not visible from the outside. It looks like a quiet team that knows where its data is, who can access it, how that access is logged, and what would happen if any of it left the network. It looks like a runbook that someone actually reads when the page goes off. It looks like an audit whose findings are tracked in the same ticket system as the rest of the engineering work.

The honest test is not the penetration test report. It is the incident response drill: a tabletop exercise that walks through a realistic scenario and exposes the seams between teams, decisions, and communications. We run these with our clients on every long-form engagement. The first one is always uncomfortable. The third one is the deliverable.

After that, security becomes what it is supposed to be: a property of the system, not a project that has to be repeated every year.

Fig.: The posture you would want before the bad day
FAQ

Cybersecurity:
questions we get asked.

Direct answers to the questions we get asked the most. If yours isn't covered, write to the team.

Let's get to work

Got a project worth building?

Tell us about your project. We work with a limited number of clients at a time, and we'll get back to you within 24 working hours with a first engineer's read, no commitment.

WhatsAppChat with the team
LinkedInFollow SDEN
X@sdenengineering