Your vulnerabilities are yours

Ask a senior engineer when someone last went looking for vulnerabilities in the service they own. Not a scanner that runs in CI and files tickets nobody reads. Someone actually trying to break it: reading the authorisation logic on every endpoint, following user input to wherever it ends up, checking what a leaked token could reach.

The honest answer is usually "the pen test," and the pen test was eleven months ago, scoped to two of the forty services, run by a firm that spent the first week learning what the product does.

A defensible answer, for a long time. Not anymore.

The claim

Every senior engineer should have an agent continuously looking for security vulnerabilities in the systems they own. Always on, pointed at their code, their infrastructure config, their dependencies and their running endpoints, with the findings landing in their queue.

And what it finds is theirs. Not the security team's.

Why "the security team handles it" was ever true

A staffing answer, never a principle. Finding a real vulnerability used to take a specific, scarce skill and a lot of slow reading. You had maybe one person in fifty who could do it well, so you pooled them, pointed them at whatever looked riskiest, and accepted that most of the code would never be examined by anyone with the right eyes. Everybody else wrote features and hoped.

It was a reasonable arrangement. For a company with one security engineer, it was the only one that fit the headcount. What held it together was the cost of looking: an expert's week was expensive, so looking was rationed, and rationing is the thing that created a separate team to do the rationing. Take the cost away and the reason for the separation goes with it.

The cost went away.

An agent will read every route handler in a service, trace every query back to where its parameters came from, and tell you which endpoint forgot to check that the caller owns the record, for the price of a coffee and some tokens. It won't find everything a great human researcher would. It will find the boring, common, exploitable things, which are the ones that actually get companies breached, and it'll do it every night instead of once a year.

So why does it land on the senior engineer

Because they're the only person who can tell a real finding from noise at the speed the agent produces them.

A security team looking at forty services is doing the same thing a reviewer does at forty diffs a day: demonstrating availability instead of exercising judgment. They don't know that the admin endpoint is only reachable from the internal network, or that the "unvalidated" field is an enum the ORM already constrains. The engineer who built it knows in thirty seconds.

They also know where the bodies are buried, the migration that was done in a hurry, the service account that got broad permissions because the narrow ones didn't work on a Friday.

Same rule as on-call. You build it, you carry it. Nobody would accept "the SRE team handles whether my service is up" from a senior engineer now. "The security team handles whether my service is safe" is the same sentence, and it should sound as strange.

It also changes what the security team is for, and I'd argue it makes them more useful rather than less. They stop being the people who find the holes and start being the people who make finding them cheap: they choose the agents, tune what they look for, set the severity bar, run the paved road so the fixes are easy, and go deep on the handful of things (payments, identity, the crypto nobody else should touch) where specialist judgment still earns its cost. A platform team, in other words, pointed at security.

It's a better job.

The excuses, one at a time

"We don't have time." You don't have time to read the code with a security eye. You have time to read a list of eight findings on Monday morning and fix the two real ones. The entire trade.

"It'll produce too many false positives." Some weeks, sure. Tuning it is your work, the same way tuning alerts is your work, and the engineer who complains that the security agent is noisy is usually the one whose pager was noisy too. Noise is a configuration problem you own.

"Security isn't my expertise." It doesn't need to be, for most of what matters. Broken access control, injection, secrets in the wrong place, a dependency four versions behind: none of these require a specialist to fix once someone has pointed at the line. The agent does the pointing. You do the fixing, and you learn the pattern, which is how the expertise gets built in the first place.

"The compliance audit covers it." It doesn't, and it never did. The audit checks that you do what you said you'd do. It doesn't check whether the endpoint you shipped last sprint leaks other customers' invoices.

"What if the agent finds something bad?"

Good. You found it first.

What it looks like in practice

Nothing elaborate.

Pick one agent that can read your repository and your infrastructure config. Give it a standing instruction to look for the handful of things that realistically get you breached, and have it run on a schedule and on every change to the parts of the system that touch authentication, payments or personal data. Findings go to the owning team's queue, not a security backlog, with a severity and the line number. (The full setup, step by step, is its own guide.)

Then treat a confirmed finding exactly like an incident. An owner, by name. A clock. And when it's fixed, a regression test so the same class of hole can't quietly come back. A security finding that sits unowned for a quarter is an outage that hasn't happened yet.

The one metric I'd watch is time from finding to fix, per team. Not the count of findings, which mostly measures how hard you're looking. A team with a lot of findings and a short fix time is healthy. A team with none is usually a team that isn't looking.

Two cautions, because the tool is powerful in both directions. Point it only at systems you own and are authorised to test. And give it the least access that lets it do the job (read the code, hit a staging environment) rather than production credentials, because an agent's blast radius is a design decision, and a security agent that could itself be the breach would be a poor joke.

What this asks of senior engineers

Seniority was always partly defined by what you'd take responsibility for without being asked. Performance. Reliability. Cost. The unglamorous parts of the system that nobody assigns and everybody depends on.

Security was the one exception we allowed, because the cost of looking was too high to ask of every owner. That exception is gone, and the attackers noticed first. They're pointing the same tools at your endpoints right now, without asking permission and without a quarterly scope.

So the question for a senior engineer isn't whether security is their job. It's whether they'd rather find their own vulnerabilities or read about them.