Patch Speed

Software always contains bugs. Some of them are dangerous because outsiders can use them to break into a system. Such bugs are called security vulnerabilities. The vendor fixes them with a small corrective update called a patch. Patch speed is the time that passes between a vulnerability becoming known and the finished patch being fully installed. It is measured in days, sometimes in hours, and in bad cases in months.

The open window for attackers

As soon as a vulnerability is publicly known, criminals know about it too. Security researchers usually publish their findings along with a technical description. Attackers read the same reports and build ready-made attack tools from them. For known vulnerabilities, often only a few days pass between publication and the first mass attack attempts.

During this span, a system is practically unprotected. The vulnerability is described, but the remedy has not yet been installed. Experts therefore speak of the vulnerability window. A fast patch speed keeps this window small, a slow one keeps it open for weeks.

For companies, this has now also become a matter of law and money. Regulators and insurers ask how long a business needs for critical updates. Anyone who, after a breach, has to prove that a patch had been available for eight weeks has a problem. Patch speed is thus one of the few security metrics that can be easily expressed in numbers.

From bug report to installed update

The process has two halves, and both cost time. First, it is the vendor’s turn: they must reproduce the reported bug, find the cause, program a fix, and test it. A poorly tested patch can crash programs and then does more damage than the vulnerability itself. Large vendors therefore often bundle their fixes into fixed release dates, for example Microsoft on the second Tuesday of every month.

The second half lies with the customer. A patch sitting on a vendor’s server protects no one. It must be distributed and installed, and many systems have to be restarted for that. On a phone this takes minutes. For a factory control system or a hospital system, the restart is planned weeks in advance, because downtime during operation would be costly or dangerous.

A common misconception is to equate patch speed with the release of the update. It is usually measured up to the point of installation. A company with 10,000 computers is only considered patched once nearly all of them have the update. The one forgotten server in the basement is exactly the one through which the attack later runs.

Where the figure shows up in the news

On one’s own phone, patch speed appears as a date in the menu. Android devices show a so-called security patch level under the system information. If it is a year old, the device is missing all the fixes from that year. How long a manufacturer even continues to deliver such updates has meanwhile become a selling point and is partly mandated in the EU.

In business news, the term comes up after major waves of attacks. A recurring pattern: a vulnerability in widely used enterprise software becomes known, a patch is released, and months later thousands of unpatched systems are still being hijacked. Authorities such as Germany’s BSI then publish warnings with concrete deadlines.

In AI systems, the topic takes on a new twist. Many companies assemble their applications from third-party software components that they can barely keep track of. If one of these components contains a vulnerability, one first has to find out everywhere it has been built in. This is precisely where fast patching most often fails in practice.