Sometimes apps that should run fine seem to find problems where there shouldn’t be any, becoming slow to launch, unable to update, erratic, and easily crashed. One reason that can account for these is that the app has become stuck in translocation. This article explains how you can check that, and what you can do to solve it and restore the app’s normal function.
App translocation, or Gatekeeper Path Randomisation (GPR), is a security mechanism intended to disrupt malicious code that’s dependent on its immediate location, perhaps to access other code in plugins. When a new quarantined app is run from the same folder it came in, it’s copied to a random path that appears as a volume, typically hidden at something like /private/var/folders/x4/[random chars]/T/AppTranslocation/[UUID]/d/, and run from there. However, it’s only present there while it’s running, and the moment you quit the app that location is unmounted, and vanishes.
In theory, translocation shouldn’t affect an app, but when it occurs repeatedly, it’s likely to prevent it from updating itself, and have other adverse effects. When an app has been translocated once, unless something is done to prevent further translocation, it’s likely to suffer the same fate every time it’s run, so becoming stuck in translocation.
Testing
To determine whether an app is being run from translocation, you need to discover the path of its executable when it’s running. That’s simple to do using Activity Monitor:
Run the app from the Finder as normal.
In Activity Monitor’s CPU view, locate the app in the list of processes, and select it there.
Click on the ⓘ tool above to inspect the process.
Look at the Executable Path given there.
If the path starts with anything like /private/var/folders/x4/[random chars]/T/AppTranslocation/[UUID]/d/, then the app is being run in translocation.
If you’d prefer to perform this in Terminal instead, run the app, then enter the command ps xw | grep AppName
to see its executable path. This was suggested by Quinn “The Eskimo!” of Apple’s Developer Technical Support.
Fixing
App translocation occurs when all the following apply:
the app has a com.apple.quarantine extended attribute attached;
the app must be opened by Launch Services (normally the Finder) rather than a command shell;
the app hasn’t been individually moved in the Finder from the folder it was unarchived or downloaded to, wherever that was.
One common error that falls foul of those rules is when two or more apps are moved together from the Downloads folder into Applications, and another is to move an app inside the same folder it came in, into Applications.
Although you can strip the com.apple.quarantine extended attribute from the app, it’s simpler and better practice to:
Move the app (one at a time) to another folder in the same volume, then run it from that location.
Move the app back to the folder you want to keep it in, preferably in one of the standard Applications folders.
Run it again from there and confirm that it’s no longer translocated.
Future updates should then work fine, and the app should be spared any further translocation.
Summary
If an app isn’t working or updating properly, suspect it might be stuck in translocation.
Run the app and inspect its Executable Path in Activity Monitor to determine whether it’s being translocated.
If it is, move it elsewhere, run it, move it back, and check again.
Apple has just released its weekly update to XProtect, bringing it to version 5319. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds three new Yara rules. MACOS.SOMA.OCENA is yet another for the vast Soma/Amos family, and there are two for the far newer MACOS.ODYSSEY group, MACOS.ODYSSEY.SOCGO and MACOS.ODYSSEY.SEENA.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5319
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5319 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
Some who use SilentKnight for the first time discover that their Mac has been running for months with one of its security systems disabled. As macOS doesn’t have a dashboard to warn you of such dangerous settings, you may not notice until it’s too late. This article explains how to check those essential security settings on Macs with T2 or Apple silicon chips, and how to put them right. Intel Macs without T2 chips are different, and are covered in a previous version.
Secure Boot
Running your Mac in Full Security ensures it gets full protection from its Secure Boot technology. In an Apple silicon Mac this prevents it from loading third-party kernel extensions, and requires recent approved versions of macOS. Check this in System Information by selecting the Controller item in its Hardware section, or in SilentKnight.
This is controlled in Startup Security Utility, accessed from Recovery. Note that it only works with the paired Recovery system, the one you normally use; Apple silicon fallback Recovery doesn’t have this ability.
If you need to run kernel extensions or other software that can’t be loaded in Full Security, use Startup Security Utility to set the Mac to Reduced Security, and enable kexts. Avoid doing this if at all possible.
Settings are different for Intel Macs with T2 chips, where there are three levels of boot security, and the most common reason for reduction from Full Security is to enable that Mac to boot from external drives, something that Apple silicon Macs can do in Full Security.
System Integrity Protection (SIP)
Since El Capitan, macOS has protected all its system files, even down to bundled apps, using System Integrity Protection. This should make it impossible for malware or other software to change those protected files. SIP is also required for a wide range of other security protection, and should be fully enabled unless you have a compelling reason for disabling it partially or completely. In Apple silicon Macs, its status is reported in System Information’s Controller item, but Intel Macs instead give it in the Software section. It’s also checked by SilentKnight and Skint.
You can turn SIP off, something very occasionally needed to perform certain essential tasks. Doing so requires you to start up in Recovery mode, enter a command in Terminal there, and restart; Apple silicon Macs also need to have their boot security reduced in Startup Security Utility before SIP can be disabled.
To enable SIP, start up in Recovery mode, open Terminal, and type the following command: csrutil enable; reboot
Once that’s done your Mac will restart in normal mode, and you should confirm that SIP is reported as enabled.
If you ever do need to disable SIP, do yourself a favour and put a sticky note on your Mac’s display to remind you to turn it back on.
Gatekeeper/XProtect
Gatekeeper runs checks on apps when they’re opened, and those can include scans for known malicious software using XProtect. As part of your Mac’s frontline protection against malware, you should leave those enabled unless there’s a compelling reason to temporarily disable them. However, I don’t know of anywhere in the macOS GUI that informs you whether these checks are being performed, although they are reported by SilentKnight and Skint.
If it has been disabled, you may be able to enable it using the command spctl --enable
but chances are that you will instead need to invoke sudo spctl --global-enable
requiring you to authenticate using your admin password. Be careful with those commands: the hyphens before enable and global-enable aren’t long dashes, but two separate hyphens.
Signed System Volume (SSV)
When you install Big Sur or later, the vast majority of its system files are saved in its System volume. For your Mac to boot from this, it has to be turned into a snapshot, sealed using a tree of cryptographic hashes, and the master seal ‘signed’ by a hash, which is compared against that set by Apple. This signed system volume is extremely secure and thoroughly reliable. On Intel Macs, this is only reported in Disk Utility, but Apple silicon Macs list it in System Information as well. It’s also reported by SilentKnight and Skint.
The SSV should always be enabled. If it isn’t, you’ll need to re-install macOS.
FileVault
Intel Macs with T2 chips and Apple silicon Macs encrypt the whole of the Data volume on their internal SSD. By default, that uses an internally-generated key that’s used automatically when any user logs in. Although it provides good security in most situations, you’re far better off enabling FileVault, as that protects the encryption key with your password as well. This imposes no overhead on accessing encrypted data, and provides valuable protection for your data at no cost.
Check whether FileVault is enabled in Privacy & Security settings, where you can enable it if it’s not already turned on. SilentKnight checks it as well.
macOS and firmware
To ensure your Mac and its apps are best protected from malware, keep its firmware and macOS up to date. As those are updated together, Macs with T2 or Apple silicon chips that are running the most recent release of their major version of macOS will also be running the current firmware, which no longer needs to be checked separately. Check the version of macOS in the About This Mac command at the top of the Apple menu.
Apple lists current supported versions of macOS on its Security Releases page. Those, and versions of security data software, are also listed and detailed here on this page.
If your Mac is running an older release of macOS and its firmware, update them together using Software Update in General settings.
XProtect Remediator scans
This anti-malware scanner performs automatic background scans to detect and remove a wide range of malicious software. It’s normally scheduled to run at least once a day, when your Mac is awake but not busy, and supplied with mains power. You’re wise to check that its scans are being run correctly, and will probably want to know if it has detected and remediated any malware. SilentKnight and Skint run a quick check of its activity over the previous 36 hours, and XProCheck provides detailed reporting and analysis.
Over the last year or so, XProtect Remediator has been using a timer during its scans, and automatically cancelling them if a scan takes longer than allowed. On many Macs, most scans are terminated early, and that results in warnings from SilentKnight and Skint. If you’re concerned, check the reports in XProCheck, where you’ll see that plugin was cancelled with a status_code of 30, as is typical with the timer.
One of the longstanding oddities in macOS security has been scanning of a notarized app by XProtect before it can be launched. When apps are submitted to Apple for notarization, they’re scanned for malicious content using methods at least as effective as XProtect, and should any notarized software subsequently be identified as malicious, its notarization and signature are revoked immediately. That should make it impossible for any app with a valid notarization ticket to contain malware known to Apple.
One of the improvements believed to be incorporated into macOS 26 Tahoe is that validly notarized apps are no longer scanned by XProtect. When I examined this recently, I confirmed that was correct, although in practice this did little if anything to improve the launch times of apps. This article extends those observations to include app first run, when detection of malware is most critical.
When an app is run for the first time in a recent version of macOS, there are three options:
apps that aren’t quarantined, including those signed by Apple and almost all of those supplied through the App Store, normally don’t undergo additional checks;
quarantined apps that have been installed correctly undergo full first run checks, that have previously included XProtect scans;
quarantined apps being run from the immediate location they arrived in not only undergo full first run checks, but are additionally moved to be run from a random path in what’s commonly known as app translocation, or Gatekeeper Path Randomisation (GPR).
This article considers the second and third of those.
Quarantined first run, no translocation
In Sequoia 15.7 these apps undergo a “direct malware and dylib scan” using the XProtect data stored in its new location, in /var/protected/xprotect/XProtect.bundle. Because this is the first run, once Gatekeeper assessment is complete and confirms the app is safe to run, the user is presented with a dialog asking for their consent. Because of the inevitable delay in responding to that, two times can provide meaningful estimates of performance:
the time between the log entry reporting that Gatekeeper is performing a scan (“GK performScan”), and declaring the Gatekeeper scan complete (“GK scan complete”), in this case 5.35 seconds;
the time between the start of the XProtect scan (“Xprotect is performing a direct malware and dylib scan”) and the declaration of scan results (“GK Xprotect results”), here 5.33 seconds.
In Tahoe 26.0 no XProtect scan was attempted, as com.apple.xprotect entered in the log “Xprotect is skipping executable assessment”, and com.apple.syspolicy.exec confirmed “Skipping XProtect scan on seen software”. Despite that, the first of those times was nearly twice that required in Sequoia, at 10.29 seconds. The reason for this is unknown, but over that period the log contained about 13,000 entries reporting “SecKeyVerifySignature”.
As a result, a smaller and simpler app was used to test app translocation and its effects.
Quarantined first run, with app translocation
Instead of using Calibre as my test app here, I chose my own app Podofyllin, with its 442 KB executable and no dylibs or other complications. This was downloaded from here, unarchived automatically in the ~/Downloads folder and there run from the folder it came in, to ensure that it would be translocated.
Early in the launch sequence, com.apple.securityd writes a log entry indicating it has created the translocation directory “SecTranslocateCreateSecureDirectoryForURL”, following which diskarbitrationd replicates the app bundle to what appears as a different volume in the translocation path. Then a first run Gatekeeper assessment is performed, including an XProtect scan, checking the notarization ticket using CloudKit, a user approval dialogue, and setting up the app’s provenance tracking.
In Sequoia 15.7, the XProtect scan took 0.15 seconds, and the total period required for the Gatekeeper scan was 0.19 seconds.
In Tahoe 26.0, com.apple.syspolicy.exec logged “Skipping up front XProtect scan” and com.apple.syspolicy went straight on to perform the CloudKit lookup. This was confirmed later by com.apple.syspolicy.exec in “Skipping XProtect scan on seen software” just before reporting the Gatekeeper scan was complete. With no time required for the XProtect scan, the total used for the Gatekeeper scan was 0.16 seconds, 88% of that for Sequoia.
Stuck in translocation
Over the last couple of years it has become clear that some apps, even though they have been moved from their original download location, continue to undergo translocation whenever they’re run, and that can cause ongoing problems.
An app will be translocated if all the following apply:
the app has a com.apple.quarantine extended attribute attached;
the app must be opened by Launch Services (normally the Finder) rather than a command shell;
the app hasn’t been individually moved in the Finder from the folder it was unarchived or downloaded to, wherever that was.
Tests in recent macOS show that apps won’t be translocated if:
they have no com.apple.quarantine extended attribute, or it has been removed;
they have been moved individually in the Finder so they’re now enclosed in a different folder.
The following will normally result in the app being run in translocation:
opening the app in the folder that it first arrived in, even if that folder has been moved elsewhere, such as into an Applications folder;
moving the app at the same time as other apps, even if they’re all put into an Applications folder. Group or simultaneous moves in the Finder aren’t counted as a move that will stop future translocation;
running the app again without moving it from a location from which it has already been translocated. Until the app is moved from that location, it’s likely to be repeatedly translocated every time that it’s run.
You can readily check whether an app is being run in translocation by starting the app and either:
inspecting that app in Activity Monitor, by selecting it in the CPU view and clicking on the ⓘ tool,
running ps xw | grep AppName in Terminal.
If the path shown for the app is something absurdly long like /private/var/folders/x4/[random chars]/T/AppTranslocation/[UUID]/d/, then it has been translocated.
If an app that appears to have been correctly installed is still being translocated, move it individually (one app at a time) from the folder it’s currently in to a different folder, run it from there, close the app, and move it back to where you want to keep it.
Conclusions
macOS 26.0 Tahoe skips reported XProtect malware scans when a notarized app is run for the first time in quarantine, even when it has been translocated.
Despite that, first run checks in Tahoe can still take significantly longer than in subsequent runs, although the reason for that isn’t clear from the log.
If an app doesn’t appear to run properly, check whether it’s stuck in translocation. If so, free it as explained above.
Apple has released its weekly update to XProtect, bringing it to version 5318. As usual, it doesn’t release information about what security issues this update might add or change.
This version makes several changes to the Yara definition for MACOS.COMPLIANTPIRATE.DEFU, but doesn’t add any new detection rules.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5318
Sequoia and Tahoe systems only
This update has now been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5318 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
However, if the regular update has been installed in the old location, XProtect is likely to update its new location from that. There’s nothing you can do to force that, but it may well explain why your Mac seems to have updated itself.
Apple has released its weekly update to XProtect, bringing it to version 5317. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds five new detection signatures to its Yara file. These include another newcomer with four signatures, MACOS.DAILYDUMPLING, and MACOS.SOMA.SEEND to add to the large Amos/Soma family.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5317
I apologise for the late announcement of this update, which seems to have been released after 22:00 GMT on 30 September, but was still incomplete here through the whole of today, 1 October.
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5317 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
One seemingly widespread complaint about recent versions of macOS has been slow launch times of notarized apps even after they have cleared quarantine in their first run. Debate on the cause of this was vigorous in April and May, but was overtaken by Apple’s announcement of macOS 26 Tahoe. I therefore postponed further work on app launch and Gatekeeper until after Tahoe’s release.
This proved worthwhile, as soon after the first beta-release, it was suggested that Tahoe would accelerate the first launch of notarized apps by exempting them from a malware scan, although I have been unable to confirm that from Apple’s published information. That would make good sense: if an app’s CDHashes verify and match those of its notarization ticket, and no known malware was found when it was notarized, then it’s not plausible for it to contain malicious content since notarization was performed. This article considers what has changed in Gatekeeper in macOS 26.0.
Although Apple hasn’t yet updated it for macOS 26, its Platform Security Guide explains what Gatekeeper does in macOS Sequoia. For an app, plug-in or an installer package downloaded from outside the App Store and opened on a Mac, Gatekeeper verifies the software:
is from an identified developer, in signature checks;
is notarised by Apple to be free of known malicious content, in notarization ticket checks;
hasn’t been altered, in CDHash verification;
doesn’t contain known malicious content the first time it’s opened, regardless of how it arrived on the Mac, in a first run XProtect scan.
To assess this, I have used Calibre version 8.11.0 installed in a macOS virtual machine running on a Mac mini M4 Pro. Calibre is a large app at just over 1 GB with many components to be checked. This version has 82 items in its Frameworks folder, 20 executables in its MacOS folder, and 25 dylibs in its Plugins folder, totalling 113 dylibs and others that need to be checked.
Two VMs were prepared, one with macOS 15.7 Sequoia installed, the other with macOS 26.0 Tahoe. Both were run with 5 CPU cores, 16 GB memory, 100 GB disk, and bridged networking.
Calibre was launched three times in Tahoe, first when freshly installed and still in quarantine. Following that, the VM was shut down, started up 4 hours later and Calibre was run a second time. The VM was shut down again, and started up two days later for a third run. Log extracts were collected within a minute using LogUI.
Tahoe: First run in quarantine
This proceeded similarly to first run in Sequoia, with the exception of XProtect malware scanning. Soon after com.apple.syspolicy.exec reported that a GK (Gatekeeper) process assessment was starting, it wrote the log entry Skipping up front XProtect scan on: PST: (path: f0970f7f0ab1ff9f), (team: NTY7FVCEKP), (id: (null)), (bundle_id: (null))
That was reiterated later, shortly before the outcome of the GK evaluation Skipping XProtect scan on seen software: PST: (path: f0970f7f0ab1ff9f), (team: NTY7FVCEKP), (id: (null)), (bundle_id: (null))
There were no other log entries that suggested an XProtect malware scan had been attempted.
As is normal in the first run, notarization was checked using CloudKit, there was abundant evidence of CDHash verification, the user was prompted for their approval, and once that was complete the code was allowed to proceed.
Despite the lack of an XProtect scan, launch was as long as previous first runs in recent versions of macOS, taking 10.4 seconds from the second click to launch the app, to display of the prompt for user approval. During that period, a standard progress dialog was displayed. Entries in the log consisted of about 13,000 messages of SecKeyVerifySignature from syspolicyd and trustd, with repeated errors of SecError com.apple.securityd Malformed anchor records, not an array
Tahoe: Subsequent runs
The second and third runs, out of quarantine, were almost identical in the log, and similar to those in macOS 15.7 (below). com.apple.syspolicy.exec announced early that the code had already been evaluated, and those previous results would be used. Provenance data was found, and the evaluation completed without any CloudKit check of notarization. Times from the second click to launch the app, to loading of the app’s preferences were 0.64 and 0.66 seconds.
At various times, the kernel reported that it was considering a malware scan on one of the executables being checked, for example ASP: considering malware scan (activeRulesVersion: 11716915239283693719 lastScanVersion: 0 chgtime: 1758884893 lastFileScanTime: 1758884893 threshold: 1758884893 pid: 949 info_path: /Applications/calibre.app/Contents/MacOS/calibre proc_path: /Applications/calibre.app/Contents/MacOS/calibre isNewerThanScan: 0 needsVersionScan: 0 is_time_eval_exempt: 0 is_scan_version_exempt: 1
Those appear new to macOS 26, and haven’t been seen in any log records from macOS 15.7 or earlier. Executables cited in those messages extended beyond components of Calibre to others that happened to be running at the time, but none was followed by any report of whether a scan was performed as a result.
Although they didn’t delay app launch, at the same time amfid entered the path of the main executable and 112 dylibs and others to check each individually. For the dylibs and others, each was accompanied by a report from the kernel of AMFI: constraint violation [dylib path] has entitlements but is not a main binary
Those took a period of approximately 3 seconds in each of the two runs.
Sequoia: 2nd and 3rd runs
These were remarkably similar, and in many parts identical, to those in Tahoe, except that there were no messages reporting consideration of malware scans. Times from the second click to launch the app, to loading of the app’s preferences were slightly quicker than Tahoe, at 0.59 and 0.59 seconds. Concurrent time to iterate through all the executable components was also shorter at 2.6 seconds, with identical reports of constraint violations.
Conclusions
macOS 26.0 Tahoe does now skip reported XProtect malware scans when a notarized app is run for the first time, when in quarantine.
Despite that, first run checks undertaken in Tahoe can still take significantly longer than in subsequent runs.
This is the result of a vast number of SecKeyVerifySignature entries written during checks on executables.
Tahoe also considers explicitly whether to perform malware scans on other processes being run, although none were undertaken. These are new in Tahoe.
From this evidence, I’m not convinced of any significant improvement in launch times. Please let me know whether you think that Tahoe has improved the speed of your app launches.
Apple has just released macOS 26.0.1 Tahoe, which fixes the problem upgrading to 26.0 on Mac Studio M3 Ultra models, and apparently fixes other urgent bugs.
For Apple silicon, the update is a 1.76 GB download.
Tahoe 26.0.1 fixes a single vulnerability, although Apple doesn’t report that it’s already being exploited. The same is also fixed in Sequoia 15.7.1, and in Sonoma 14.8.1.
macOS 26.0.1 has build number of 25A362, Safari version 26.0.1 (21622.1.22.11.15), and a Darwin Kernel version of 25.0.0. There has been no change in iBoot firmware, which remains at 13822.1.2.
As Apple hasn’t been forthcoming about what else has changed, here’s my list:
Passwords app has gone from version 2.0 to 2.0.1, suggesting it has at least one significant bug fixed.
AppKit framework has had an increment in build number, also suggesting bug fixes.
CoreText framework likewise, with bug fixes for a higher build number, possibly related to the fixed vulnerability in font handling.
Security framework has a substantial increase in build number, implying bug fixes there as well.
No sooner have we recovered from upgrading and updating macOS to 26.0/15.7/14.8 than Apple has released the next round of betas. This article looks at what’s in store for us over the coming year, as far as macOS is concerned.
With pandemics hopefully behind us, Apple’s planned OS updates have settled into a more regular pattern. Release dates when Sonoma was the current version of macOS (2023-24) were:
14.0 – 26 September
14.1 – 25 October
14.2 – 11 December
14.3 – 22 January
14.4 – 07 March
14.5 – 13 May
14.6 – 29 July
14.7 – 16 September.
Over the last year (2024-25), Sequoia has been almost identical, allowing for the small vagaries resulting from our calendar:
15.0 – 16 September
15.1 – 28 October
15.2 – 11 December
15.3 – 27 January
15.4 – 31 March
15.5 – 12 May
15.6 – 29 July
15.7 – 15 September.
If Tahoe follows the same pattern, you can expect releases to occur on the following dates:
26.0 – 15 September 2025
26.1 – 27 October 2025
26.2 – 15 December 2025
26.3 – 26 January 2026
26.4 – 30 March 2026
26.5 – 11 May 2026
26.6 – 27 July 2026
26.7 – 14 September 2026.
If you’d like a week’s notice of scheduled updates, watch Apple’s Developer Releases newsfeed at feed://developer.apple.com/news/releases/rss/releases.rss for Release Candidates. For minor versions, those are normally released about a week before the intended final release, so RCs seen on 20 or 21 October are likely to be followed by the public release on about 27 October.
Those can of course slip a few days or even a week if there are serious problems remaining with a release candidate, and some may be rescheduled to coincide with hardware announcements. These are also the ‘minor’ version updates, and Apple is likely to intercalate ‘patch’ releases to fix any serious bugs or urgent security vulnerabilities. Those almost never go through beta-testing or release candidacy.
For those staying with Sequoia or Sonoma for the time being, those security updates are most likely on the same dates as those for Tahoe.
Finally, a reminder for those whose Macs are still running macOS 13 Ventura: the final security update to 13.7.8 was released on 20 August this year, and Ventura is no longer officially supported by Apple. If your Mac can run Sonoma or later, and you want continuing security updates, then you’ll need to upgrade it to Sonoma 14.8 or later.
Apple has just released its weekly update to XProtect, bringing it to version 5316. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds nine new detection signatures to its Yara file. These include five with novel names:
MACOS.SULFURSLAB.JS
MACOS.FOXTAIL.DEST
MACOS.FLAMINGOFEET.AR
MACOS.COMPLIANTPIRATE.DEFU
MACOS.TETRAGONE.FU
together with MACOS.ODYSSEY.SOBGO for the recently added Odyssey, and MACOS.SOMA.SEENB, MACOS.SOMA.SEENC and MACOS.SOMA.INGOBA for the prolific Amos/Soma family.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5316
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5316 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
It has been barely a year since XProtect changed from stalwart to bogeyman. Over the course of dozens of updates through to macOS Sonoma, if there was one security data update you could rely on, it was XProtectPlistConfigData containing the many rules for XProtect. They guarded us through the dangerous days of Flash Player, the perils of ransomware, and a succession of stealers.
Then in Sequoia that changed, and XProtect’s data became stored in two locations, each with its own update method. The traditional location in CoreServices continued to be updated through softwareupdated, while the copy in the new location in /var/protected/xprotect has been updated by XProtectUpdateService over a connection to iCloud.
With both locations in play, XProtect updates have become more complicated. Some updates only came for one location, such as versions 5273 and 5275 that were released only to Sequoia’s new location. To help us manage XProtect in its new location, Apple provided a command tool, xprotect. That can check which version is available via iCloud, and update that when the local copy was no longer the latest.
One valuable feature was that it could also use a copy in the traditional location to update the new location, in the event that version was more recent than that available from iCloud, but most recently that has been disabled. Now, if a Mac running Sequoia or Tahoe has successfully updated its traditional location but not the copy in the new location, the user is unable to do anything to rectify that, and has to wait until that update is made available from iCloud. Sometimes both are provided at the same time, but it’s also common for iCloud to lag the traditional version by an hour or more, sometimes even longer.
Last week, with the update to XProtect 5315, the day after many of us were preoccupied with macOS updates, something even stranger happened. At around 18:00 GMT on 16 September, softwareupdated became able to download and install that new version into its traditional location, enabling macOS versions up to Sonoma to update successfully. But no such update was made available via iCloud for Sequoia or newly upgraded Tahoe systems, not for another 24 hours. Over that period attempts to obtain or convert the update using xprotect update were unsuccessful.
However, some hours after the traditional update was installed by those who had upgraded to Tahoe, XProtect’s new location was silently updated to 5315. Its version number had gone bump in the night. But if the xprotect command tool couldn’t accomplish that for the user, how could macOS? Were these silent updates coming by telepathy or radio waves?
Although there was no record in any of the usual places, such as Installations in System Information, or even found by my app SystHist, the xprotect version command disclosed that my Mac mini had updated XProtect’s new location at 06:46 GMT on the morning of 17 September, enabling me to hunt that event down in the log.
That update had been accomplished by a background check scheduled and dispatched by DAS-CTS (I have corrected times here to GMT): 2025-09-17 06:46:42.615072 com.apple.duetactivityscheduler REQUESTING START: 0:com.apple.security.syspolicy.xprotect-update:7874AD
This in turn fired up XProtectUpdateService 2025-09-17 06:46:42.695517 com.apple.xprotect Connecting to XProtectUpdateService
2025-09-17 06:46:42.744182 com.apple.security.XProtectFramework.XProtectUpdateService XProtectUpdateService booting
2025-09-17 06:46:43.157255 com.apple.security.XProtectFramework.XProtectUpdateService Attempting to apply update: [private]
2025-09-17 06:46:43.191178 com.apple.security.XProtectFramework.XProtectUpdateService Update completed. Activated update [private]
So the XProtect update had been completed and activated at 06:46 that morning. But how, given that iCloud was still only offering the old version? 2025-09-17 06:46:43.193159 com.apple.syspolicy.activities Finished Xprotect update in 496.4100122451782 ms: Error Domain=XProtectUpdateError Code=2 "Activated update LocalUpdate[5315]" UserInfo={NSLocalizedDescription=Activated update LocalUpdate[5315]}
2025-09-17 06:46:43.193285 com.apple.syspolicy Sent CloudTelemetry event: Xprotectupdateresult
“Activated update LocalUpdate” can only mean one thing, that XProtectUpdateService did what xprotect update used to do, and used the copy of XProtect 5315 in the traditional location to update the new location, taking just under half a second. In addition, com.apple.syspolicy had sent news of that event to Apple via iCloud.
That didn’t work for my old iMac Pro, still running Sequoia, though, which had to wait for the iCloud version of XProtect data to be updated, and wasn’t using version 5315 until 20:17 GMT on 17 September, over 26 hours after its initial release.
Prior to Sequoia, all supported and many unsupported versions of macOS got the same XProtect updates, available immediately they were released through Apple’s software update servers. Just over a year later,
Macs running Sonoma and unsupported versions of macOS could be updated as soon as the softwareupdated update became available, in the traditional way;
Macs running Sequoia could only be updated 24 hours later, when the iCloud update was made available;
Macs running Tahoe could have been updated at any time after the traditional update had been installed, until the update was finally made available through iCloud.
I’m so looking forward to the time when I don’t need to use SilentKnight, the xprotect command and my log browser LogUI to track XProtect updates, and when those become timely again.
Each of the main security services in macOS such as XProtect relies on data commonly stored in separate files on the Data volume so they can be updated directly outside full macOS system updates. Those are released silently by Apple, unannounced, and you aren’t even sent a notification when they’ve been updated.
Currently, those most frequently updated are XProtect and XProtect Remediator, the former being updated most weeks. However, Sequoia changed the way that XProtect’s data is updated, and it’s now intended to occur over a connection to iCloud rather than through Software Update, while XProtect Remediator continues to rely on the latter rather than iCloud.
This article details each of the main security data files found in macOS 26 Tahoe, together with others involved in related system functions. Several other bundles that formerly had roles in security have now been emptied, left frozen in time, or removed completely. As Apple doesn’t document any of them beyond mentioning their existence and simplified role, the information given is the best that I can find currently.
Main Security Data
XProtectPayloads, alias XProtect.app and XProtect Remediator
This contains a suite of specialised malware detection and remediation tools, in the app bundle XProtect.app in the Data volume at /Library/Apple/System/Library/CoreServices. This was introduced in macOS 12.3, then version 62 was pushed to Catalina and later on 17 June 2022. Executables include a replacement for MRT, and many scanners for specific malware types. My free XProCheck inspects its reports for malware detection and remediation. This is normally updated every month or so using Software Update or a substitute.
XProtectPlistConfigData
These are whitelists and blacklists used by XProtect. Since Sequoia, two different locations are used: the primary is at /var/protected/xprotect/XProtect.bundle in the Data volume; the secondary is also in the Data volume at the traditional location of /Library/Apple/System/Library/CoreServices/XProtect.bundle, and can used as a fallback when there’s no bundle at the primary location. While previous versions of macOS still obtain updates through Software Update, Tahoe is also intended to update the primary bundle via a CloudKit connection to iCloud. This is routinely updated every week, at the same time as updates for previous versions of macOS. You can force an update using the command sudo xprotect update in Terminal, if a more recent version is available.
Bastion
These provide rules and exceptions for XProtect Behaviour Service (XBS). First introduced in Ventura, this service monitors for and logs processes that access sensitive locations such as folders containing browser data. This doesn’t block behaviours, only records them in its database at /var/protected/xprotect/XPdb, and reports them to Apple as security intelligence. Bastion rules are defined in bastion.sb and BastionMeta.plist inside /Library/Apple/System/Library/CoreServices/XProtect.app Those are updated irregularly.
AppleKextExcludeList
Latest version: 21.0.0, 9 September 2025 (26.0 release).
This is a huge list of kernel extensions that are to be treated as exceptions to Tahoe’s security rules, and is stored in the Data volume in /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext, at Contents/Resources/ExceptionLists.plist. At one time, this was a blacklist of kexts to block, but in Mojave 10.14.5 that changed, and it has since been a list of over 18,000 kexts that are given exceptional treatment, as explained here. However, this doesn’t appear to apply to Apple silicon Macs, as they have their own separate rules about which kexts to allow and which to block, that are far more stringent. Accordingly, this list should go away in macOS 27.
Others
IncompatibleAppsList
Latest version: 260.200 (26.0 release).
This is a bundle in the Data volume at /Library/Apple/Library/Bundles/IncompatibleAppsList.bundle which contains IncompatibleAppsList.plist, listing many known incompatible versions of third-party products, including Flash Player.
Vestigial Data
MRTConfigData
Last version: 1.93, 14 July 2022.
This was Apple’s Malware Removal Tool stored in the Data volume at Library/Apple/System/Library/CoreServices/MRT.app, so that it could remove any malware which macOS detected. This has now been replaced by the XProtectRemediatorMRTv3 executable module in XProtect Remediator, and may disappear in future versions of macOS. It usually isn’t installed as part of macOS, but is installed later as a security data update.
Gatekeeper Configuration Data (GK Opaque)
Latest version: 181, but can instead be 94.
This is an SQLite database in the Data volume in /private/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db and may have been used to provide whitelists for Gatekeeper’s security system, which checks the code signatures of apps. Macs that have never had Catalina or earlier installed normally have the very old version 94, indicating this database isn’t currently used.
Gatekeeper E Configuration Data (GKE), alias Gatekeeper Compatibility Data
Latest version: 1.0 dated 2 October 2019.
This was an SQLite database in the Data volume in /private/var/db/gke.bundle/Contents/Resources/gk.db with an additional file gke.auth, which may have provided whitelists for Gatekeeper’s security system. gke.auth is believed to contain data for checking signed disk images, and seems to have remained largely unchanged since Sierra. gk.db was new in Catalina and hasn’t changed since. Although this is still downloaded and installed, it’s nowhere to be found in Tahoe, and appears to be a historical remnant.
Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5315. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds three new detection signatures to its Yara file, two for a new entry named Zuru as MACOS.ZURU.LOAD and MACOS.ZURU.BEACON, and the third as another Soma/Amos component named MACOS.SOMA.SEENA.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5315
Sequoia and Tahoe systems only
This update has finally been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check then enter your admin password. If that returns version 5315 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
Update: as of 1100 GMT 17 September 2025, Apple still hasn’t released this via iCloud for Sequoia and Tahoe systems.
Further update: Sequoia and Tahoe systems are now receiving the 5315 update silently, without any change in the version reported by the xprotect tool. So don’t be surprised if your Mac gets updated without the xprotect tool knowing anything about it.
Further further update: over 24 hours after release of this update for older macOS, it has now been made available via iCloud, and the xprotect commands now work, for those Macs that still haven’t updated themselves.
Top economic officials met in Madrid for a second day, with deadlines looming on tariffs and a ban on TikTok in the United States if it is not sold by its Chinese owner, ByteDance.
Apple has just released macOS 26.0 Tahoe (build 25A354), together with security updates to Sequoia taking it to 15.7, and for Sonoma to 14.8. As expected, there are no further security updates provided for Ventura, which is now unsupported.
The upgrade to Tahoe is once again provided as an ‘update’ rather than a full Installer app. If you want to run the Installer app to upgrade, download it from the App Store rather than using Software Update. If you’re updating Sequoia or Sonoma and your Mac is capable of running Tahoe, be very careful to select the right update in Software Update.
The Tahoe upgrade weighs in at 7.7 GB for Apple silicon Macs upgrading from a recent version of Sequoia. For Intel Macs it should be 6.1 GB.
On Apple silicon Macs, iBoot is updated to version 13822.1.2. Intel Macs have their firmware updated to version 2092.0.0.0.0 (iBridge 23.16.10350.0.0,0). Safari is version 26.0 (21622.1.22.11.14). The Darwin kernel version is 25.0.0.
Security release notes are also available:
Tahoe 26.0 lists 75 vulnerabilities fixed, none of which is reported as already being exploited.
When Apple launched its new iPhone 17 range last week, it also announced a major change in their security. This article tries to explain what that means, and whether Apple intends building it into future Macs.
Handling of memory is an important facet of security, and securing that should eliminate plenty of vulnerabilities from Apple’s operating systems. For example, the single vulnerability fixed in Sequoia 15.6.1, and known to be actively exploited, resulted in memory corruption from processing a malicious image file. Many of those fixed in 15.6 also cite memory problems in their cause, such as corruption, out-of-bounds and use-after-free errors. Apple’s research indicates that some of the vulnerabilities used in the most sophisticated attacks, particularly those against iOS, could have been prevented by making memory handling more secure in the first place.
Over the last few years, Apple has focussed attention on making memory handling safer. Starting in iOS 15, it introduced a new interface known as kalloc_type to be used throughout the kernel and all kernel extensions. This requires Apple’s engineers to adopt its new features, and by iOS 16 it’s estimated that 95% of the kernel-space codebase in iOS had been converted. This has been fed through into macOS from Ventura onwards.
Although kalloc_type has helped, more is needed if memory handling is going to as safe as Apple wants, in what it terms Memory Integrity Enforcement. Unlike most other security measures, the principle of this is relatively simple: to allocate and control memory using secure tags. When a kernel extension, for example, requires some memory, it’s provided with a secure tag. When it wants to access any of that memory, the kext then has to provide the tag with its request. The tag is then checked and access only granted if the tag is successfully validated for the address requested.
This can be used to prevent one of the commonest types of vulnerability, accessing memory beyond that allocated in a buffer overflow. As that memory request is out-of-bounds of the memory allocated, the secure tag provided won’t extend to cover that, and the request is refused. Another common type of vulnerability is when code requests memory that has already been freed, in use-after-free access. MIE prevents that as the secure token is invalidated when that memory is freed, so the request is refused.
While the principle underlying MIE is simple, its implementation is more complex. One obvious problem is that it imposes significant overhead to memory allocation and access. The only way to work around that is to implement it in hardware, hence its current limitation to devices using Apple’s new A19 and A19 Pro chips, the first to offer that support. These come with additional features for Arm’s Enhanced Memory Tagging Extension, an option from the Armv8.7 instruction set architecture, and not yet available in an M-series chip for Macs. If you look for FEAT_MTE4 among the hardware options in sysctl (shown easily in Mints, for example), there’s no mention of it in Apple’s latest M4 chips. Additionally, for apps to support MIE, they have to opt in to enable hardware memory tagging, a feature that’s only available for now in the iPhone 17 range, including the iPhone Air.
Critics have pointed out that MIE only tackles some vulnerabilities, but Apple’s analysis of recent real-world exploits used in malware shows how the combination of defences can now disrupt the chains many rely on. By achieving that early in a chain, Apple argues that those developing attacks will be forced to redevelop the whole of that exploit chain. Neither is MIE completely new, as other operating systems like GrapheneOS, popular on Google’s Pixel devices, have already been using their own implementation of similar protection. Apple claims that those have shortcomings it has addressed in implementing MIE for iPhones.
Apple hasn’t yet made any announcement about whether or when MIE might be coming to its M-series chips using in Apple silicon Macs. I suspect we’re unlikely to see the debut of an M5 complete with Neural Accelerated GPU and hardware support for MIE in Apple’s Halloween Mac event, and more likely with macOS 26.3 early next year. Of course, MIE doesn’t protect against everything, but it should make life significantly harder for those intending to attack us.
With macOS 26 Tahoe due to be released on Monday 15 September, I’m delighted to provide version 1.09 of my simple security checker Skint and its menu bar sibling SkintM.
These new versions should recognise Tahoe correctly, and check its version against an updated database.
Skint and SkintM versions 1.09 are now available from here: skint109
from Downloads above, from their Product Page, and via their auto-update mechanism.
Note that, because of the way it (mis)handles Dock icons, Skint might prove to be one of the few apps you run in Tahoe that doesn’t conform to its standard icon format. I also resisted the temptation to make these version 26.
Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5314. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version brings no changes in its text data files, specifically its Yara rules. Wondering if I might be missing something, I have also compared the general release XProtect files with those for Sequoia and Tahoe (delivered by iCloud), and they are identical too.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5314
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5314 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
It’s now almost a year since macOS Sequoia changed security updates, and I’m still being asked how these work. I also suspect a few are wondering whether there will be any changes coming in Tahoe. This article summarises how these work at the moment, and are expected to continue.
Three XProtects
All reasonably recent versions of macOS have three different security features known as XProtect:
The oldest XProtect scans code just before it’s run. This uses one or two XProtect.bundle items containing Yara rules that determine the known malware it can detect. Currently, those are updated once a week.
The newer XProtect.app in /Library/Apple/System/Library/CoreServices is only used in Catalina and later. This runs daily scans to look for malware using its scanning modules, and is also known as XProtect Remediator as it removes malware. Currently, this is updated once a month.
The newest and hidden Behavioural XProtect watches constantly for suspicious behaviour such as apps accessing folders used by Safari and other browsers, according to its Bastion rules. Those rules are contained inside XProtect.app and are updated with it.
So for the time being, you should expect your Mac to update XProtect’s bundle every week or so, and the XProtect app (XProtect Remediator, and Bastion rules) every month.
XProtect Remediator
Roughly once a month, your Mac should download and install a file named something like XProtectPayloads_10_15-155, where the last three digits are its new version number. This is delivered and installed automatically through Software Update, if you have it set to Install Security Responses and system files. You can also download and install it manually using the softwareupdate command, or, easiest of all, using my free SilentKnight.
Legacy XProtect
All fairly recent versions of macOS have a copy of XProtect.bundle in /Library/Apple/System/Library/CoreServices. This is also downloaded and installed using Software Update, softwareupdate or SilentKnight, and the file name is something like XProtectPlistConfigData_10_15-5314. In versions of macOS before Sequoia, this is the only copy of that bundle, and once that has been installed, XProtect is up to date.
iCloud XProtect
Almost a year ago, Apple changed XProtect in Sequoia, and since then Tahoe has followed suit. They not only have legacy XProtect with its XProtect.bundle in /Library/Apple/System/Library/CoreServices, but they have a separate copy of the same bundle in /private/var/protected/xprotect. If you compare those carefully, you’ll see differences, as the legacy copy is signed, but the other isn’t.
When XProtect is updated, Sequoia and Tahoe therefore download and install those two copies separately. The legacy copy is updated exactly the same as in older macOS, through Software Update, softwareupdate or SilentKnight.
The new copy of XProtect.bundle in /private/var/protected/xprotect can’t be updated by softwareupdate or SilentKnight, though. Updating the legacy copy doesn’t alter or update that, which is instead performed over a connection to iCloud. To check and update that copy, you can use the xprotect command in Terminal. The command xprotect version
returns the version of XProtect installed in the new (iCloud-based) location, which can be different from the legacy copy. You can check whether an iCloud update is available using the Terminal command sudo xprotect check
and entering your admin password when prompted to do so. If that version number is higher than that currently installed in the new location, then the command sudo xprotect update
will download and install XProtect from iCloud into its new location.
Can the two XProtects interact?
In Sequoia and Tahoe, both versions of XProtect.bundle will eventually be downloaded and installed automatically. Sometimes, when you’re installing one, the other is also updated. That doesn’t occur because one updater can also update the other copy, but simply because the automatic update process has run. In the early days of Sequoia, the xprotect update command could update the iCloud version from the legacy version, but that stopped working many months ago.
Another behaviour that can appear confusing is when legacy XProtect updates but the iCloud version doesn’t. That often occurs soon after a new version is released, as it almost invariably is made available via Software Update first, so resulting in the legacy version being updated quickly. Sometimes the iCloud update isn’t made available for several hours later, and that may give the impression that updating the legacy version is somehow blocking the iCloud update. That’s easy to check using the xprotect check command: until that reports the new version is available, the xprotect update command won’t work.
How do I know when these updates are available?
I am sometimes asked where I look to check when XProtect and other updates are available, as if Apple publishes this information somewhere. It doesn’t. I use the same tools that you can use, SilentKnight to check for updates via softwareupdate, and the xprotect command tool for those delivered from iCloud. As soon as I find a new update, I install it here, update the databases on Github used by SilentKnight and Skint, analyse the contents of the update, post the announcement here, post that on X/Twitter, then update this blog’s System Updates page.
Do different Macs update differently?
All the code for these updates is contained in the copy of macOS installed in the SSV, the signed snapshot of the System volume that runs your Mac. For any given version of macOS, all Macs, both Intel and Apple silicon, have identical SSVs, although there are differences in their cryptexes and Data volumes. Thus, XProtect updates work exactly the same on all Macs running Sequoia 15.6.1 from my ancient iMac Pro to my latest Mac mini M4 Pro, and I check those with every update as well.
Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5313. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds 4 new rules for components of MACOS.MISOMESA and 7 for MACOS.MISOMAGIC, both new codenames in the Yara file, it also adds a new rule for MACOS.SOMA.AUENC, another Soma/Amos component, and amends the existing detection rule for MACOS.DUBROBBER.CHBI.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5313
Sequoia and Tahoe systems only
This update has now been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5313 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
Inside every Intel Mac with a T2 chip, and every Apple silicon Mac, is a secure enclave, originally referred to as its security enclave. The subject of a flurry of Apple’s patents from 2012 onwards, this was introduced in the A7 chip inside the iPhone 5s and iPad mini 3, 12 years ago in September 2013, where it brought biometric authentication in Touch ID.
iPhone 5s
Protecting the most important secrets in a computer is a great challenge. No matter how secure you try to make the main processor and memory, as they’re exposed to direct attack, isolation can only be relative and temporary. An alternative approach is to move the most secure data and its processing into a secure enclave and its processor, and that’s the architectural solution chosen by Apple in what it patented as a security enclave, filed in September 2012, a year before its release in the iPhone 5s. Engineers credited for that patent are Manu Gulati, Michael J Smith and Shu-Yi Yu.
Successive iPhone chips steadily improved their secure enclaves, and by the time the iPhone 7 was introduced in September 2016, with its A10 Fusion chip, its secure enclave was handling encryption and authentication but not replay prevention. It also had EEPROM secure storage, and an AES engine with DPA protection and lockable seed bits. When the first Intel Mac with a T1 chip was released a couple of months later, that was based not on the A10 but the S2 used in the Apple Watch Series 2. The T1 thus doesn’t really have a secure enclave as such, although it supports Touch ID.
An early and thorough account of these secure enclaves was presented by Tarjei Mandt, Mathew Soling and David Wang at Black Hat USA in 2016. This appears to be the only such account apart from the section in Apple’s Platform Security Guide, most recently updated in December 2024. Apple’s engineers continued to gain new patents, covering trust zone support (filed in 2012), key management (filed in 2014), and most relevant to Macs, Pierre Olivier Martel, Arthur Mesh and Wade Benson’s patent for multi-user storage volume encryption, filed in 2020.
T2 chip
The first Macs with a true secure enclave are those with a T2 chip, starting with the iMac Pro in December 2017. Those are based on the same A10 Fusion chip from the previous year, and were already lagging the iPhone 8 in this respect.
The T2 secure enclave is another co-processor system, run by a Secure Enclave Processor (SEP), a 32-bit ARM CPU running its own operating system, sepOS, based on a specialised L4 microkernel completely different from those used by Macs and Apple’s devices. It has its own secure storage (EEPROM), and a Public Key Accelerator for signing and encryption/decryption using RSA and ECC methods. Outside the enclave is a dedicated AES256 encryption/decryption engine built into the data transfer path between the internal SSD and main system memory.
M-series chips
The big leap forward for Macs was the release of the first models featuring M1 chips, which caught up with the features of late versions (after autumn 2020) of the A12 and A13, with Apple’s second generation Secure Storage Component.
Perhaps the most significant of its improvements are measures to prevent replay attacks. Those are best illustrated with FileVault. Let’s say that you didn’t enable FileVault at first, but left your Apple silicon Mac to handle the encryption of its internal Data volume without the added protection of your password. That would mean that its volume encryption key (VEK) was generated internally by the Secure Enclave, and stored there. If you then turned FileVault on, the VEK would be encrypted using your password and the hardware key. In the T2 chip, it might be possible to use the old VEK to decrypt the volume. In the secure enclave of an M-series chip, that type of replay attack is prevented by the revocation of all previous events and records.
Other improvements include the use of second generation secure storage incorporating counter lockboxes to enforce limits on the number of passcode attempts allowed, instead of an EEPROM, and a better Public Key Accelerator.
Currently, the secure enclave is known to protect the following:
encryption keys for Touch ID, FileVault, and the Data Protection (iCloud) keychain (but not file-based keychains);
that Mac’s Unique ID (UID) and Group ID (GID);
Touch ID control, and (on older devices not Macs) Face ID using a secure neural engine; in recent devices and M-series chips, that’s implemented as a secure mode in the main neural engine (ANE);
Apple Pay handling;
Activation Lock, through the Owner and User Identity Keys;
signing and verification of LocalPolicy for boot environments (Apple silicon).
Communication between the CPU and SEP is performed using a dedicated mailbox whose function is detailed in Apple’s patents. Further information is also provided in the Platform Security Guide.
FileVault encryption
It has been stated widely (even here) that the secure enclave in T2 and Apple silicon chips contains a hardware encryption/decryption unit and acts as the internal SSD’s storage controller. In fact, as shown in the original patent of Martel and others, and now in the Platform Security Guide, the AES engine responsible is located outside the secure enclave, together with the Flash controller, and has a secure link to the enclave.
During SEP boot, it generates an ephemeral key to wrap keys to be used by the AES engine for encryption and decryption. That key is sent from the secure enclave to the AES engine over the dedicated connection between them, then used to protect keys transferred from the enclave to the AES engine. That ensures an unprotected key is never exposed outside the enclave and AES engine.
The Apple silicon secure enclave is by no means unique. ARM TrustZone, other Trusted Execution Environments, and Trusted Platform Modules offer similar features and facilities. However, the secure enclave is unusual because it has been integrated into all Macs with T2 or Apple silicon chips, and all Apple’s recent devices, and can’t be disabled or bypassed.
References
Manu Gulati, Michael J Smith and Shu-Yi Yu, US Patent 8,832,465 B2, Security enclave processor for a system on a chip, filed 25 September 2012, granted 9 September 2014.
R Stephen Polzin, James B Keller, Gerard R Williams, US Patent 8,775,757 B2, Trust zone support in system on a chip having security enclave processor, filed 25 September 2012, granted 8 July 2014.
R Stephen Polzin, Fabrice L Gautier, Mitchell D Adler, Conrad Sauerwald and Michael LH Brouwer, US Patent 9,419,794 B2, Key management using security enclave processor, filed 23 September 2014, granted 16 August 2016.
Pierre Olivier Martel, Arthur Mesh and Wade Benson, US Patent 11,455,432 B1, Multi-user storage volume encryption via secure processor, filed 8 June 2020, granted 27 September 2022.
Tarjei Mandt, Mathew Soling and David Wang (2016), Demystifying the Secure Enclave Processor, Black Hat USA 16 (PDF)
Apple, Platform Security Guide
Wikipedia’s overview of Apple silicon chips.
Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5312. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds three new detection rules: MACOS.SOMA.AUENB augmenting rules for the Soma/Amos family, MACOS.DUBROBBER.CHBI for another Dubrobber variant, and MACOS.ODYSSEY.LELI for an additional Odyssey variant.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5312
Sequoia and Tahoe systems only
This update has now been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5312 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
When Mac OS X 10.0 was released in March 2001, privileges, permissions and security adopted a conventional model based on BSD and Unix. Those sufficed for 15 years until the release of OS X 10.11 El Capitan in September 2015, when System Integrity Protection, SIP, was introduced. This article outlines its history over the last decade.
2015 Introduction
The first public account of SIP was presented by Pierre-Olivier Martel at WWDC 2015 in June, and documented in Apple’s System Integrity Protection Guide that September, which hasn’t been revised since. These changes were justified as adding a further layer of security protection to prevent attackers from gaining full control by escalating privileges to root.
Three types of protection were promised:
file system protections, so that system files could only be modified by processes signed by Apple;
prevention of runtime attachment, code injection, or modification of system binaries, with modifications only permitted by Apple’s installers and updaters;
kernel extensions (kexts) had to be signed using special certificates granted by Apple.
Each Mac’s SIP configuration was stored in NVRAM, and controlled by the csrutil command used in Recovery mode.
When released, the csrutil command provided some degree of separate control over six groups of features: file system protections, debugging protection, DTrace protection, kext signing requirement, NVRAM and ‘Apple internal’ protection. One immediate beneficial side-effect was that SIP prevented permissions being changed for system files, and that made the practice of repairing permissions on them unnecessary, allowing removal of support for that procedure from Disk Utility.
2015 Conflicts
Press reviews of the SIP feature were divided, with some claiming it was a sign that OS X was being closed down and moved to the iOS security model, while others considered that few users would notice much difference.
Problems resulting from SIP were reported soon after El Capitan’s release. For example, some older Mac models intentionally prevented their use with Apple USB SuperDrives. One workaround to address that had been to modify one of the files now protected by SIP, which consequently required the user to disable SIP to make that change.
As kernel extensions hadn’t previously been required to be signed at all, other early casualties were all older unsigned kexts, making some apps unusable unless a new version was provided with a correctly signed kext.
2016 Error
Late in 2016, it became clear that Apple had shipped a substantial batch of new MacBook Pro systems with SIP disabled. At that time, System Information was unable to report SIP status, and the only way to enable protection was to start that Mac up in Recovery mode and use the csrutil command in the Terminal app there. That applied to macOS Sierra 10.12 to 10.12.1.
To make this easier, Apple changed csrutil so that it could enable SIP when invoked in normal running mode, provided it was run with elevated privileges obtained using sudo. Despite that, some of those affected MacBook Pro models didn’t have SIP enabled correctly for several months.
2017-18 Problems
Over the following years, SIP continued to cause irritations that infuriated some users.
Bundled apps in the main Applications folder were protected by SIP, and that prevented the user from modifying them. As the handling of kexts changed, it was discovered that SIP made it awkward to remove old kexts the user had installed. That was because the folder /Library/StagedExtensions was put under the protection of SIP by attaching a com.apple.rootless extended attribute to it.
One reading of that extended attribute is that only Apple’s KernelExtensionManagement service can give permission for changes to be made within that folder, and the folders within it.
2020 Extended attributes
Apple later used SIP to lock down individual extended attributes (xattrs) attached to regular unprotected files. The first example of this was the undocumented com.apple.macl xattr that macOS started to attach widely to all user documents. Presence of that xattr was implicated in some problems in which those documents became locked down and unable to save changes, despite permissions and other visible attributes showing that the user had full ownership of the file. The only workaround for this has been to copy the file to another volume, where the xattr no longer has the protection of SIP, and can be stripped.
When Apple later introduced another undocumented xattr com.apple.provenance, that too was sometimes but not always protected by SIP, although that hasn’t been implicated in problems visible to the user.
2022 Launch constraints
Launch constraints were introduced in macOS 13 Ventura and iOS 16 in 2022. Every executable binary in the system now has a set of rules determining the requirements for that binary to be launched. These include self constraints that the binary itself must meet, parent constraints that must be met by its parent process, and responsible constraints that must be met by the process requesting the launch. Together these form that code’s launch constraints. To make those constraints simpler, they come in different categories, ranging from 0, in which there are no constraints at all, to combinations that prevent launch by processes that aren’t themselves part of the system and require the code itself to be on the System volume.
Although Apple has documented these for developers, they can cause unexpected behaviour for users, who haven’t been given any explanation. Testing has demonstrated that launch constraints are dependent on SIP, so must be assumed to have been added to its list of protections.
2024 Malware scans
Many users have reported slowing app launch times in recent versions of macOS. In February 2024, Jeff Johnson investigated these, and concluded that the cause was the macOS security system repeatedly performed malware scans against a growing set of Yara rules. These stopped when SIP was disabled, implying that this is yet another protection that has been added to those controlled by SIP.
2024 Current protections
Current user documentation for SIP explains only its file system protection, csrutil‘s man page refers to its usage information, but from that and XNU it’s possible to separate out its controls to include the following, at least:
Filesystem Protections, disabled by CSR_ALLOW_UNRESTRICTED_FS, abbreviated to fs
Debugging Restrictions, disabled by CSR_ALLOW_KERNEL_DEBUGGER and CSR_ALLOW_TASK_FOR_PID, abbreviated to debug
DTrace Restrictions, disabled by CSR_ALLOW_UNRESTRICTED_DTRACE, abbreviated to dtrace
Kext Signing, disabled by CSR_ALLOW_UNAPPROVED_KEXTS, abbreviated in csrutil to kext
NVRAM Protections, disabled by CSR_ALLOW_UNRESTRICTED_NVRAM, abbreviated to nvram
Apple Internal, disabled in XNU by CSR_ALLOW_APPLE_INTERNAL, and only disabled when SIP is fully disabled
BaseSystem Verification, abbreviated to basesystem
Boot-arg Restrictions, disabled with nvram
Kernel Integrity Protections, disabled with kext
Authenticated Root Requirement, disabled by CSR_ALLOW_UNAUTHENTICATED_ROOT, managed separately using csrutil authenticated-root disable and enable
Additional configuration flags available in XNU that don’t appear to be directly supported by csrutil include: CSR_ALLOW_TASK_FOR_PID, CSR_ALLOW_DEVICE_CONFIGURATION, CSR_ALLOW_ANY_RECOVERY_OS and CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE. Those should be disabled when SIP is fully disabled.
2015-2025 Vulnerabilities
Over the last decade, many vulnerabilities have been discovered in SIP that have allowed parts of its protections to be bypassed. Among the most recent is CVE-2024-44243 discovered by Jonathan Bar Or (@yo_yo_yo_jbo) of Microsoft Threat Intelligence and Mickey Jin (@patch1t), and fixed in the update to macOS 15.2 Sequoia. However, this wasn’t fixed in Sonoma until the following round of updates (14.7.3), and appears to remain unpatched in Ventura 13.7.8.
Microsoft’s report explains how bypassing just one of SIP’s many protections can give access to bypasses of more or all of SIP’s other protections. Note also how Apple’s description of the vulnerability in its security release notes refers to StorageKit but doesn’t reveal that this affected SIP.
Over the last decade, SIP has grown like Topsy from three protections that seemed worthwhile and simple, into a protean collection of many parts that remain largely undocumented and pervade much of modern macOS security.
There are so many controls in macOS that sometimes you can’t see the wood for the trees. This can leave uncertainty over essentials, such as whether your Apple silicon Mac really is properly secure, or maybe there’s something sinister going on with it? This is a question I’m asked not infrequently, usually when someone has been spreading disinformation or FUD (fear, uncertainty, doubt). So how can you check that your Mac is properly locked down and boots securely?
Quick checks
There are two quick checks that cover the essentials. First, open System Information and select the Controller section in Hardware.
This provides a brief summary of your Mac’s boot security, which should read as shown above. If you still need to use a kernel extension or similar, your Mac might show Reduced Security with Allow All Kernel Extensions enabled, but you should do everything you can to avoid that.
Secure Boot is controlled using Startup Security Utility in Recovery mode, and if you care to start up in that mode, you can confirm or correct its settings there.
Back in normal user mode, open Privacy & Security settings and ensure you have FileVault enabled there.
SilentKnight also checks that XProtect/Gatekeeper checks are enabled, and that security data are up to date, giving you complete confidence.
Details
Although those should be sufficient for most, some want to go further and verify that their Mac’s boot process and security systems are also working correctly. To do that, shut your Mac down, wait ten seconds or so, and start up normally with the startup chime sounding at a known time. Enter your password, wait a few seconds for the Finder to get set up and running, and open LogUI. Set its time to that of the startup chime, and get the first 10 seconds or 10,000 log entries. You may need to adjust the seconds to capture the full boot sequence. When you have, look through the log and identify the following waypoints.
In each of these log entries, I have emboldened a word or two that you can copy from here and paste into LogUI’s Search box, then press Return. That will display the log entry, and sometimes others you might find relevant. Times are given here in seconds, with the startup chime occurring at about 37 seconds. Version numbers shown are those for macOS 15.6.
The start of boot is recorded as 37.562774 === system boot: [UUID]
and a little while after that, the kernel declares its version details 42.759300 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041
for macOS 15.6.
Further down you’ll come across more information about key security components, including the Trusted Execution Monitor 43.060422 [Log]: Code Signing Monitor Image4 Module Version 7.0.0: Fri Jul 11 16:51:29 PDT 2025; root:AppleImage4_txm-320.100.22~1090
43.060447 [Log]: build variant: txm.macosx.release.TrustedExecutionMonitor_Guarded-135.100.37
Then the iBoot firmware version 43.061758 iBoot version: iBoot-11881.140.96
43.061760 iBoot Stage 2 version: iBoot-11881.140.96
CoreCrypto support is vital, and another Image4 extension 43.137635 FIPSPOST_KEXT [133796636] fipspost_post:154: [FIPSPOST][Module-ID] Apple corecrypto Module v18.3 [Apple silicon, Kernel, Software, SL1]
43.242334 Darwin Image4 Extension Version 7.0.0: Mon Jul 14 11:23:46 PDT 2025; root:AppleImage4-320.100.22~2585/AppleImage4/RELEASE_ARM64E
You should see entries reporting the loading of security policy components 43.242343 Security policy loaded: AppleImage4 hooks (AppleImage4)
43.242961 Security policy loaded: Apple Mobile File Integrity (AMFI)
43.243092 Security policy loaded: Seatbelt sandbox policy (Sandbox)
The Secure Enclave Processor or SEP is another key component that has to be started up 43.264594 "AppleSEPKeyStore":326:0: starting (BUILT: Jul 14 2025 23:34:10) ("normal" variant 🌽 , 1827.120.2)
43.264639 "AppleSEPKeyStore":471:0: _sep_enabled = 1
Apple System Policy should follow a bit later 43.760156 Security policy loaded: Apple System Policy (ASP)
43.760188 AppleSystemPolicy has been successfully started
The root of the file system is then identified in two entries whose origins go right back to the start of Mac OS X 43.940643 BSD root: disk3s1
43.940644 , major 1, minor 13
And APFS mounts the root file system, using the SSV snapshot 43.941048 apfs_vfsop_mountroot:2984: apfs: mountroot called!
44.034685 apfs_vfsop_mount:2763: disk3s1 Rooting from snapshot with xid 1724240.
One of the most important entries comes shortly after that, where successful validation of the SSV’s root hash is reported 44.038830 authenticate_root_hash:642: disk3s1 successfully validated on-disk root hash
It’s now time to start user space processes, and for that launchd must be loaded so it can launch everything else 44.103761 load_init_program: attempting to load /sbin/launchd
How Secure Boot works
Apple silicon Macs have a small ROM to support DFU mode in case a full Restore is required, and to check and load the first stage of the ‘firmware’, the Low-Level Bootloader or LLB. Only if that matches its signature will the ROM firmware hand over to it and proceed with the boot process. The LLB in turn performs the same checks on the second stage ‘firmware’, iBoot proper. That goes on to check the kernel, before loading that and handing over for kernel boot to take over.
iBoot ‘firmware’ doesn’t write anything in the log, but once the kernel takes over its log entries provide a detailed account of its progress. The great majority of its log entries are unintelligible to anyone outside Apple, but the waypoints I have given above identify some of the most important steps it takes. When it’s ready, the kernel validates the root hash for the SSV snapshot, as noted above, enabling the boot process to proceed to load and run other parts of macOS. The remaining hash checking of the SSV, to confirm that it’s exactly as Apple intends, proceeds in a ‘lazy’ fashion, as access is needed to its contents.
This chain of validation before loading the next stage ensures that nothing in the boot process can be tampered with or changed, and the boot is secure throughout. Apple provides further details in its Platform Security Guide.
Apple has just released urgent security updates to bring macOS Sequoia to 15.6.1, Sonoma to 14.7.8, and Ventura to 13.7.8.
Security release notes for these are already available, for 15.6.1, 14.7.8 and 13.7.8 Each refers to the same single vulnerability in ImageIO, which is apparently being exploited “in an extremely sophisticated attack against specific targeted individuals” using a crafted image file.
The download for 15.6.1 is about 1.56 GB for an Apple silicon Mac, and should be well under 1 GB for Intel. Time to update!
Security utilities that detect known malicious software do so using sets of detection rules. Since their introduction by Victor Alvarez of VirusTotal 12 years ago, the most common method of expressing these rules is in a text file with the extension .yara. Apparently YARA stands for either YARA: Another Recursive Acronym, or Yet Another Ridiculous Acronym.
Yara rules are used extensively in macOS by both the original XProtect and its sibling XProtect Remediator. Those of XProtect are found in the XProtect.yara file in XProtect.bundle, in /Library/Apple/System/Library/CoreServices and its additional location in /private/var/protected/xprotect in Sequoia and later. Further Yara rules are also encrypted and embedded in XProtect Remediator’s scanning modules, as detailed by Koh M. Nakagawa in the FFRI Security GitHub.
As used by Apple, each rule can consist of up to three sections:
meta, containing the rule’s metadata including a description and in more recent cases a UUID for the rule.
strings, specifying some of the content of the file, typically in the form of hexadecimal strings such as { A0 6B }.
condition, a logical expression that, when satisfied, meets the requirements of that rule, so identifying it as malicious.
I’ll exemplify these using Yara rules used in XProtect version 5310.
Private rules
At the start of the Yara file are any private rules. These are a bit like macros, in that they define properties that are then used in multiple rules later. Laid out in compact form, an example reads:
private rule Shebang
{ meta:
description = "private rule to match shell scripts by shebang (!#)" condition:
uint16(0) == 0x2123
}
This starts with description metadata for this private rule, then states the condition for satisfying this rule, that the first 16-bit unsigned integer in the file contains the hex 0x2123, the UTF-8 characters 0x21 or ! and 0x23 or #. In the reverse order of #! they’re known as the shebang, and the opening characters of many shell scripts, but in this rule they are given the other way around because of the byte order used in the 16-bit integer.
This defines what’s required of a Shebang, and can be included in the conditions of other Yara rules. Instead of having to redefine the same feature in every rule, they can simply include that Shebang rule in their condition.
Regular rules
After 3-5 private rules, the XProtect Yara file goes on to enumerate 372 normal rules, including this one:
This rule has its internal code name as its description, and has been assigned the UUID shown. It then defines two binary strings, a0 and a1, the former containing ‘wild’ values expressed using the question mark ?. The condition for satisfying the rule is that the file must:
There are standard implementations that can check files against custom sets of Yara rules. Rules are normally compiled into binary form from their text originals before use. Full details are given on VirusTotal.
Apple’s use of Yara files is mysterious, as for some years all the descriptions used arbitrary code names as obfuscation. When the source of all the rules is given in plain text, it’s hard to see what purpose that served, and it meant that users were told that MACOS.0e32a32 had been detected in an XProtect scan, for instance. Thankfully, Apple has more recently replaced most of those with more meaningful names.
I’m grateful to Duncan for asking me to explain this, and hope I have been successful. I’m also grateful to isometry and an anonymous commenter for straightening out the confusion over the Shebang.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5311. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds eight new detection rules, for MACOS.BANSHEE.MA, MACOS.BANSHEE.MA2, MACOS.SOMA.GEGO, MACOS.POSEIDON.B, MACOS.TIMELYTURTLE.FUNA, MACOS.TIMELYTURTLE, MACOS.TIMELYTURTLE.INDRBYSE and MACOS.TIMELYTURTLE.INDR. Banshee, Poseidon and TimelyTurtle are new names in XProtect’s Yara rules.
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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5311
Sequoia and Tahoe systems only
This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5311 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
XProtect is the front-line tool in macOS for detecting known malware. When a downloaded app is run for the first time and put through Gatekeeper checks, those rely on detection rules defined in the XProtect.yara file inside the XProtect bundle in /System/Library/CoreServices. Those are updated periodically to extend their coverage as new malware is detected and analysed by Apple’s security engineers. This article looks at how they have changed over the last six years.
My starting point is XProtect version 2103 released on 2 May 2019, in the heyday of macOS 10.14.4 Mojave. That contains a total of 92 rules in a text file of 42,903 bytes, for an average rule size of 456 bytes. Among those are many old chestnuts such as Bundlore.
My end point is version 5310 released this week, on 12 August 2025, for macOS 15.6 Sequoia and earlier. That contains a total of 372 rules in a text file of 969,662 bytes, giving an average rule size of 2,572 bytes. Still among those are the same old chestnuts including Bundlore.
Thus the number of rules is now 4 times what it was six years ago, and they take over 22 times as much space.
For the period up to the end of 2023, I have analysed XProtect’s Yara file in updates every 6 months, in May and November, or the closest update available. From the start of 2024 updates became more frequent, and I have therefore analysed the last update in each month. In late 2024, XProtect in macOS Sequoia started using iCloud to deliver its XProtect data updates. For this analysis I have excluded version 5273, which was only released via iCloud and wasn’t provided through the regular softwareupdate route used by all previous versions.
The number of Yara rules increased steadily until updates became more frequent in 2024, following which there was a very steep rise early that year. Since then they have continued to rise more steeply than before 2024, but now appear more linear, as seen in the red line of regression. Over this period, hardly any Yara rules have been removed.
Total size of the Yara file has followed a similar pattern, with little change until the start of 2024. It then peaked briefly before reducing slightly, pausing a little, then undergoing a step increase from 288 KB to 877 KB. Growth has been steadier for the last year, although it appears to be on track to reach 1 MB in 2026.
Average size of Yara rules changed little between 2021-2023, but increased greatly with the addition of some very large rules in June-July 2024. It has since declined slowly, as more recent rules have been far smaller.
This prodigious growth in the number of Yara rules and their size has inevitably had its effect on the time taken to complete Gatekeeper checks that include XProtect scans. macOS Tahoe has been promised to limit that, by not scanning notarized apps with XProtect, so improving app launch times.
Given that remarkably few old Yara rules have been removed over the last six years, this growth has been inevitable. However, unless old malware is incapable of being run on Macs still supported by XProtect updates, it’s hard to see how it could be safe to remove old rules. When support for running x86 code (except that for “older unmaintained gaming titles”) is dropped from macOS 28, many older Yara rules could be dropped from XProtect updates without putting Apple silicon Macs at risk, but even that isn’t an easy decision. In the meantime, at least our faster Macs should be able to complete XProtect scans more quickly.
Login
