Detection in one repo isn't a security posture

TL;DR

Most security tooling is very good at one thing: finding a problem inside a single repository. That feels like security. It isn't. A finding in one repo is a fact. A security posture is knowing whether that same problem exists across every repo you own, stopping it from spreading, and fixing it everywhere at once.

Prevention, detection, and response aren't three separate programs you can buy and bolt together. They're one problem, and the connective tissue between them is visibility across the whole codebase. Break the visibility and all three degrade together.

AI is now writing a meaningful share of production code and pulling in dependencies faster than any human review process was built to handle. That doesn't add a fourth problem. It strains the one you already have.

The reframe

Walk into most engineering orgs and ask how they think about application security, and you'll get a tool inventory. A scanner here. A dependency checker there. A secrets detector in CI. Each one is competent inside its lane, and each one operates inside the boundary of a single repository.

Here's the assumption baked into that setup: if every repo scans itself, the sum of those scans is your security posture.

It isn't, and the gap shows up the moment something goes wrong. A vulnerability gets disclosed in a widely used library. The real question isn't "is this repo affected." It's "which of our 3,000 repos pull this in, directly or transitively, and how fast can we patch all of them." Most teams cannot answer that in an afternoon. Many cannot answer it in a week. That delta, between detecting a problem in one place and understanding it everywhere, is where breaches live.

So the reframe is this. Prevention, detection, and response are not a pipeline of independent steps. They're the same capability viewed at three moments in time, and each one depends on the same thing: complete, queryable visibility across every repository you own.

• Prevention is detection applied before code ships, which only works if you can see the patterns you're trying to stop everywhere they might appear.
• Detection is worthless at one-repo resolution if the same flaw sits in forty other repos you didn't scan in the same pass.
• Response is just detection plus the ability to act, at scale, across every affected repo at once, before the window closes.

Optimize one in isolation and you haven't moved your posture. You've bought a better flashlight for one room in a building you can't see the floor plan of.

Why this is getting harder, fast

Two things are bending the curve, and neither is hypothetical.

First, volume and velocity. AI assistants are now writing a large and growing share of the code that ships. Microsoft's CEO has said as much as 30% of the company's code is AI-written, and Google has reported a similar share for new code. More code, generated faster, means more surface area entering your repos every day than human review was ever sized to inspect. Detection that depends on someone eventually looking falls further behind every sprint.

Second, dependency sprawl. Modern applications already carry around 180 dependencies on average, and AI-assisted development pulls in more, faster, often resolving a build error by installing whatever package makes it go away. The attack surface is expanding in exactly the layer teams have the least visibility into. And attackers have noticed. Sonatype identified more than 454,600 new malicious packages in 2025, a 75% jump year over year, including the first self-replicating npm malware that spread across more than 500 packages on its own.

Put those together. You're shipping more code, faster, that depends on more third-party code, faster, while the malicious share of that third-party code is climbing. The volume of things you'd need to detect is rising. The time you have to respond is falling. And none of it respects repository boundaries.

A package can be safe on Monday and compromised on Tuesday. A pattern your linter flags in one repo can already be living in fifty. The problem was never confined to a repo. Our tools were.

What good actually looks like

You don't need a product to know whether your posture is real. You need to be able to answer a few questions honestly, in minutes, not weeks. A team with genuine codebase visibility can:

• Find every instance, everywhere. Given a vulnerable version, a risky pattern, or a leaked credential format, locate every repo that contains it, including transitive dependencies, in a single query.
• See the blast radius before acting. Know how many repos, services, and teams a given issue touches before triage, so prioritization is based on reach, not guesswork.
• Fix at the same scale you detect. Apply a patch or a pattern change across every affected repo in one coordinated motion, not one pull request at a time.
• Prevent the next instance. Feed what you found back into the checks that run before code merges, so the same class of problem can't quietly reappear in repo 3,001.

If your honest answer to any of these is "we'd have to check each repo," you have detection. You don't yet have a posture.

The takeaway

Security is a codebase visibility problem, and most teams are solving the wrong part of it. They're investing in sharper detection inside individual repos while the real risk lives in the space between repos, the space AI is filling faster every day. Better scanners won't close that gap. Visibility across the entire codebase will, because it's the one capability that prevention, detection, and response all quietly depend on.

Read The codebase visibility security framework to learn more.