Security Left, Security in the Cloud, and the New Question of Securing AI Itself

“Shift left” has been a slogan in application security for long enough that it risks becoming background noise, but the underlying problem it addresses has not gone away: fixing a design flaw after deployment costs vastly more, in both money and risk exposure, than catching it during design or the first sprint. What has changed is that the tooling to actually do this well has matured, and — more recently — that AI-assisted development has changed both the speed at which code gets written and the shape of the risks security teams need to catch.

Threat modelling still earns its place at the start

Of everything under the DevSecOps umbrella, threat modelling remains the practice most often skipped under deadline pressure, and it is usually the one whose absence is most expensive later. A lightweight threat model — done early, revisited when the architecture changes materially, not treated as a one-time document — forces a team to answer a small set of genuinely useful questions: what are we building, what can go wrong, what are we doing about it, and did we do a good enough job. I have found that even an hour spent on this with the right people in the room (not just security, but the engineers who actually know the data flows) catches design-level issues that no amount of downstream scanning will find, because a scanner cannot tell you that an API endpoint has no business exposing a particular field to unauthenticated callers.

Embedding SAST and DAST into CI/CD pipelines is now reasonably standard practice, but the value depends entirely on how it is tuned. A SAST tool dropped into a pipeline with default rules and no baseline tuning tends to produce a wall of findings that developers learn to ignore within a sprint or two — the same alert-fatigue dynamic that plagues SOCs applies here just as much. The pipelines that actually change developer behaviour are the ones where findings are triaged for relevance before they ever reach a developer’s queue, where the security team has done the work of suppressing genuine noise, and where a small number of high-confidence, high-severity findings block the build while lower-confidence ones are tracked without blocking delivery. Security-by-design succeeds or fails on whether it is engineered to fit into how developers actually work, not on how comprehensive the tool’s rule set is on paper.

Cloud security fundamentals do not change by provider, but the details do

Across AWS, Azure, and GCP-type environments, the fundamentals are consistent even though the console layouts and terminology are not: identity and access configuration is where most real-world cloud incidents originate, not exotic zero-days. Overly permissive IAM roles, storage buckets or blob containers left with broader access than intended, and secrets committed into infrastructure-as-code repositories remain the recurring, unglamorous causes of cloud breaches I encounter. The shared responsibility model is well understood in principle but poorly internalised in practice — I still meet teams who assume the cloud provider is responsible for security configuration of the resources they themselves provisioned, when the provider is only ever responsible for the security of the underlying platform.

Infrastructure-as-code has been a genuine net positive for security, because it makes configuration reviewable and version-controlled rather than a matter of who clicked what in a console last Tuesday. But it also means a misconfiguration, once baked into a template, replicates itself automatically and at scale — which makes policy-as-code scanning of IaC templates before deployment one of the higher-leverage controls available to a cloud security programme, catching issues before they ever become runtime findings.

Securing AI systems: a genuinely new problem, not a rebrand of the old one

This is where I think the industry conversation is least mature, and it is worth separating two distinct problems that get conflated constantly: securing AI/ML systems themselves, and securing the organisation’s data and processes as AI tools get adopted throughout the business.

On the first: AI/ML systems introduce attack surfaces that traditional application security does not fully cover. Data poisoning — where an adversary manipulates training data to corrupt a model’s behaviour — is a real risk for any system that trains or fine-tunes on data with insufficiently controlled provenance, and it is very difficult to detect after the fact, because the model simply behaves subtly wrong rather than failing loudly. Model risk more broadly deserves the same rigour applied to any other critical business logic: version control, testing against adversarial and edge-case inputs, and clear accountability for what happens when a model’s output is wrong in a way that causes harm — a question that intersects directly with GDPR’s provisions on automated decision-making where personal data is involved.

The data side of this is where I have spent considerable direct time, working on data matching and testing involving machine learning algorithms, and it has convinced me that unstructured data is the harder and more neglected half of the AI security problem. Structured data has decades of established classification, access control, and DLP tooling behind it. Unstructured data — documents, emails, chat logs, scanned images, increasingly the free-text inputs and outputs of AI systems themselves — is much harder to classify at the volume and speed AI adoption demands, and it is exactly the corpus most likely to contain personal data, credentials, or sensitive business information that ends up, unintentionally, inside a training set or a retrieval-augmented generation pipeline. Any organisation deploying AI systems that touch unstructured data needs a genuine data governance answer to “what is actually in this corpus” before the model goes anywhere near it — and in my experience, most organisations do not yet have that answer with any confidence.

AI as a tool for developers and security teams alike

The second dimension is closer to home for security teams: AI coding assistants and copilots have materially changed how quickly code gets written, and the security implications cut both ways. On the risk side, I am seeing code shipped faster than review capacity can keep pace with, AI-suggested dependencies pulled in without the scrutiny a human would have applied by habit, and a subtle erosion of developers’ own understanding of code they did not fully write themselves — which matters enormously when that code needs to be debugged under incident pressure at 3 a.m. There is also a quieter data governance question: what happens to proprietary or sensitive code and configuration once it is pasted into a third-party AI tool, and whether that tool’s data handling terms are compatible with the organisation’s own obligations.

On the opportunity side, the same tools are genuinely useful for security teams — accelerating log analysis, drafting first-pass detection rules for review, summarising incident timelines, or triaging low-complexity SAST findings faster than a human would alone. The honest, balanced position, in my view, is that AI is a capable accelerant for both developers and defenders, but it does not remove the need for human judgement at the points that actually matter — architectural decisions, sign-off on production changes, and interpretation of ambiguous incident evidence. Organisations that treat AI output with the same scrutiny they would apply to a junior team member’s first draft, rather than as an authoritative answer, are the ones getting real value from it without quietly accumulating new risk they have not yet had to price in.