Security Patches Without a Phone Home: Getting Fixes Across an Air Gap

Illustration for: Security Patches Without a Phone Home: Getting Fixes Across an Air Gap

The fourth goal of CISA’s Secure by Design pledge asks a signer to “demonstrate actions taken to measurably increase the installation of security patches by customers”. Its first suggested approach is providing automatic installation of patches and enabling it by default.

We cannot do that, and we are not going to. RaptorGRC runs inside your network, opens no outbound connections out of the box, and does not phone home. A product that could silently update itself would need a channel to us, and that channel is the thing our customers chose this product to avoid.

So goal four, for us, is not about automating the install. It is about removing every other obstacle between a fix existing and you knowing it exists.

How a release is built

Versions follow a calendar scheme, in the form of year, quarter and a hotfix counter, held in one place in the build so that the number in the container matches the number in the notes.

Release notes are maintained as a file in the repository rather than assembled from commit messages at the last minute, and they are written for an operator rather than for a developer.

The pipeline builds the container image from a base image pinned by digest, then assembles a release bundle. The bundle contains the image as a tarball, software bills of materials in both CycloneDX and SPDX form, the vulnerability scan report, a signature, and build provenance. It is designed to be carried onto approved media and walked into a facility, because that is how our customers actually take delivery of software.

The signature deliberately avoids uploading to a public transparency log. Verification is done offline against a public key committed to the repository, because a verification step that requires internet access is useless to the people this product is for.

How a release reaches you

The portal holds it

Releases are published in the customer portal. Each one shows its version, its size, its release notes and a SHA-256 for the download, and the same is true of each attached artefact. You can verify what you carried across the boundary against the value we published before you install it.

An email goes out on upload

When a new release is uploaded, the portal emails the release notes to the contacts of every organisation holding an active, activated licence. It goes once per address, so a person listed against two organisations does not receive it twice.

That is the whole mechanism, and it is the honest answer to the goal. Patching an offline product is a pull, not a push. The announcement tells you a fix exists. The portal gives you a verified artefact. You decide when it crosses your boundary.

What the announcement does not do

The announcement is best effort. A failure to send is logged and never blocks the release upload, because a broken mailbox at one customer must not stop a security release reaching everyone else.

There is no retry queue. If our mail provider has a bad ten minutes, the message for the addresses in that window is gone, and the only record is a line in our log. There is no read receipt and no acknowledgement, so we cannot tell whether anybody opened it.

There is also no mechanism for a customer to say who should receive release announcements separately from who receives everything else. It goes to the organisation’s contacts, which is a blunt instrument. A security-notifications list would be better.

Only three releases are kept

The portal keeps the newest three releases. When a fourth is uploaded, the oldest row and its files are deleted.

There is a reasonable argument for that, which is that a downloads page offering eleven versions invites somebody to install the wrong one, and old builds accumulate known vulnerabilities that are then sitting on our own server. There is also a reasonable argument against it, which is that a customer on a long change-freeze can find the version they validated has disappeared from under them.

I think three is too few for a product deployed into environments where a change window is measured in months. It is stated here so that nobody is surprised by it.

There is no patch SLA, and the licence says so

I would rather write this plainly than leave a reader to find it in a document nobody reads.

RaptorGRC’s licence agreement provides support on a reasonable-endeavours basis and explicitly does not commit to response times, service levels or bug-fix timescales. There is no contractual patch window, and this article does not create one.

The only timed commitments we have made anywhere are in the vulnerability disclosure policy, which are an acknowledgement of a security report within three working days and a ninety-day coordinated disclosure window. Those are commitments about communication, not about fix delivery.

For a free product from a small company, that is a defensible position. For a customer building a supply-chain risk assessment, it is a finding, and it should appear in your assessment as one.

The argument for automatic updates, taken seriously

The case for auto-update is genuinely strong and I do not want to wave it away.

CISA maintains a catalogue of known exploited vulnerabilities precisely because flaws with fixes already available keep being exploited in the wild. Every hour of operator decision-making between a fix existing and a fix being installed is exposure. Products that update themselves close that window without depending on an operator noticing an email. CISA puts automatic installation first in its list for exactly that reason, and the browser and operating-system vendors have proved the model works at scale.

The counter is not that auto-update is wrong. It is that in this product the cost is a permanent outbound channel from a system that holds a complete map of an organisation’s control weaknesses, its incidents and its supplier dependencies. That channel is an attack path, and it is one that a compromise of us would turn into a compromise of every customer at once. The SolarWinds Orion and 3CX compromises are what that failure mode looks like, in both cases through a legitimate, signed update reaching customers.

Given the data RaptorGRC holds, I think the trade is clear, and the customers who chose an offline GRC platform have already made it. But the honest framing is that we have accepted a slower patch cycle in exchange for removing a class of supply-chain risk, not that we found a way to have both.

What we still owe

The obvious missing piece is what CISA calls a seat belt chime. A RaptorGRC deployment does not know that a newer version exists, so it cannot tell an administrator on the dashboard that they are three releases behind with two security fixes outstanding.

That is buildable without breaking the offline promise. The version metadata could travel the same route the licence does, by an operator pasting a signed statement, or the release bundle could carry a manifest the product reads at import. Both would let the product nag its own administrator rather than relying on an email reaching a mailbox that may no longer be monitored.

Neither is built. It is the change I would prioritise on this goal.

Why there are no adoption statistics

CISA suggests demonstrating progress here by publishing the percentage of users on each version over time.

We do not know. There is no telemetry, so we cannot see which version any deployment is running. The one signal that ever reaches us is the product version inside an offline activation request, and activation happens once, at the beginning, so it tells us what a customer started on and never what they are on now.

That is the cost of the design, and it is the same cost described in the first article in this series. We cannot report your patch adoption because we cannot see it, and we are not going to build the thing that would let us.

The full tracker is at /secure-by-design. What does and does not leave your network is set out at /transparency.