There are three clocks running in every software organisation, and they are set to different speeds.
The first is the release clock. Teams that deployed monthly five years ago now deploy weekly, and teams that deployed weekly now deploy several times a day. The tooling that made that possible is mature, and AI assisted development has compressed it further. A feature that used to take a sprint takes an afternoon.
The second is the attacker clock. Reconnaissance, enumeration and the first attempts against a newly exposed surface used to take a person days of work. Automation shortened that considerably. Automation with a model behind it has shortened it again, and the interval between something appearing on the internet and something probing it is now measured in minutes rather than days.
The third is the testing clock. It runs in quarters. In many organisations it runs annually, because that is the cadence a compliance framework requires and a procurement cycle allows.
Nobody designed that arrangement. It is the residue of a period when the first clock also ran in quarters, and the third one has not been reset since.
Why the mismatch is worse than it sounds
The obvious problem with an annual penetration test is that it goes stale. That is true and it is the version of the argument most people already accept.
The less obvious problem is that a scheduled test cannot see the thing that most often causes an incident, because of when the test happens relative to when the exposure appears.
Work through the sequence. A test is scoped in January against the application as it exists in January. The tester works within an agreed boundary and produces an accurate report. In March a migration happens and an old service is left running because nothing pointed at it any more and nobody had a reason to look. In April a mobile feature ships that calls three new endpoints. In June a third party integration is added under deadline pressure.
By the time the next test is scoped, none of those three changes were in the previous scope, all three have been live for months, and at least one of them is the sort of thing that ends up in a breach notification. The report was never wrong. It described a product that stopped existing shortly after it was written.
This is the pattern I have seen most often in real incidents, and it is almost never a sophisticated attack against a hardened target. It is an artefact of change. Something was left behind, something new was exposed, something that used to require a credential stopped requiring one during a refactor. The finding is usually mundane. What made it consequential was the length of time it sat there unexamined.
The bottleneck is not the testing
Here is the part I find most interesting, because it points at where the problem is actually solvable.
Ask why testing runs in quarters and the answer people reach for is cost, or the scarcity of skilled testers. Both are real. But when I look at where the time in an engagement actually goes, a substantial proportion of it is not testing. It is setup.
Getting access to the environment. Getting credentials that work, for accounts with the right roles. Getting the client's identity provider to cooperate with a testing tool. Working out how the mobile application authenticates and getting to a state where its traffic can be observed. Establishing what is in scope, what is shared infrastructure, and what will page someone at three in the morning if it falls over.
None of that is offensive work. All of it is necessary before offensive work can start, and it is the reason an engagement is a project rather than a task. It is also why testing more often does not simply cost proportionally more. Each new engagement pays the setup cost again.
That reframes the problem. If the expensive part is the setup rather than the testing, then the thing worth building is not a faster tester. It is a system where the setup is done once and the testing runs continuously against it. That is a different engineering problem, and a more tractable one.
The stakes are moving too
I want to be careful here, because the argument that software is becoming more consequential is easy to make badly. It usually arrives as a list of headlines and a gesture at the future.
The specific version worth making is narrower. Categories of software that used to fail inconveniently are becoming categories that fail dangerously, and the testing cadence they inherited was designed for the inconvenient version.
Public infrastructure is increasingly sensor driven, connected and centrally managed, which means a city's operational systems now have an attack surface in the same sense a web application does. Vehicles are moving from software assisted to software driven, and a fault in a driving system is not a data problem. Telecommunications networks are software defined, and state linked actors have demonstrated an interest in the traffic they carry.
The point is not that any of these will be attacked tomorrow. It is that a yearly testing cadence in a system where failure is a safety event is a different proposition from the same cadence on an internal reporting tool, and most of these industries adopted their security practices when they were closer to the second than the first.
What I am not arguing
Continuous testing does not make scheduled engagements pointless. There is a category of work, particularly on a new or unusually complex target, where an experienced engineer spending two focused weeks finds things that no continuous process is going to surface. Deep manual work against a hard target remains valuable and I do not expect that to change soon.
I am also not arguing that testing frequency is the only variable. An organisation that tests weekly and remediates nothing is worse off than one that tests annually and fixes what it finds. Cadence matters because it shortens exposure windows, and that only helps if something happens at the other end.
And the three clocks framing is a simplification. Plenty of organisations have continuous scanning in place already, and the honest description of their position is that they have partial coverage running continuously and full coverage running rarely. The gap I am describing is in the middle of that, not at either end.
Where Deus Rex sits
We built Deus Rex around the setup problem, because that is the constraint that keeps testing infrequent.
The platform establishes access to an application once, across web, iOS and Android, and then tests on your terms; ad-hoc, on a schedule, or continuously integrated into your release pipeline. Findings are confirmed by exploitation rather than inferred, and the fix arrives as a pull request your team reviews and merges on its own terms.
The methodology underneath it is not new. Deus Rex is built by Cyrex, which has spent twelve years doing this work by hand for studios and enterprises where a live failure is a serious event. What is new is running it on the release clock instead of the procurement clock.
Written by
Tim De Wachter
CTO Deus Rex
