Last Week on My Mac: Why are security updates still so unreliable?

Apple’s software updates are a cornerstone in the security of our Macs, and updates it releases for the security tools built into macOS are a crucial part of that. When Apple’s security researchers discover a change in threat, it’s essential that all Mac users benefit from the response to that threat as quickly as possible.

With plenty of us now, both at home and in smaller workgroups, using several if not many Apple products, the Content Caching service provided by macOS is our means of getting timely security updates. These servers also reduce the burden on Apple’s software update servers, as they allow multiple Macs to be updated from a single download from Apple.

If only they had worked reliably over the last eight months.

Problems started here on 9 June 2022. My Content Caching server running in Monterey suddenly started delivering XProtect updates to client Macs that failed to install correctly. After flushing its caches, I discovered the only reliable way to install those updates was to disable the Content Caching server altogether, so that each of my Macs had to download the update direct from Apple.

I filed a Feedback report with Apple, complete with a sysdiagnose from a client and one from the server. Weeks passed, and every time there was a new security update, I had to disable my Content Caching service to update successfully, until 4 August, when the update installed through the server for the first time since May. I closed the Feedback, presuming that whatever was the cause of this had been fixed.

The next security update came two weeks later, on 18 August, and behaviour had reverted, forcing me to disable the server once again. I filed a fresh Feedback (FB11333839), with another matched pair of sysdiagnose reports.

Since then, the Content Caching server has worked on another two occasions, on 13 October 2022 and 19 January 2023. Otherwise, each time there’s been a new security update, I’ve gone through the same routine: try first with the server running, watch the update fail to install, disable the server, try installing the update again, this time successfully. This has persisted through upgrading the server and its clients from Monterey to Ventura.

Of the 16 security software updates since the start of June last year, only three have worked as advertised, and the other 13 have failed identically. That’s less than a 20% success rate.

I know from the comments of others here that I’m not alone, and that several of you have disabled your Content Caching servers as a result of these persistent problems. Of course we could be the only ones affected, but given the lack of controls over or insight into the service, there isn’t anything we can do to work around this, other than by disabling the service whenever we want to update, which is deeply contradictory. Isn’t the purpose of the Content Caching server to make updates quicker and easier?

I’ve now reached the stage where I realise little or nothing is going to happen, at least not in Ventura. Maybe macOS 14 will bring an undocumented new feature, “A Content Caching server that works”?

In the meantime, I ask one favour of Apple. If you can’t fix this problem, could you at least give us a workaround in an additional option to the softwareupdate command tool, to download and install software updates direct from Apple rather than through the Content Caching server? I know this shouldn’t be too difficult, as it’s already an internal option for macOS, which is able to elect for downloads from Apple to be made direct, rather than through a local server.

If your Macs rely on a local Content Caching server for their updates, this might be a good time to check that they are being installed correctly on your Macs. I maintain lists of the current versions of security data files for Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page. Which is more than Apple does.