As the threat landscape and strategies change, different parts of macOS security have been more actively developed. When Java and Flash vulnerabilities were dominant, XProtect’s metadata became vital for blocking older unpatched versions. Then in 2020, Apple grew XProtect’s Yara signatures to detect more malicious software, in 27 updates released that year. That campaign had finished by 2023, when it was only updated once each month, and all eyes were on the youthful XProtect Remediator maturing rapidly in its 18 updates. This article outlines what changed in macOS security protection during 2024, and how Apple has shifted emphasis back to XProtect, together with the importance of CDHashes and notarization.

XProtect

This has definitely been the year of XProtect, which performs on-demand checks of code that’s about to be launched, using a set of Yara rules to detect known malware. Our Macs started 2024 with version 2177, and after a record total of 29 updates for all macOS and a sudden change in version numbering, by the year’s end that has reached 5284. Even more impressive is the growth of XProtect’s Yara detection rules: at the start of 2024 there were about 195 rules taking 167 KB of text; as we pass into 2025, there are now about 328 rules in 921 KB of text. That’s 170% of the number of rules, and over five times the size.

macOS Sequoia has also brought the most substantial change to XProtect itself, in the introduction of a new medium for delivery of updates to its data, suggesting that XProtect is being forked. When macOS 15.0 was first released, XProtect could receive updates via either the old mechanism of Software Update, or through a new connection to iCloud using CloudKit. After a transition period, updates switched to iCloud only with effect from macOS 15.2.

Apple released two test updates for Sequoia only during September, one of which brought a huge increase in Yara rules in a file of 1.2 MB in size. This suggests that Sequoia’s XProtect is likely to see more frequent and larger updates now that this new mechanism has been tried and tested. How that will run alongside updates for older macOS has yet to be demonstrated, and none of this has been documented by Apple.

XProtect Remediator

This runs daily or more frequent background scans looking for the presence of malicious software and remediating it whenever it can. Although most of its scans are brief, those for Adload can now take several seconds or longer. Our Macs started the year with version 122 containing 22 scanning modules. Since then there have been 18 updates, bringing new modules for Bundlore (also the subject of a campaign in XProtect), and the newer Crapyrator and Dolittle (covered by extensive rules in XProtect), while RedPine has been dropped. We end the year with version 149.

For much of the year updates have been released every two weeks, but have reduced to one update each month since the summer. It’s thought that XProtect Remediator also uses XProtect’s Yara rules for detection purposes, so it should have benefitted from all those updates as well.

XProtect Behavioural and Bastion

The most recent of the XProtect trio, this watches for code that breaks its Bastion rules of behaviour by accessing files in specific sensitive locations, and similar. Apple states in its Platform Security Guide that this isn’t used to block apps or for local detection: “In addition, XProtect contains an advanced engine to detect unknown malware based on behavioral analysis. Information about malware detected by this engine, including what software was ultimately responsible for downloading it, is used to improve XProtect signatures and macOS security.”

Its Bastion rules have grown from 7 to 12, adding watched locations in ~/Library and /Users/Shared and more. Apple doesn’t provide any information as to how useful this intelligence is proving.

Gatekeeper

As all those using macOS Sequoia will have discovered by now, it brings a major change to way that Gatekeeper’s checks for notarization can be bypassed. In recent versions of macOS, this has been simple to accomplish using the Finder’s Open command, so simple that malware developers commonly coach the user through this to ensure their unsigned code is run without the defences of macOS. The new procedure requires permission to be granted explicitly in Privacy & Security settings.

This has proved controversial, with some who distribute code that isn’t notarized complaining that it’s getting in the way of users running perfectly benign software. However, it’s an important part of the transition to reliance on CDHashes known to Apple. It has already posed a problem to those distributing malicious code, for which no simple workaround has yet emerged. This has also led to a few legitimate apps being blocked, typically when they have been updated in place without fully updating their CDHashes and notarization ticket.

MRT

The old macOS Malware Removal Tool MRT has been superseded in Catalina and later by a scanner module in XProtect Remediator. MRT was last updated nearly three years ago, with version 1.93 from 29 April 2022 being the last. It hasn’t been entirely forgotten, though, and may still be installed on the latest Apple silicon Macs.

Threat

Fuller accounts of changes in the threat landscape are given by independent security researchers. Moonlock’s was published earlier this month, and I’d expect to see reviews from Patrick Wardle at the Objective-See Foundation and others in the coming days.

The year has seen continuing increase in the number and variety of malicious products for macOS. It’s surprising how many old names like Adload and Bundlore are apparently still thriving, and the emphasis remains on stealers. Recent directed attacks have demonstrated increasing ingenuity and technical skills, and at least one managed to sneak its way through screening by Apple and became notarized, although that has since been revoked.

As ever, threats are most immediate for those who engage in high-risk activities, including downloading cracked commercial products, and dealing in cryptocurrency.

The year ahead

Given that there’s no sign yet that Apple has driven away those who develop and deploy malware, 2025 isn’t likely to be any easier. Most malware has yet to respond to the change brought in bypassing notarization requirements. While there are bound to be more attempts to get malware notarized by Apple, the chances of a notarized app being malicious are likely to remain as close to zero as possible. Greatest risks will continue for those who run unnotarized code from uncontrolled sources.

Apple has put a lot of effort into the changes it has made in XProtect, and will expect to see results in the coming months.

I wonder whether we’ll look back at 2024 as the year that Apple Intelligence came to our Macs and devices?

While there are plenty of nay-sayers, and those who still accuse Apple of falling behind, there can be few who aren’t aware of what’s available to those who have bought a recent Mac or one of the higher-end iPhones or iPads. Since Apple’s attempt to hijack the established abbreviation AI at WWDC last summer, we have heard little else. There can have been few minor updates that were sold as heavily as the autumn’s x.1 and x.2 releases for their lavishly preannounced new features.

We’ve been beta-testing some of those features for as long as we’re normally allowed for a whole major release of macOS. Over that period, the number of users who have switched to English (US) as their primary language must have been substantial. It’s the first time I have kept one of my Macs running beta-releases long after the annual macOS upgrade, and I only reverted when 15.2 was released with AI support for English (UK).

Although these AI features have their uses, and for many should prove quietly revolutionary, I’m not convinced that they transform our Macs or devices into anything even remotely intelligent, and a far cry from the great thinkers in Raphael’s masterpiece The School of Athens. The central figures here are Plato (left) and Aristotle (right). Seen further to the left in profile is Socrates, and below him is Pythagoras writing in a book while a boy holds in front of him a small blackboard showing the theory of harmony.

Contrast that hullabaloo about AI with Apple’s complete silence on security, specifically the changes brought in its front-line malware detection feature XProtect in macOS Sequoia, since its release on 16 September. Prior to that, XProtect’s data bundle, including its Yara file of detection signatures for malicious software, had been maintained by the general macOS update service through softwareupdated. The diagram below outlines this long-established process.

When Sequoia 15.0 was released, that changed to what has turned out to be an intermediate invoking both the old mechanism and the new.

For the first couple of weeks of that, XProtect updates were chaotic:

• 13 Sep (approx) Software Update Service stopped providing regular XProtect updates
• 13 Sep (approx) XProtect version 5273 available from Software Update Service for Sequoia only
• 16 Sep macOS 15.0 released, with version 5273 available from Software Update Service for Sequoia only; upgraded Macs updated to 5273 by copying from secondary to primary locations; 5273 not provided from iCloud, where 5272 remained the current version
• 18 Sep Software Update Service resumed delivery of 5272 to Sonoma and earlier
• 18 Sep Software Update Service started delivery of 5274 to Sonoma and earlier; 5273 no longer available for Sequoia, with 5272 still available from iCloud
• 24 Sep Software Update Service delivered 5275 for Sequoia; no change to Sonoma and earlier, and 5272 still available from iCloud.

Then, just as we were getting the hang of it, Sequoia 15.2 excised the old mechanism, as we discovered last week when Apple released the first update to XProtect since 15.2.

Throughout all of this, Apple has remained completely silent. What’s even more surprising is that in the last few days, Apple has updated its definitive guide to security for Macs and all its devices. Although not all localised English translations have yet been synced with its US or Canadian English versions, the account of XProtect now has a published date of 19 December 2024, but doesn’t mention September’s changes.

There are those who insist that none of this is our concern, we should just let Apple do whatever it deems appropriate, and we shouldn’t even know what version of XProtect’s data is installed, as macOS takes care of all that for us. However, the security of my Mac is very much my business. If I were to unwittingly install malware that stole sensitive information, those are my banking details at risk, not Apple’s. Should I suffer financial loss as a result, would Apple provide unlimited compensation?

Hardly. Read sections 8 and 9 of Apple’s licence for macOS Sequoia, and the onus is clearly placed on the user. Just to emphasise this, further down that licence, in the Apple Pay & Wallet Terms and Conditions, is the express statement: “You are solely responsible for maintaining the security of your Mac Computer, Supported Devices, your Apple Account, your Touch ID information, the passcode(s) to your device(s), and any other authentication credentials used in connection with the Services (collectively, your “Credentials”).” The next time someone says that you should leave the security of your Mac to Apple, remind them of that.

Apple also encourages us to take an active part in our Mac’s security protection, and provides us with tools for doing so. The description given in man xprotect is a good example: “xprotect is used to interact with XProtect. It is useful for administrators or users who want to manually invoke XProtect functionality.”

Information about XProtect updates is exposed in the GUI, in System Information, where each update including those delivered by both old and new mechanisms is listed, together with its version number. That in itself is puzzling, as recent entries incomprehensibly duplicate older XProtectPlistConfigData entries with newer XProtectCloudKitUpdates.

So if AI doesn’t bring us the School of Athens, what has macOS Sequoia achieved so far? For this second image I turn to Lovis Corinth’s first major painting after his near-fatal stroke just before Christmas in 1911, an autobiographical portrait expressing his frustrations, in The Blinded Samson from 1912.

Please don’t breathe a word of this over on Apple Support Communities, though, where it seems your Mac’s security should be like mediaeval religion, a matter of blind faith and the suppression of knowledge. It’s high time for a Renaissance, much more Enlightenment, and a modicum of Intelligence.

Apple provides so many services for different parts of macOS that it’s hard to keep track of them. If you want to see a short summary, this article lists all service connections for enterprise network administrators, although it doesn’t detail which services use which servers, for example referring to “macOS updates” in many entries.

Many of you seem surprised to learn that Sequoia’s new XProtect updates come from iCloud, although Apple has been using iCloud for similar purposes for at least the last five years.

One good example that’s used every day on your Mac are the notarization checks sometimes run by Gatekeeper when macOS launches executable code, such as an app. In that case, com.apple.syspolicy processes the app’s notarization ticket
looking up ticket: <private>, 2, 1
by trying to fetch its record from iCloud using CloudKit. That’s followed by log entries indicating the network access required to connect with iCloud and check the ticket. Success is reported by com.apple.syspolicy in
CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
looking up ticket: <private>, 2, 0
and further lookups. I first reported those checks with iCloud back in Catalina, in 2019.

A simple way to illustrate the differences between this and using the general softwareupdated service is to compare what happens in the log when you ask if there are any updates available.

softwareupdate

When SilentKnight does this, it uses the only supported method, the softwareupdate tool, as used to keep XProtect up to date in all versions of macOS prior to Sequoia. That command hands over to the softwareupdated service to run the check. That in turn uses components of com.apple.SoftwareUpdateController to summarise the update state of that Mac, connect to the Software Update Server, check all the current versions and build numbers of macOS and its ancillaries, and arrive at a list of updates required. This is even more complex than it sounds, as com.apple.SoftwareUpdateController has to check key settings such as whether the root volume is sealed or not.

You can trace this through several thousand log entries, and after around 4.4 seconds and multiple network connections, softwareupdate finally informs SilentKnight that there are no updates available.

xprotect

Running the command
sudo xprotect check
in Sequoia is far simpler and quicker, as it checks for just one component’s updates through iCloud. The command connects to XProtectUpdateService in the XprotectFramework private framework in macOS, which in turn fires up CloudKit to connect to iCloud. That fetches a database record and returns the result to XProtectUpdateService, and so back to the xprotect tool as its result. Total time taken is 0.5 second.

As Apple’s intent in changing the management of XProtect and its data appears to be to facilitate more frequent and macOS-specific updates, iCloud is an ideal platform to host this on.

Pinniped with tusks

There is, though, one last thing: what is the walrus? As that might seem an odd question, read these two log entries encountered when browsing what happened with the xprotect check command:

12:08:00.919841 com.apple.cdp XPC Error while fetching walrus status: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process." UserInfo={NSDebugDescription=The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process.}
12:08:00.919845 com.apple.cloudkit CoreCDP reports that walrus is undetermined for the logged in account. Error: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=<private>}

The prospect of an undetermined walrus that can’t be fetched from inside my Mac might seem worrying

If your Mac is running macOS Sequoia version 15.2 and you keep an eye on its security data updates, you may have noticed that those have changed again. Perhaps the only way to make sense of what has happened is to understand how XProtect updates work in recent versions of macOS.

Before doing that, there are two important issues to make clear:

• Despite their names, XProtect and XProtect Remediator are different, and in Sequoia are updated using different mechanisms. XProtect is run on-demand when macOS is about to execute code, while XProtect Remediator runs scans for malware in the background about once a day. This article is only about how XProtect updates, as XProtect Remediator is still updated using the softwareupdate mechanism, and that hasn’t changed.
• Sequoia obtains XProtect updates through a connection to iCloud that is independent of whether your Mac is logged into your Apple Account in iCloud. So long as your Mac is connected to the internet and nothing blocks its iCloud connections, those updates will be available to it, regardless of whether it’s connected to your Apple Account or iCloud Drive. This is in common with other services that macOS relies on, such as making notarization checks on apps, and updating linguistics data and those used by AI.

macOS Sonoma and earlier

Like other security data updates including XProtect Remediator, XProtect is updated through Software Update, or the command tool softwareupdate, which is how SilentKnight obtains its updates too. Shortly after starting up, and at least daily after that, your Mac’s softwareupdated service contacts Apple’s software update servers and checks whether there are any updates available. If there are, they’ll be automatically downloaded and installed, provided that’s enabled in System Settings.

In this case, XProtect is installed in its traditional place, in /Library/Apple/System/Library/CoreServices as XProtect.bundle.

mcOS Sequoia 15.0-15.1.1

For this brief period, XProtect updates have been available using either of two methods.

The traditional method using Software Update or softwareupdate continues to install the XProtect bundle in its old location, where it could still be used, but the XProtect service in Sequoia expects to find it in a different location, in /private/var/protected/xprotect, where it’s still known as XProtect.bundle.

The new method installs the XProtect bundle directly into its new location, and doesn’t obtain it using Software Update or softwareupdated, but an undocumented service that connects to iCloud instead. That appears to activate at least once a day, independent of softwareupdated, and silently checks for XProtect updates in iCloud. When it finds one, that’s installed directly to /private/var/protected/xprotect but not the traditional location in /Library/Apple/System/Library/CoreServices. It’s therefore perfectly possible for the two XProtects to get out of sync, although the only one that Sequoia uses is that stored in the new location.

Sequoia also introduces a new command tool xprotect to help manage these new updates. If you run
sudo xprotect update
and the version of the XProtect bundle in the traditional location is greater than that in the new location, then the newer version will be copied to the new location to install it there as an update, instead of having to wait for the update through the new iCloud mechanism. This also provides redundancy, but relies on the two sources providing identical updates.

To add a final twist of confusion, if xprotect copies the XProtect bundle from the traditional to the new location, it does so by copying its contents, so its version number changes but the bundle itself retains its previous date of creation and modification, which can prove thoroughly confusing. The lesson here is to check the bundle by its version number, not by its dates.

macOS Sequoia 15.2 and later

In the latest release of Sequoia, the traditional method of updating XProtect is no longer used. If softwareupdate were to download and install an update, then it will only end up in the traditional location, and xprotect update can’t use that to update the new location.

In normal use, this means that the user can’t update XProtect until that new version is made available from iCloud. This ensures that the only versions provided to Macs running 15.2 and later are those intended to be used in Sequoia, but it also means that any delay in providing those via iCloud will leave Macs without the latest update.

Apple has modified the xprotect command to provide one let-out, though: use
sudo xprotect update --prerelease
and it “will attempt to use a prerelease update, if available.” Note that still can’t use a traditional XProtect update installed in the traditional location, and still has to be able to obtain the update from iCloud, but it might work when xprotect check and xprotect update can’t offer a new update yet. Note that Apple describes that early-bird version as prerelease, and it shouldn’t therefore be used as if it’s a regular release, and only for good reasons.

SilentKnight

Because of these changes, as of Sequoia 15.2, SilentKnight is no longer able to provide any assistance in updating XProtect, and its next version 3.0 will also be unable to do anything more useful than inform you that your current version of XProtect is up to date, or out of date. If it is out of date, then it’s up to you what you decide to do about it. In most cases, that should be to leave well alone and let macOS handle the update as it’s intended to.

Because time of release of XProtect updates through softwareupdate and iCloud differ, and vary around the world, availability from one source is no guarantee that the other will also be offering that update. For example, on 17 December, the softwareupdate version became available by about 1830 GMT. A prerelease version for 15.2 was available several hours before that, but the regular release wasn’t available from iCloud until early the following day. If Apple is intending to fork XProtect data for 15.x from those for older versions of macOS, the two update services will be offering quite different bundles anyway, as we experienced briefly in the early days of Sequoia.

Although I do periodically poll traditional softwareupdate servers for new updates, repeatedly doing so for iCloud updates doesn’t appear a good way to proceed, and could in any case be misleading. On the other hand I don’t think it’s intended that apps like SilentKnight should check for prerelease updates as a matter of course, and abuse of that option could lead to its removal. In other words, Apple wants full control over when your Mac can and will update to new versions of XProtect, presumably because Sequoia will be getting different updates in the future.

Summary

• If your Mac hasn’t been upgraded to Sequoia, XProtect updates continue as usual, and SilentKnight will continue to be able to find and install them as it has done in the past.
• If your Mac is running Sequoia 15.0 to 15.1.1, then it will continue to be offered XProtect updates both ways, and should continue to do so until you update it to 15.2.
• Macs running 15.2 and later now get XProtect updates differently. Neither you nor SilentKnight can alter that, unless you want to try obtaining prerelease updates through the xprotect command in Terminal. While SilentKnight and Skint will warn you when an XProtect update is expected, you should rely on macOS to handle those updates for you.

Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5284, and to XProtect Remediator for all macOS from Catalina onwards, to version 149. As usual, Apple doesn’t release information about what security issues these updates might add or change.

Yara definitions in this version of XProtect augment existing rules for dylibs in MACOS.ADLOAD, and add 2 new rules for MACOS.DOLITTLE, 1 for MACOS.PIRRIT, 5 for MACOS.BUNDLORE and 5 for MACOS.ADLOAD.

XProtect Remediator adds a new scanner module for Bundlore. There are no changes to Bastion rules for the behavioural version of XProtect (Ventura and later).

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-149 and XProtectPlistConfigData_10_15-5284.

For Sequoia 15.2 and later only: XProtect updates are no longer supplied through Software Update, softwareupdate, or SilentKnight. The only way that your Mac can obtain XProtect updates is through a connection to iCloud, which is supposed to happen automatically. If your Mac hasn’t yet been updated to version 5284, you can try using the Terminal command
sudo xprotect update --prerelease
(with a double hyphen not an m-dash)
That should download and install this update even though it hasn’t yet been generally released through iCloud.

For Sequoia 15.1.1 and earlier only: this update hasn’t yet appeared in iCloud, which may still return an XProtect version of 5283. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command
sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, 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.

[Updated blind-guessing the changes in 15.2, at 2030 GMT 17 December 2024.]

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5283. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds new rules for MACOS.DUBROBBER.F2 and MACOS.DUBROBBER.H2, and modifies that for MACOS.DUBROBBER.G.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5283.

For Sequoia only: this update has now been made available in iCloud, which should return an XProtect version of 5283. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command
sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, 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.

Updated 2242 GMT 19 November 2024.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5282. The last version released was 5279. As usual, Apple doesn’t release information about what security issues this update might add or change.

Relative to the last version released for all supported versions of macOS (5279), this version renames several existing rules, as MACOS.DUBROBBER.A to MACOS.DUBROBBER.E, and adds new rules for MACOS.DUBROBBER.F, MACOS.DUBROBBER.G and MACOS.DUBROBBER.H. It also adds a new rule for MACOS.TAILGATOR.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5282.

For Sequoia only: this update has already been made available in iCloud, which now returns an XProtect version of 5282. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command
sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, 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.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5279. As usual, Apple doesn’t release information about what security issues this update might add or change.

Relative to the last version released for all supported versions of macOS (5278), this version makes a small amendment to the detection rule for MACOS.PIRRIT.CHU.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5279.

For Sequoia only: there’s no sign of this update being made available in iCloud, which now returns an XProtect version of 5278. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command
sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, 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.

Modern Macs and macOS feature multiple layers of protection, most of which I have recently described. This article tries to assemble them into an overview to see how they all fit together, and protect your Mac from startup to shutdown. There are also many additional options in macOS and third-party products that can augment security, but I’ll here concentrate on making best use of those that come with a modern Mac and macOS. My recommendations are for the ‘standard’ user, as a starting point. If your needs differ, then you may of course choose to be different, but should always do so in the full knowledge of what you are doing and what its penalties are.

Startup

Whether your Mac has a T2 or Apple silicon chip, it’s designed to boot securely, which means that every stage of the boot process, from its Boot ROM to running the kernel and its extensions, is verified as being as Apple intends. To ensure that, your Mac should run at Full Security. For a T2 model, that means disabling its ability to boot from external disks; for an Apple silicon Mac, that means no third-party kernel extensions. If you need to run your Mac at reduced security, that should be an informed decision when there’s no good alternative.

A vital part of the Secure Boot process is the firmware loaded by the Boot ROM. That needs to be kept up to date by updating to the latest minor release of the major version of macOS. That doesn’t prevent your Mac from staying with an older supported version of macOS, as Apple supplies the same firmware updates for all three supported versions of macOS.

The System volume should be signed and sealed, as the SSV created by a macOS installer or updater. System Integrity Protection (SIP) should also be fully enabled, as without it many macOS security features work differently or not at all. Some need to disable specific SIP features, but again that should only be set when you’re fully aware of their effects and consequences, and should be the minimum needed for the purpose.

User Data

Having got the system up and running, the boot process moves to what is in mutable storage on the Mac’s Data volume. In the internal SSD of a modern Mac, that’s always encrypted, thanks to the Secure Enclave. Although that might appear sufficient, you should always turn FileVault on if your Mac starts up from its internal SSD. That ensures the encryption is protected by your password: an intruder then has to know your password before they can unlock the contents of its Data volume. They have limited attempts to guess that password before the Mac locks them out from making any further attempts. As FileVault comes free from any performance penalty, there’s no good reason for not using it.

Good security is even more important for Data volumes on external boot disks, where FileVault is just as important, but needs additional physical measures to ensure the external disk isn’t mislaid or stolen. That’s a more complex issue, for which the simplest solution is to start your Mac up from its internal SSD with the benefit from FileVault there.

Run Apps

With the user logged in successfully, and the Data volume fully accessible, the next stage to consider is running apps and other software. For this there’s another series of security layers.

When an app is launched or other code run, Gatekeeper will first check it, and in many circumstances run a check for malware using XProtect. Those shouldn’t be disabled, or macOS will still make those checks, but will simply ignore the results. XProtect looks for evidence that the code about to be run matches that of known malware. Although on its own this won’t detect unknown malware, it’s an effective screen against what’s most common. You also need to keep your Mac up to date with the latest security data updates, as those can change every week or two as new malware is identified and included.

Currently, no well-known malware has been notarized by Apple, and most isn’t even signed using a trusted developer certificate. Most therefore attempt to trick you into bypassing checks made by macOS. In Sonoma and earlier, the most common is to show you how to use the Finder’s Open command to bypass the requirement for notarization. As that has changed in Sequoia, those who develop malware have had to adapt, and some now try to trick you into dropping a malicious script into Terminal. Expect these to become more sophisticated and persuasive as more upgrade to Sequoia.

There are simple rules you can apply to avoid getting caught by these. The first time you run any new app supplied outside macOS or the App Store, drag the app to your Applications folder and double-click it in the Finder to open it. If it can’t be launched that way, don’t be tempted to use the Finder’s Open bypass, or (in Sequoia) to enable the app in Privacy & Security settings. Instead, ask its developer why it isn’t correctly notarized. Never use an unconventional method to launch an app: that’s a giveaway that it’s malicious and you shouldn’t go anywhere near it.

macOS now checks the hashes (CDHashes) of apps and code it doesn’t already recognise, for notarization and known malware. Those checks are run over a connection to iCloud that doesn’t need the user to be signed in. Don’t intentionally or inadvertently block those connections, for instance using a software firewall, as they’re in your interest.

Private Data

Traditional Unix permissions weren’t intended to protect your privacy. Now so many of us keep important or valuable secrets in our Home folders, privacy protection is essential. While you might trust an app to check through some files, you may not expect or want that app to be looking up details of your bank cards and accounts.

Privacy protection is centred on a system known as TCC (Transparency, Consent and Control), and its labyrinthine Privacy & Security settings. One of the most tedious but important routine tasks is to check through these every so often to ensure that nothing is getting access to what it shouldn’t.

No matter how conscientious we might be, there’s always the request for access that you don’t have time to read properly, or items that end up getting peculiar consents, like a text editor that has access to your Photos library or your Mac’s camera. Take the time to check through each category and disable those you don’t think are in your best interests. If you get through a lot of new apps, you might need to do this every week or two, but it needn’t be as frequent in normal use, and shouldn’t become an obsession.

There’s some dispute over whether it’s better to leave an app turned off in a category that you control, like Full Disk Access, or to remove it. I tend to disable rather than remove, with the intention of removal later, but seldom get round to that.

Downloaded Apps

While macOS continues checking apps in Gatekeeper and XProtect, there are a couple of other important protections you need to know about. Since macOS Catalina, every 24 hours or so macOS runs a paired set of scans by XProtect Remediator, looking for signs of known malware. If it finds any, it then attempts to remove, or remediate, that. The snag is that it does this in complete silence, so you don’t know whether it has run any scans, and you don’t know if it came across anything nasty, or removed it. I like to know about such things, and have written my own software that lets me find out, in SilentKnight, Skint and XProCheck. One day Apple might follow suit.

Some browsers like Safari have a potentially dangerous setting, in which they will automatically open files they consider to be safe, once they have been downloaded. This can include Zip archives that might not be as innocent as you expect. If you leave that behaviour set, you could discover your Downloads folder with all sorts of items in it. I much prefer to turn that off and handle those downloads myself. You’ll find this control in Safari’s General settings, where it’s called Open “safe” files after downloading.

Bad Links

Most of the protection so far relies more on features in your Mac and macOS, and less on your habits and behaviour. But it’s the user who is the kingpin in both security and privacy protection. Nowhere is this more important than dealing with links in web pages, emails, messages, and elsewhere. If you’re happy to click on a link without checking it carefully, you can so easily end up in the company of your attackers, inviting them into your Mac and all your personal data.

Unless it’s a trusted web page or contact, I always inspect each link before even considering whether to open it. For emails, my general rule is never, and I inspect the text source of each message to see what that really links to. It’s harder on the web, where even ads placed by Google can whisk your browser into an ambush. One invaluable aid here is Link Unshortener, from the App Store, which is a ridiculously cheap and simple way to understand just where those cryptic shortened links will take you. If you can’t convince yourself that a link is safe and wholesome, then don’t whatever you do click on it, just pass on in safety.

Summary

That has been a whirlwind tour through getting the best from macOS security, summarised in the following diagram. Fuller details about each of those topics are easy to find using the Search tool at the top right of this page. There’s plenty more to read, and for deeper technical information, try Apple’s Platform Security Guide.

Work and play safely!

Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 147. The previous version was 145.

Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac has not yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-147.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, 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.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5278. As usual, Apple doesn’t release information about what security issues this update might add or change.

Relative to the last version released for all supported versions of macOS (5277), this version adds three new definitions for MACOS.ADLOAD.I, MACOS.SOMA.G and MACOS.SOMA.H.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5278.

For Sequoia only: there’s no sign of this update being made available in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command
sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, 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.