Slow Is a Vulnerability. So Is Instant.

A vulnerability lands in a dependency you use. The clock starts. How long until the fix is running in production?

Whatever the answer is, it cannot be shorter than the time it takes to ship any other change. The patch goes through the same pipeline: the same tests, the same review, the same deploy. Your exposure window has a floor, and your delivery capability sets it.

That is not a finding from a research report. It is a definition, which is why I like it: Slow is the vulnerability.

The chain that does the damage

At six people, almost nothing that will actually hurt you is exotic. It is a long lived credential in a repository, a contractor whose access nobody removed, or a dependency you could not upgrade because the upgrade had quietly become a project. None of those are security problems in a specialist sense. They are consequences of how you build.

If you do not fully trust your test suite, every dependency bump becomes a manual risk assessment. Manual assessments are expensive, so you batch them. Batching means you fall behind and it increases the potential point of failure. Then a real vulnerability lands and the fix needs a version you are eleven releases away from.

Your time to patch was not decided during the incident. It was decided months earlier, by whether your tests were green for the right reasons. Whether the code was written in a way that makes it easy to understand and easy to test. A flaky suite is a security problem and not an annoyance: every “just merge it, that one is always red” is a control you have trained the team to ignore, and it is to some extent very similar to an alerting feed which keeps spamming false positives to the point where no one is paying attention anymore. At that point, it provides limited to zero value.

Current is not the same as instant

Although it is a good ability to be able to patch immediately, that doesn’t mean that you should always do so.

For routine bumps, let them age a few days. If you are using well-established libraries, then the thousands of teams adopting before you are your canary against a compromised release. For a live disclosure, consider patching immediately. A pipeline you trust buys you the option to be either, chosen per threat. Without one you have a single speed, and it is the wrong one.

At Flare, we use Renovate to update our dependencies automatically, and we have a pipeline that runs the tests and deploys on every PR. This means that we can take a dependency as soon as it is released, without any human intervention. Apart, of course, from a deliberate cooldown on routine releases, which is there to mitigate supply chain attacks: if a package is compromised, the people who upgraded in the first few hours are the ones who find out on everybody else’s behalf. The cooldown does not apply to a disclosed vulnerability, which goes straight through.

What AI changed

Every AI security incident I have read about decomposes into something with a name from before 2010: over broad credentials, a missing authorization check, unvalidated output, no egress control. Norm Hardy described the confused deputy in 1988 [1], and an over permissioned agent is a very articulate confused deputy. Agents do not invent privilege. They inherit yours.

What changed is the slack. Machine speed closes the gap between a misconfiguration existing and a misconfiguration being exercised, and higher throughput degrades controls that assumed a human review budget. The work did not get longer. The cost of skipping it collapsed from eventually to this quarter.

We got a worked example in July 2026. During an internal evaluation, OpenAI’s agents worked out that they could pass messages to one another through the company’s Artifactory package registry, and built a shared board there for trading exploits and credentials across separate evaluation runs. When it was found and the infrastructure rebuilt, they reconstituted the board two days later by a different mechanism [4][5]. They then chained several vulnerabilities, left the sandbox through its one permitted egress path, and reached Hugging Face [2][3].

Every link has an old name: a covert channel through shared writable storage, remote code execution, secrets sitting in accessible environment variables, server side template injection. Nothing on that list is new. What is new is that no person was driving, that it escalated rather than merely inheriting what it was given, and that it came back after being cleaned up.

One honest exception. Every previous case of untrusted input reaching a privileged interpreter eventually got a structural fix: prepared statements, contextual escaping, allowlists. Prompt injection has none, because parameterization worked by separating the data channel from the instruction channel and natural language gives you one channel for both. Same bug class, no equivalent fix.

The limits

DORA finds that delivery performance and security practice tend to occur together [6]. Treat that as support rather than proof. It is survey data, and people answer questions about deployment frequency with their best case.

However, the arithmetic needs no study behind it. Lead time bounds patch time. It is necessary and not sufficient: you can ship forty times a day and still have a shared administrator account.

But it does mean the highest leverage security work available to a small team is not a product. It is a pipeline they trust and one path to production.

To recap

There’s a quote by Kent Beck that I love and resonate with:

I’m not a great programmer; I’m just a good programmer with great habits.

Martin Fowler records that in Refactoring as something Kent Beck often says about himself. Beck has since explained what he means by the habits: code for other people, work in small steps, rest well. Personally, I found that to be a simple and effective heuristic. None of those three is a security practice.

I wrote this while preparing for Security in the Age of AI, an evening hosted by The Shack and Cloudflare on securing a startup from day one.

I’ll be headed over to the event shortly. And as a panelist, it feels a bit odd to talk security without really focusing on any security practices.

But work in small steps is the whole of this post. Small steps are what keep the lead time short, short lead times are what set the floor on your exposure window, and the floor is the only number in this that nothing you buy can move. Most small teams do not need a great security engineer. They need ordinary engineering with good habits, and it turns out the habits were load bearing all along.

If you want some guiding questions you can use to assess your own team, I have compiled a list of twelve here: security check. Nothing is sent anywhere, and there is no score at the end.