What has happened to XProtect in Sequoia?

As those running macOS 15 Sequoia are only too painfully aware, the way that XProtect’s data is updated has changed from that still used in older versions of macOS. Instead of accessing that data in XProtect.bundle in the path /Library/Apple/System/Library/CoreServices, in Sequoia the data used is in /private/var/protected/xprotect. While the old location can still be updated using Software Update, SilentKnight and softwareupdate, the only way to update the copy in the new location is using the xprotect command tool, which normally obtains its updates through a connection to iCloud.

Updating in Sequoia

Since Sequoia 15.0, there has been a way to update data in the new location from XProtect.bundle in the old location, using the command
sudo xprotect update
If that finds a newer version of the bundle in the old location, it installs its contents in the new location, so updating XProtect in Sequoia. At least, it did until the release of Sequoia 15.3 or 15.3.1.

When Apple released XProtect version 5288 on 26 February, it did so through both connections, and all versions of macOS were able to update promptly and successfully. That didn’t work with its successor 5289 on 4 March, though. Although the Software Update version was successfully updated in the old location to 5289, no iCloud update was made available, and sudo xprotect update proved unable to update from that to the new location.

This has left those running Sequoia 15.3.1 with version 5289 in the old location, but 5288 stuck in the new location. As Apple doesn’t tell us of these updates, nor of how XProtect is supposed to work in Sequoia or earlier, it’s impossible to tell whether this is intended, or an unintended failure.

Which rules does XProtect now use?

One potential explanation is that XProtect has returned to using its old location for the Yara rules, in /Library/Apple/System/Library/CoreServices/ XProtect.bundle/Contents/Resources/XProtect.yara. That’s fairly easy to check in the log, where it states the location of the rules it’s using to check an app for malware. The answer is
com.apple.xprotect Using XProtect rules location: /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara
that’s the new location for Sequoia, and hasn’t changed since 15.0.

How does macOS now update the correct rules?

By chance, a few minutes after I had started my Mac mini M4 Pro yesterday, I opened SilentKnight and discovered that XProtect had successfully been updated to version 5289, something it wouldn’t do the previous evening following its release. At that time:

XProtect in its old location had been updated to 5289 the previous evening.
SilentKnight now reported XProtect in its new location was 5289.
sudo xprotect check reported the version in iCloud was still 5288.
sudo xprotect update reported that it was already up to date.
xprotect version reported that 5289 had just been installed, about 2.5 minutes after starting up.

This was an ideal opportunity to discover how XProtect had updated this time, by looking in the log with LogUI. That showed the update had been dispatched as a background activity by DAS, with ID com.apple.security.syspolicy.xprotect-update. That’s a scheduled background activity run every 24 hours, and in this case appears to have been dispatched because of the recent boot.

That activity connects to XProtectUpdateService, which then runs the check and updates as necessary, connecting to iCloud using CloudKit. On this occasion it ‘found’ the 5289 update, although maybe in its old location rather than in iCloud, and updated XProtect’s data in its new location.

How to keep XProtect up to date

From this experience, bearing in mind that everything might change again in the future, my advice is to:

Check for updates as usual using SilentKnight, Software Update, or softwareupdate.
When offered an update by any of those, install it gratefully.
Run SilentKnight a few minutes later. If that update isn’t reflected in the version shown, restart your Mac and leave it for 10 minutes or so before checking again.
If it still doesn’t update correctly, check again in about 24 hours, by which time DAS should have dispatched com.apple.security.syspolicy.xprotect-update with any luck.

I suppose that’s progress?