I keep seeing the same reflex everywhere: “Let’s run a scan.” Scanning is useful. I’m all for it. But a scan tells you what is exposed today. It doesn’t tell you why it was exposed in the first place, or whether it will be exposed again next week.
What the Scan Doesn’t See
The French refrigeration controllers weren’t the result of some sophisticated hack. According to the CERT-FR advisory, their management interfaces were accessible from the internet, running on hardware that had been unsupported for years and was often managed remotely by the installer. A factory reset didn’t help; the device was simply compromised again afterward. The root cause lay in the design of the entire chain: who manages what, through which route, and who checks that it is secure.
That’s what I mean by security by design. Not an extra layer bolted on afterward, but answers to a few fundamental questions before the system is deployed. What paths lead into the system? Who holds the keys? What happens if a key is leaked? And how do we know that the software running in production is the software we approved?
What We’re Seeing in Practice
This autumn, we examined the web API of a software platform we know, using two tools: a network scanner that looks for known vulnerabilities, and a reasoning model that analyzes the code and architecture. Since October, we’ve had access to Anthropic’s Mythos 5.1, a model suited to this kind of analysis and available only under specific conditions. Naturally, we only examine a client’s code with their written permission.
The network scanner quickly and effectively identifies both major and minor vulnerabilities. The model then takes the analysis further: can a vulnerability actually be exploited, and how much damage could it cause? Can it be mitigated quickly? How did the vulnerabilities arise, and is there a common pattern?
Together, the two tools provide a level of insight that neither can deliver on its own.
The lesson: the scanner checks the result; the model and the architect examine the decisions behind it. You need both, in that order.
Why This Matters Now
The Dutch Cybersecurity Act extends the duty of care beyond the organization itself, explicitly covering the supply chain, secure maintenance, and the assessment of whether security measures are effective. Water authorities and airports are covered; universities are next in line for designation. For anyone supplying software or installations to these organizations, that means one thing: customers will want evidence of what is running, what has changed, and whether it has been tested.
“We ran a scan” is only half an answer.
The Questions We Ask
- Access: What paths into the system exist, including those used by suppliers, and who can list them without having to look them up?
- Keys: How many secrets are stored in configuration files, and how long does a leaked key remain usable? An hour, a day, or forever?
- Lifecycle: Which components are no longer supported by their manufacturers, and what is the plan for each of them?
- Change management: How do we know that the version running in production is the version that was approved?
- Evidence: If a customer asks tomorrow for an overview of security measures and tests, how many days would it take us to provide it?
- Recovery: What happens if a controller or service is compromised, and have we ever rehearsed our response?
A scan tells you what is exposed today. The design determines whether it will be exposed again tomorrow.
Start with the Design
Wondering whether your architecture can stand up to the questions raised by the Dutch Cybersecurity Act? Or simply curious about how a reasoning model examines your code?
I’d be happy to walk through it with you, using your own system as an example. Over a cup of coffee, of course.
