At Nanitor, we run our infrastructure on Debian Linux, and we patch automatically. But here is the thing about automation: if nobody is watching, you cannot tell the difference between a system that is patching correctly and one that quietly stopped working months ago.

That is the gap Nanitor closes — for our customers, and for ourselves.

Nanitor is a CTEM platform (Continuous Threat Exposure Management). In plain terms: it continuously monitors all your IT assets against the latest known vulnerabilities and tells you, in real time, where your security gaps are. For our own infrastructure, we use Nanitor as an independent auditor. Our automated patcher does its job, and Nanitor independently verifies that the job actually happened. If the patcher fails silently — as automated systems sometimes do — Nanitor would flag the issue and keep flagging it until someone fixes it.

Last month, we had a real incident that put this to the test.

A 14-Point Drop in the Morning Report

Every morning, our security team receives a Slack message with a single headline: the Nanitor HealthScore for our infrastructure. Most days it hovers around 99%. On Thursday 21 May, it dropped to 85.87%.

Here is what four consecutive mornings looked like:

A 14-point drop on a small infrastructure estate points somewhere specific. No critical (P0) issues, which meant it was not an emergency — but it was clearly something to investigate.

What Caused the Dip

Inside Nanitor, tracing the drop took seconds. A new security release for bind9 — a networking software package that ships with most Linux systems — had landed across our Debian fleet. Our automated patching system had not yet applied it. Nanitor had already identified the gap the evening before any patch was touched, and was tracking six known vulnerabilities that the new release would close.

On one of our servers (a backup host running Debian 13), Nanitor recorded three missing patch events at 20:40 on 21 May:

None of our hosts run bind9 as a DNS server — these are client tools and shared libraries. The real-world risk in this specific case was relatively low. But that is exactly the assessment that must be made case by case, which is what the ISMS is for: Nanitor names the gap at the package level; the security team decides what that gap means given the role the host plays.

The Fix — Automatically

Our automated patching system (Debian's unattended-upgrades) runs on a schedule at around 06:20 each morning. By 06:40 on 22 May, Nanitor had recorded the patch events on the same host:

In the same scan, all six CVEs flipped from 'vulnerable' to 'no longer vulnerable' on that host — and the same pattern played out across the entire fleet as each server's scheduled patch run completed. Nobody touched a server. By Monday, the HealthScore was back at 99.21%.

Two Independent Systems — That Is the Point

Two systems handled this entire incident without human intervention. They are deliberately separate:

Neither system can certify itself. When the patcher and the auditor are independent, a disagreement between them is information — and that information is what tells you patching has quietly failed before the failure becomes an incident.

At customer sites, the most common pattern Nanitor catches is exactly this: the patcher is configured, the timer is running, the team believes the estate is current — and Nanitor reports otherwise. A misconfigured package source, a held package, a stale cache, an update unit that fails silently on one repository. The patcher was running. It was simply not applying what the team thought it was.

Why This Matters for Compliance (ISO 27001)

For security managers and compliance leads, this cycle maps directly to two ISO 27001 controls:

The HealthScore moving from 99.23% to 85.87% and back is not a paragraph in a risk register. It is the risk register, in motion — with timestamps, package versions, and a full audit trail.

For a board meeting or an external audit, the difference matters: 'Yes, we patch automatically' is a statement of intent. 'Here is the patch applied on this host, at this version, with these six CVEs cleared, on this date' is evidence.

When 24 Hours Is Not Fast Enough

The bind9 case resolved within 24 hours — well within acceptable limits for patches of this severity. But not all vulnerabilities are the same. If a CVE is actively being exploited in the wild, has a public proof-of-concept, or sits on an exposed network path, 24 hours is too slow.

In those cases, the escalation path is short. Nanitor identifies the exact hosts and package versions affected. A targeted deployment — an Ansible playbook, a manual apt upgrade, whatever fits the environment — closes the gap in minutes. The next Nanitor scan confirms the fix.

- name: Force-upgrade bind9 on the affected host
  hosts: backup-host
  become: yes
  tasks:
    - name: Upgrade bind9 packages to latest
      ansible.builtin.apt:
        name: [bind9-libs, bind9-host, bind9-dnsutils]
        state: latest
        update_cache: yes

The principle holds regardless of tooling: automation is the floor, not the ceiling. Build the floor first; keep the ceiling reachable.

Closing: The Boring Days Are the Win

Most mornings, the HealthScore sits at 99%. Nothing moves. The Slack message is a green tick. That is not a sign that nothing is happening — it is a sign the system is working.

The bind9 incident is not a failure story. It is a story about a gap that was detected, tracked, fixed automatically, and confirmed — all before any human had to make a decision. From detection to confirmed fix: approximately 24 hours. Fully automated, fully audited, and with a trail that survives external review.

Routine, audited, and predictable. That is the goal.