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.

Last updated: 19 September 2025.

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.

References

Wikipedia’s account, still largely based on SIP in 2015
This blog on csrutil controls

With the next scheduled update to macOS Sequoia likely to be released in September or October, macOS 15.6 officially marks the end of its year-long cycle of full support. This article looks at its updates and how it has changed.

Updates

It took Sequoia a total of 11 updates to reach version 15.6 at the end of July, including five unscheduled patch updates, which is close to average. Prominent through those updates has been the number of security vulnerabilities addressed, peaking at 81 in 15.6.

In terms of cumulative size of updates, Sequoia was close to average at a total of 27.5 GB for Apple silicon Macs and 19.3 GB for Intel models. Although not as bad as Big Sur which took over 50 GB for Apple silicon Macs, it wasn’t as good as Sonoma at just over 21 GB. Update size was relatively small up to 15.3, but added over 9 GB in the three updates it took to reach 15.4. Apple doesn’t appear to have made progress in reducing the size of updates for Apple silicon Macs, and that may not be achieved until macOS 27 next year, when Intel support is finally dropped.

Bundled apps

The total number of bundled apps has increased slightly, from 60 in Sonoma to 62 in 15.0, and 64 in 15.6. That’s set to rise again in Tahoe, with the addition of Journal and Phone.

/System/Library

The total number of bundles in /System/Library has risen further to reach 9,304, almost double the number in 10.14.5 six years ago, and up from 8,392 a year ago in 14.6. Unusually, this has risen by nearly 300 through Sequoia’s cycle. Previously it has been more common for only small rises to occur during a cycle, and in macOS 13 the total fell slightly.

Over that period, the main growth has been in the number of Private Frameworks, which have risen from about 1,760 in 10.14 to over 4,400 in 15.6. Public Frameworks have risen less, from less than 520 to 806. Despite Apple’s campaign for third-parties to move away from kernel extensions, those in macOS also continue to grow, rising from a minimum of 515 in 10.15.0 to 939 in 15.6. Sequoia has added 39 of those in going from 15.0 to 15.6.

This is a more detailed breakdown by category of bundles in /System/Library, comparing 10.15.6 with 15.6:

• Accessibility, a small increase from 125 to 161
• Automator, a small reduction from 266 to 252
• Templates, a marked reduction from 383 to 252
• CoreServices, a small reduction from 390 to 363
• AssetsV2, a substantial growth from 188 to 806
• Public Frameworks, a modest increase from 600 to 806
• Kernel extensions, a substantial increase from 534 to 939
• Private Frameworks, a huge increase from 2,055 to 4,407.

Five years ago in 10.15.6, public Frameworks were almost a quarter of all Frameworks. In 15.6, they are less than 18%. macOS continues to become an increasingly private operating system supporting Apple’s apps, not those of third party developers.