Signing and notarization of apps and other executable code is a controversial topic. Over the last decade and more Apple has steadily introduced increasingly demanding standards, now requiring developers to notarize apps and other code they distribute outside the App Store. This article tries to explain why, and how this contributes to Mac security.

I would hope that what we all want is confidence that all executable code that our Mac runs, in particular apps, is exactly as was built by its developer. In addition to that, in the event that any code is found to be malicious, then macOS can promptly protect us by refusing to launch it. The first requirement is thus about verification of apps and code, and the second is about having a system that can block code from being launched in the first place.

CDHashes

The well-proven way to verify that files and bundles haven’t changed is using cryptographic hashes of their contents. Compute a hash, save it in a way that can’t be tampered with, and you can verify a bundle by recomputing its hash and confirming that it hasn’t changed. Apple has been using this for a long time, and its approach is a little more complex, as explained in detail in this excellent tech note.

When an app is signed, hashes are computed for different parts of its contents and assembled into a code directory, a data structure rather than a folder/directory. That data structure is then hashed to form the cdhash, or CDHash with mixed case to aid its reading. Because it’s a hash of hashes, it uniquely identifies that app, bundle or other executable code. CDHashes are thus part of the signing process, and the signature contains those CDHashes. They are also part of the notarization process, in which Apple’s Notary Service signs the CDHashes for code when it undergoes notarization, and that forms the notarization ticket that’s issued for that app, and normally attached or ‘stapled’ to it.

Between them, code signing and notarization thus provide two levels of verification, in a signature attached to the code itself, and in a record kept by Apple following successful notarization.

Unsigned apps

An unsigned app has no CDHashes, so its contents are uncontrolled and no verification is possible. It can change its own contents, morph itself from benign to malicious, forge its identity by posing as a completely different app, or be hijacked to run malicious code. While macOS could compute its CDHashes and Apple could try to track them, there’s no way to verify its identity, so external checks aren’t feasible, and there’s no way to block the code from being launched, as all it would need to do to evade that would be to change itself so its CDHashes changed.

Although macOS running on Intel Macs long tolerated this, from their release four years ago, Apple silicon Macs have refused to run such unsigned code.

Ad-hoc signed apps

Since Apple required code to be signed for Apple silicon Macs, all self-respecting build systems for macOS have automatically signed the code they generate. However, unless the developer has a certificate issued by Apple, by default they use ‘ad hoc’ certificates that are created locally and lack any chain of trust. That enables anyone to create CDHashes at any time, without any traceability to a trusted root certificate.

This is a slight improvement on completely unsigned code, and does enable an app to be identified by its CDHashes, but as they’re so easy to create, there’s no reliable way to verify that the app hasn’t changed since its original build. Although Apple could try to collect those CDHashes, there’s no useful way to block code from being launched, as all an adversary needs is to resign the code to change its CDHashes: they’re simply too labile to be trustworthy.

Certificate signed apps

For many years, before Apple introduced notarization over six years ago, this was the standard expected, but not required, of apps distributed by third-party developers. Although in theory developers could have used certificates provided by other authorities, not all Certificate Authorities are equal in their diligence, and Apple rightly wanted to be responsible for all revocations.

Certificates add control and verification, within limits determined by the certificate user. CDHashes gathered from code can be collected, but again their provenance relies on their user. At one time, they were commonly abused by those distributing malicious software. Although abused certificates were revoked by Apple, before that could happen, the malware had to be detected and identified, which could allow it to be run by many users for long before it could be blocked.

Certificate checks were another problem with this approach. It isn’t practical to check each certificate every time code is to be launched, so approvals have to be cached locally, adding to the delay before any revocation becomes effective.

Notarization

To address the limitations of signing code using developer certificates, Apple introduced the process of notarization. In this context, it adds:

• CDHashes from notarization are known to Apple, and stored in its database, for quicker online checks, and more rapid revocation.
• Apple screens apps being notarized to detect those that may be malicious.
• Apple has a complete copy of every app that has been notarized, and already knows its CDHashes.

This finally checks the provenance of all code being run, through its CDHashes; if they’re not already known to Apple, then that build of the app can’t have been notarized, and can be blocked from launching, provided the user doesn’t disable notarization checks. Screening for malware forces those trying to get malicious code notarized to adopt techniques of obfuscation, but even if those are successful, Apple already has a copy of that app and its CDHashes. That eliminates much of the delay incurred by certificate-signed apps. Together these have proved sufficient disincentive to malware developers to try to abuse notarization.

Key features of notarization are thus:

• Verification that the app or code hasn’t changed since it was built by its developer, up to the moment that it’s run.
• Independent verification against Apple’s database.
• Rapid blocking if the app or code is discovered to be malicious.
• Apple is provided with a full copy of the app or code, to aid any further investigation.
• All apps or code are checked independently for evidence that they’re malicious, before they can be released.

If you can come up with a system that achieves those and could replace notarization, I’m sure that Apple would love to hear of it.

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

Startup

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

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

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

User Data

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

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

Run Apps

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

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

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

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

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

Private Data

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

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

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

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

Downloaded Apps

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

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

Bad Links

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

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

Summary

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

Work and play safely!

When Apple introduced notarization six years ago, it warned us that it would eventually become obligatory for developers, and reassured us that we would still be able to run our own apps that aren’t notarized. macOS Sequoia is the first version of macOS to expect apps delivered from outside the App Store to be notarized, but still to allow us to run apps that aren’t. This article explains how that’s accomplished, and what you should do to work within these new rules.

Sequoia’s rules

When an app is being launched for the first time on that Mac, if it has been put into quarantine with a quarantine extended attribute, Gatekeeper will check whether it has been notarized. If it has, then its launch will progress to further checks such as those of XProtect. If it hasn’t been notarized, then macOS will warn you of that, and halt its launch.

If you want to launch the app despite that warning, open Privacy & Security settings, where you can click the button to Open Anyway.

You will then be warned again, and given the advice “don’t open this unless you are certain it is from a trustworthy source.”

Clicking Open Anyway then takes you to the third dialog, where you’ll need to authenticate to launch the app.

Why all the dialogs?

The old Finder bypass for Gatekeeper was simple: use the contextual menu to Open the app, and there’s a single dialog to get through. That’s so simple that it has become widely used by malware.

These are the helpful instructions provided by one of the most widely encountered malicious apps, Atomic Stealer, when you mount its disk image. The invitation is hard to refuse unless you know the trouble it will bring. Detailing the new bypass system is going to prove a real challenge to those intent on delivering us their malicious apps.

How to run your own apps

The best way to avoid getting embroiled in this process is to build your own apps locally. All modern build systems such as Xcode and its tools now apply an ad-hoc signature to the app or command tool, but their products aren’t put into quarantine. Starting with the source code gives you the opportunity to satisfy yourself that the code hasn’t been tampered with, or is malicious. You may also be able to verify checksums or hashes to provide additional reassurance.

Using pre-built apps and tools brings significant risk. Supply-chain attacks are increasingly common, so even if you’re prepared to trust the source of the app, they may be unaware that it has been tampered with. Remember that, in security terms, there’s no robust way to tell the difference between a benign app and malware unless it has been notarized.

How to move apps between Macs

One of AirDrop’s annoyances is that everything transferred so conveniently also acquires a quarantine extended attribute, so putting it through full Gatekeeper first run checks on notarization. This isn’t just done to annoy, but allows for the fact that AirDropped apps can come from untrusted sources.

If, instead of using AirDrop, you use local file sharing, no quarantine extended attribute is added, and your unnotarized app won’t be put through a full first run check, so you won’t have to suffer the dance of the three dialogs before it will launch.

If you have access to a Developer ID and need to distribute an app more widely, you can notarize other developers’ apps. Apple has made it clear that submission of an app for notarization doesn’t have to be performed by its developer, the owner of the certificate used to sign the app with, but anyone with a current developer account with Apple can do so provided they follow the correct process. This is most appropriate for those in enterprise and organisations who need to use third-party products that aren’t yet notarized by their developer.

Tricks to avoid

You can of course strip the quarantine extended attribute before trying to run an app for the first time. This is a potentially dangerous workaround, as it bypasses first run checks that could spot malware. For those of us who often transfer our own apps for testing using AirDrop, it’s easy to drop them into a folder, Zip that, then on the recipient Mac strip the quarantine xattr before unZipping the archive. My utility Cormorant can make that even simpler. If you were to opt to do that, you must be absolutely certain of the provenance of the app you’re transferring.

For those who have test systems that frequently need to run unnotarized apps, another potential solution has been to disable Gatekeeper on them. Perhaps anticipating a move to do that, Apple has changed how this can be done, making it a two-step procedure, in which you first allow the disabling of checks, then in Privacy & Security settings control how that’s implemented. Apple encourages those who need to do this to use installed profiles instead, or handle it through MDM payloads. This has been explored in detail by Brandon Dalton in his account of these changes.

Is notarization worth it?

In terms of risk alone, only ever running code on your Mac that has been signed by Apple (all macOS code, all App Store apps) or has been notarized by Apple, is almost the safest policy (after running only those apps bundled with macOS). In the early years of notarization, a handful of malicious apps did manage to get notarized for a brief time, but it has been a good while since the last of those. The highest risk strategy is to ignore notarization completely, as it allows all malware to run freely.

There has been a lot of misinformation as to how notarization does or doesn’t work. It’s a key part of Apple’s switch from relying on the chain of trust in code signatures to assessing executable code using its CDHashes. Every notarized app is associated with CDHashes that can verify the integrity of its code, and can be compared against those obtained during the notarization process. This allows Apple to divide code into one of three classes:

1. known good, gathered from notarization,
2. known bad, discovered in malicious code in the wild,
3. unknown, found in code that hasn’t been notarized, or found in known malware.

If all the code that your Mac runs is in the first category, or signed by Apple, then it’s at lowest risk. What you should aim for is to ensure that any code in the third category can’t turn out to be malicious.

Over a series of three articles last week, I pored over thousands of log entries to examine how macOS Sonoma 14.6.1 checks applications it’s launching, under normal full security settings, with reduced security, and for known malware. This article draws together my conclusions from those tests run in virtual machines on an Apple silicon Mac.

Layered security

Like other security functions in macOS, app launch security is built in layers, including checks of

• code-signing certificates (multiple times);
• CDHashes, including their consistency, and against Apple’s database for notarized apps, and their revocation;
• quarantine extended attributes, which normally trigger a user consent dialog, and may result in app translocation;
• previous launch, in the LaunchServices database;
• matches with Yara rules in XProtect’s data;
• user consent to a first launch prompt dialog;
• launch and other constraints.

Additional data may also be collected and stored in the provenance database that first appeared in Ventura.

Not all checks are performed on every launch of an app. At a minimum, for a notarized app that has been run only recently, these might consist of only local checks against CDHashes and with the app’s existing entry in the LaunchServices database. Checks are also modified by reducing security settings:

• Disabling Gatekeeper checks doesn’t stop those checks from taking place, but apparently ignores some results, notably those obtained by XProtect. It doesn’t affect checks of CDHashes against Apple’s database.
• Disabling SIP has more pervasive effects in largely disabling the com.apple.syspolicy sub-system, affecting several layers, although checks of CDHashes against Apple’s database are unaffected.

com.apple.syspolicy

In full security conditions, one sub-system dominates log entries concerning app launch security, com.apple.syspolicy. This is clearest in Gatekeeper and XProtect checks. Although the log entries that follow may appear bewildering, they are the best illustration of this point.

When launching a notarized app that hasn’t previously been run on that Mac and has a quarantine xattr, Gatekeeper and XProtect scans are reported in the following sequence of entries:
com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>
com.apple.syspolicy.exec Skipping TCC check due to process: 692, 0, 692
com.apple.syspolicy.exec queueing up scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec starting work for scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec allowUI is YES, creating codeEval object: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec Adding default exception for team: <private>
com.apple.syspolicy.exec Registered app bundle for protection: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec GK performScan: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
com.apple.xprotect XProtectScan beginAnalysisWithResultsHandler continueOnError is set to 0
com.apple.xprotect XPAssessment performAnalysisOnFileImpl continueOnError set to 0
com.apple.xprotect Xprotect is performing a direct malware and dylib scan: <private>

Those checks later complete in entries such as:
com.apple.syspolicy.exec GK Xprotect results: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), XPScan: 0,-7676743164328624005,2024-08-26 08:19:01 +0000,(null)
com.apple.syspolicy.exec GK scan complete: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
com.apple.syspolicy.exec scan finished, waking up any waiters: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
com.apple.syspolicy.exec App gets first launch prompt because responsibility: <private>, <private>
com.apple.syspolicy.exec GK evaluateScanResult: 0, PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist), 1, 0, 1, 0, 4, 4, 0
com.apple.syspolicy.exec GK eval - was allowed: 1, show prompt: 1
com.apple.syspolicy.exec Skipping TCC check due to process: 692, 0, 692
com.apple.syspolicy Found console users: <private>
com.apple.syspolicy.exec Prompt shown (5, 0), waiting for response: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)

When SIP has been disabled, there are precious few entries from com.apple.syspolicy or com.apple.syspolicy.exec. Instead, XProtect appears to be left to its own devices, and doesn’t fare well:
com.apple.xprotect XPAssessment performAnalysisOnFileImpl continueOnError set to 0
com.apple.xprotect XprotectService Calling SecAssessmentCreate with URL <private>, context <private>
XprotectService SecTrustEvaluateIfNecessary
com.apple.xprotect XprotectService Bundle is not apple signed
com.apple.xprotect XprotectService Bundle size result: 18388222 (YES)
com.apple.xprotect XprotectService Always scan: YES
com.apple.xprotect XprotectService Starting malware scan for: <private>
kernel XprotectService [697] crossed memory high watermark (15 MB); EXC_RESOURCE
kernel Full corpse enqueued for XprotectService
com.apple.xnu memorystatus kernel kernel EXC_RESOURCE -> XprotectService[697] exceeded mem limit: ActiveSoft 15 MB (non-fatal)
ReportCrash event condition bump 0 -> 1
ReportCrash post-exception thread qos drop 21 -> 17
ReportCrash PID 697 exceeded the memory high watermark; Invoking ReportMemoryException with corpse.

There are no other entries referring to Gatekeeper or those checks. The effects of disabling SIP appear extensive and pervasive throughout several of the layers of app launch security.

CDHashes are central

With the adoption of notarization, apps run in macOS should now fall into one of five categories:

• signed by Apple, either its own apps or those delivered through its App Store;
• notarized by Apple, with its CDHashes added to Apple’s database;
• signed (either with a Developer certificate, or ad hoc) locally, and not distributed over the internet, with its own unique CDHashes;
• unwanted or malicious, with revoked CDHashes,
• unrecognised, and potentially malicious.

These emphasise the importance of the online ‘notarization’ checks of CDHashes performed in all circumstances where macOS doesn’t have previous records of saved CDHashes for that code. Their primary purpose isn’t to validate notarization, but to identify code as known good, known bad, or unknown. When Apple’s security engineers identify new malware, its CDHashes can quickly be added to the database as being revoked, so ensuring that all subsequent checks of the same CDHash will be classified as revoked, for malicious code. This is a rapid response that should have no false positives, in which benign code is mistakenly identified as being malicious.

Typically, the checking sequence is reported in the log with:
com.apple.syspolicy looking up ticket: <private>, 2, 1
com.apple.syspolicy cloudkit record fetch: <private>, <private>
com.apple.syspolicy cloudkit request cache info: <private>, max-age=300
com.apple.syspolicy CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
com.apple.syspolicy Inserting ticket: <private>
com.apple.syspolicy completing lookup: <private>, 0
[and so on with further lookups]
and those are among the only entries from com.apple.syspolicy seen when SIP is disabled.

When full security is enabled, those are completed with
com.apple.syspolicy.exec GK evaluateScanResult: 0, PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist), 1, 0, 1, 0, 4, 4, 0
But when SIP is disabled, those don’t appear, and seem to be substituted by application of Security rule 11 instead.

The downside of CDHash checks is that their false negative rate can be alarmingly high. Change a single bit in the code being hashed, and the hash will amplify that change, and is completely different. Hence the importance of notarization to establish which CDHashes definitely aren’t from malicious code.

One threat to this system occurs when a user mistakenly blocks their Mac from connecting to Apple’s database using CloudKit, for example using a misconfigured software firewall. Without a suitable vulnerability, malicious software shouldn’t be able to use this approach to block a payload from being checked.

I don’t know whether any third-party security products use a similar checking mechanism with their own local or remote CDHash databases, but this appears to be a great advantage to the protection built into macOS.

Performance

Two of the checks performed with full security enabled are dependent on the size of the app being checked. Fully validating an app’s CDHashes against those in its signature or notarization ticket should benefit from hardware acceleration, particularly on Apple silicon, and can be tackled hierarchically. It appears unlikely to result in significant delays to launching an app.

XProtect scans are more likely to be responsible for observable delays in app launch times, though. With the recent growth in the number of Yara rules, and their length, scans performed after an app’s first launch are the most probable cause of large and complex app bundles requiring several seconds before the app can be run.

Summary

I have updated the flow chart I first proposed as a result of observations made of app launches in Sonoma 14.4.1:

This is also available as a tear-out PDF here: launchsonomaapp2

I welcome any evidence that will refine and improve that, please.

Previous articles

Launching apps in Sonoma 14.6.1: Full security
Launching apps in Sonoma 14.6.1: Reduced security
Launching apps in Sonoma 14.6.1: Known malware
How does Sonoma check an app before launch? (Sonoma 14.4.1)