Context Is All You Need - Rethinking software security in the age of AI
8 September 2026
For a long time, we have treated software security as a problem of finding vulnerabilities. And to be fair, we have become very good at it.
When I started working with software security, a security assessment might result in a manageable number of findings. Someone would actually read them. A security engineer and a developer could sit down, discuss what they meant, understand the application, and decide what to fix.
Then we industrialized vulnerability discovery.
We added SAST. SCA. DAST. Container scanning. Infrastructure-as-code scanning. Cloud security tools. Kubernetes scanners. Secret scanning. SBOMs. More rules. More feeds. More dashboards. Finding twelve potential vulnerabilities became finding twelve thousand.
Somewhere along the way, however, I think we started optimizing the wrong thing. We got better and better at producing security findings, collecting them, deduplicating them, prioritizing them, visualizing them and turning them into tickets.
But did we become equally good at making our software more secure?
I’m not so sure.
Welcome to the vulnerability factory
Picture a normal team on a normal Monday. A developer opens the security dashboard: 437 open findings, twenty-two Critical, eighty-six High. Some come from dependencies, some from infrastructure, some from the code. Several describe the same underlying problem. A few aren’t reachable in production. Some are technically correct and practically irrelevant. And buried in there, one or two genuinely matter.
Meanwhile they’ve got a sprint to deliver, a production issue to deal with, and a product owner asking when the next feature is ready. We hand them the dashboard and call it actionable security.
I don’t blame the scanners — most are remarkably good at what they were designed to do. The problem is that we let the output of scanning tools become the unit of security work. More scanners, more findings, more aggregation, more dashboards, more prioritization, more tickets. And then we act surprised when developers experience security as an endless queue of things somebody else wants them to fix.
We built a vulnerability factory.
Detection isn’t the scarce resource anymore
The economics are strange. Generating another thousand findings is cheap. Working out whether one of them is a real risk is expensive. Understanding why the same issue keeps appearing across twenty applications is more expensive still. And deciding which architectural change would remove that whole class of problems needs something scarcer than another scanner.
It needs context.
A scanner can tell me user-controlled input reaches a sensitive function. That’s rarely enough to decide anything. I also want to know what the application does, who can reach it, what data it handles, where the trust boundaries sit, whether that path is even live in production, what identity the workload runs as, what compensating controls exist, and what an attacker would actually gain. And above all: why does this application look like this in the first place?
That’s the gap between detecting a potential vulnerability and understanding risk.
We already know that context works
None of this is particularly new. We’ve always had ways to get good context; we call them threat modeling, architecture review, and penetration testing.
Put a few experienced people in a room with the developers, hand them diagrams, code, and data flows, and give them time. The conversation changes immediately — instead of CVSS scores you’re talking about attack paths, trust assumptions, business impact, and design choices. Good penetration testers do the same from another angle: before they find anything interesting, they spend a surprising amount of time working out how the pieces fit, what the developers assumed, and what can be combined in a way nobody expected.
It works beautifully. It just doesn’t scale. You can’t put experts around every repository every week, so that depth has always been reserved for a tiny sliver of the software estate.
And that’s exactly where AI changes something fundamental.
AI changes the economics of context
Most of the excitement about AI in security is about finding vulnerabilities, filtering false positives, or generating fixes automatically. All useful. But I don’t think it’s the interesting part.
The big shift is that AI makes it cheap to build and maintain context. For the first time we can hand a machine most of what a security architect or penetration tester would otherwise collect by hand — code, configuration, infrastructure and deployment definitions, architecture documentation, dependencies, security requirements, previous findings, threat models, runtime information, design decisions — and ask it to reason across all of it at once. For teams fortunate enough to maintain a monorepo with documentation co-located with code, capturing this full picture is even simpler: the system’s architecture, history, requirements, and implementation are already in the same place, ready for continuous analysis.
That changes the question. Instead of “Is finding 4217 a false positive?” we can ask: “What is stopping this application from becoming dramatically more secure?”
Now that’s a question worth asking.
Please don’t build a smarter vulnerability queue
So I’ve been experimenting: feed AI the whole picture, then don’t ask it to fix the findings. Ask it instead to describe a path from where the application is today toward a genuinely stronger security architecture. I call the result a security architecture roadmap, and the distinction matters.
Say an application has eighteen findings about weak credential handling. The traditional answer is eighteen tickets. The smarter-AI answer analyzes them, decides twelve are real, and writes twelve fixes. Better! But still whack-a-mole.
A roadmap says something else entirely:
- Introduce workload identity.
- Migrate services off long-lived credentials.
- Remove static cloud credentials from application configuration.
- Add policy that blocks new static credentials.
- Continuously detect deviations.
- Retire the legacy mechanism once migration is done.
Now we’re not fixing eighteen problems. We’re changing the system so an entire class of problems becomes hard to create.
Think about what that means at scale. If AI automatically fixes a hundred vulnerabilities in a repository, fantastic — but what if ninety of them come from three bad architectural patterns? Wouldn’t it be smarter to fix the three? Chewing through a backlog faster is genuinely useful, but if that’s all we do, we’re automating the old operating model instead of improving it. The real opportunity is to climb: from findings to patterns, patterns to root causes, root causes to architectural change, and from there to security properties we can actually enforce.
The goal was never an empty dashboard — that might just mean our scanners are looking in the wrong places. The goal is an architecture where the secure thing is also the easy, normal thing.
Invariants instead of vulnerability counts
That changes how we describe the destination, too. Instead of “we want zero Critical vulnerabilities,” we can start saying things like:
- All workloads use short-lived identities.
- All Internet-facing services go through the approved ingress architecture.
- Applications don’t implement their own cryptography.
- Authorization uses approved mechanisms.
- Secrets never live in source code or static deployment configuration.
- Dependencies are maintained automatically within an agreed policy.
- Security-relevant deviations are detected continuously.
I think of these as security invariants: things we want to remain true about our systems. Once you name them, security stops being a chase after an endlessly changing list and becomes a matter of moving applications toward a known architectural direction.
One roadmap per repository — then five hundred
Every repository can have its own roadmap. Not a document written once and forgotten, but something that evolves with the application: where are we today, what are the biggest structural risks, what should the target state look like, what do we change first, which changes remove the most risk, which controls should become automatic, what’s in the way. That’s continuous security architecture rather than vulnerability management, and it gives developers the one thing a dashboard almost never does: direction. Not just what’s wrong, but where we’re going.
Then it gets really interesting. Build one roadmap and you learn about one application. Build five hundred and you start learning about your organization. Maybe fifty repositories independently show teams struggling with workload identity. Maybe thirty built their own authorization mechanisms. Maybe static secrets keep turning up everywhere, or secure ingress keeps going wrong, or every team invented a slightly different flavor of dependency management.
Those aren’t application-level problems anymore. They’re architecture and platform problems, and that information can flow upward — into a North Star security architecture grounded in what’s actually happening in your code.
A North Star, not a document on a shelf
Most large organizations already have security architecture documents, and some are genuinely good. But there’s usually a painful gap between the architecture we describe centrally and the software teams actually build.
AI lets us close that loop. The North Star says where we’re going. Standards and platforms help teams get there. Repositories show us what really happens. AI continuously analyzes the gap, roadmaps describe how each system should evolve, and the patterns across those roadmaps tell us where the North Star, the platforms, or the standards themselves need to improve. Then it starts again.
Security architecture stops being a document and becomes a continuous learning process.
Maybe vulnerabilities were the wrong abstraction
There’s a more philosophical thought hiding in here. We picture insecure software as software containing a pile of vulnerabilities. But vulnerabilities usually aren’t random. They’re symptoms — of complexity, bad defaults, missing platform capabilities, old frameworks, weak identity models, poor isolation, inconsistent authorization, manual configuration, ambiguous ownership, and architectural decisions made years ago. If that’s true, then managing them one by one was always the wrong level of abstraction.
We still need scanners, findings, and deterministic controls, and sometimes we absolutely need to fix one specific vulnerability right now. But findings should be signals, not the destination. They help us understand the system, and that understanding should improve the architecture.
Context is all you need
For years we assumed the limiting factor in software security was our ability to detect vulnerabilities. It wasn’t. We became exceptionally good at detection. What we never had was enough understanding to act on all those signals intelligently.
Context was the scarce resource. AI may be about to make it abundant.
If it does, let’s use it for something more ambitious than a faster vulnerability queue: to genuinely understand our systems, find the structural problems, eliminate whole categories of vulnerabilities, make good security properties automatic, and keep pulling the whole estate toward a shared North Star.
Because the best vulnerability isn’t the one an AI finds and fixes in thirty seconds.
It’s the one your architecture no longer lets anyone create.
That is where a North Star security architecture ultimately leads: Secure by Design. By turning security properties into shared architectural direction, and by making them easier to enforce than to bypass, we move from reacting to vulnerabilities toward designing systems that prevent whole classes of vulnerabilities.
Further reading on Secure By Design topics can be found in the in-depth article series Defense In Depth