Assume the bug is there

This month’s PHP flaws are a useful reminder. Two critical bugs in the core of PHP, each letting an unauthenticated visitor run code on the server, were patched on 21 October after the details leaked a day early. We run no PHP. That is not the point. The point is that the most dangerous bugs sit below the application, in the language runtime, the libraries and the databases that every application stands on, and nobody who builds on them can see them in advance.

Finding such bugs is also getting cheaper. Models that read code are now good at it, and attackers can run capable open models on their own hardware. So here is what we will not say: that our software has no vulnerabilities. Nobody’s does, and a vendor who claims otherwise is selling an adjective. What we can describe is how we build so that a bug is found early, fixed fast and cannot reach far, at each stage of the work.

Design: decide what cannot happen

The cheapest vulnerability to fix is the one the design makes impossible. The platform is written in a memory-safe language, runs a small number of services, and is designed to give each customer a dedicated deployment with no shared network or database between customers, so one customer’s incident is not another’s.

Authority is designed in, not added. Code checks permission keys, never job titles. A route with no declared permission refuses everyone rather than admitting everyone. A service calling another service must present its own signed token, because “it is only internal” is not a reason to leave a door open. Sign-in uses passkeys, so there is no password to guess or spray. The person who prepares a payment can never approve it, whatever else they hold.

These decisions are written down as numbered rulings in the repository. A rule that lives in someone’s head gets quietly undone; a rule in the repository is checked by the next change.

Build: every rule comes from a failure

Our standing rules read like a list of scars, because that is what they are. One exists because a missing number once passed as zero and produced a figure that looked real. Another exists because an unawaited message send once raced, and a failed send was marked as sent. Each rule names the incident behind it, so the next person, or the next agent, knows what it is for and does not simplify it away.

We build with AI agents under written rules and delivery gates, and a human holds the approval that matters. Agents review the work as well as write it, which brings us to the part most relevant this month.

Prove: tests that can fail

More than seventy end-to-end suites run against real infrastructure, a real database and a real message broker, with no mocks standing in for them. On every push a build gate type-checks and bundles all sixteen projects. A fix is not finished until a test that reproduced the bug now passes. And the tests are held to a standard: a permission check tested with a super-user token proves nothing, because that token passes every check, so we test with an identity that holds exactly the permission under test.

Review: AI on the defending side

In September we pointed five review agents at our own code, in parallel, with one question: where would an attacker with a capable model look first? They returned ranked findings, each checked against the code. Two were the kind that only appear when you read the system as a whole. In one, a model’s verdict about a document could have been steered by hostile text inside that document into clearing a fraud flag. In another, an automated agent’s action depended on a confidence number that the model itself set. We made the identity comparison deterministic, so no model verdict can clear it, and put a rule-based gate in front of the agent’s actions. The fixes were written the same day and merged after review.

The principle we took from it applies well beyond our code: a language model is an untrusted step between untrusted input and a trusted decision. It may propose. It may not be the only thing that decides.

Operate: speed and containment

When a flaw is disclosed, the time to exploitation is now measured in hours, partly because models help attackers read a patch and write an exploit for it. Our answer has two parts.

Speed. A fix is a pipeline, not a project: update the dependency, rebuild, run the full suite, redeploy, and roll back to the previous release if anything misbehaves. We are adding a written target for critical fixes, measured in hours rather than weeks, along with automated dependency audit and image scanning on every build.

Containment. Assume a bug will be exploited and ask how far it gets. A private data tier, least-privilege roles, rate limits, a web application firewall in front of production that can block a known exploit pattern while a fix is built, and isolated deployments per customer. One flaw should land an attacker in a small room.

The AI work continues on this side. We are extending the September review into a routine one: agents that read each change for security flaws and then try to disprove their own findings, that map published advisories to the exact versions we run, and that triage alerts. Each begins in shadow mode, alongside the human process and compared with it, and earns more autonomy only on evidence. Anything that changes production still waits for a person. We also keep our own AI tools patched. They are software too, and they have had flaws of their own.

What to ask a vendor

Not whether they have vulnerabilities. Ask how long a critical fix takes from disclosure to production, what evidence shows a control works, what happened the last time a review found something, and how far a single flaw can reach. We try to answer those with numbers.