How does Ventura check an app’s security?

A couple of days ago I explained that Ventura checks apps more thoroughly than before. This article shows how it does that, according to what it records in the log.

Security checks made when an app is launched still depend on several factors. A set quarantine flag results in full first-run checks including app translocation and is atypical. To see a more representative process, I’ve looked at notarized apps being run for the first time without quarantine. As these apps had never been run in that VM before, security systems had no prior knowledge of them, and couldn’t make use of existing entries in the security database or cached information.

This account gives brief extracts from many thousands of log entries. In particular, the two remote connections involve long exchanges that are recorded across hundreds of transactions. Privacy protection was removed from the log for this purpose, and full network diagnostics were enabled. If you try to follow this along on another Mac, you may therefore not see the same amount of detail.


In this case, running my app Cormorant from the main Applications folder, the action to open the app was recorded at almost exactly 1.009 seconds elapsed. First announcement was made by LaunchServices
1.016423 LaunchServices LAUNCH: Opening file:///Applications/ with 0 items on behalf of 377 role=e flags=8000001 (null)
where process 377 is the Finder.

Entries then report that the app bundle needs to be set as trusted so it can be launched, and LaunchServices looks for any plugins and extensions. A bundle record is then built for the app in the LaunchServices database by parsing its Info.plist, and once that’s complete the app is registered there as being trusted. LaunchServices then hands over launching the app to RunningBoard, which manages it and the resources available to it.


As that’s going ahead, Apple Mobile File Integrity (AMFI) initiates security checks
1.051891 amfid Entering OSX path for /Applications/
and calls Security to perform a trust evaluation if necessary, then stated as
Requested evaluation with only soft restricted entitlements, but no soft restricted entitlements found


syspolicyd then initiates the Gatekeeper (GK) assessment
1.064942 syspolicyd GK process assessment: /Applications/ >-- (/sbin/launchd, /Applications/
1.064988 syspolicyd Gatekeeper assessment rooted at: /Applications/

and starts with a scan of the app bundles for code
1.065387 syspolicyd starting work for scan for code: PST: (path: /Applications/, (team: (null)), (id: (null)), (bundle_id: (null))


The first step in that is to add a default exception for the team of the code-signing certificate, following which the app bundle is registered for protection, Gatekeeper scans the app bundle, and XProtect is called to perform a direct malware and dylib scan
1.068594 Xprotect is performing a direct malware and dylib scan: /Applications/
This is one of very few explicit mentions of XProtect and its service in the log.

Note that this XProtect isn’t the background scanner XProtect Remediator, but the longer-established service that performs on-demand scans to detect malware using compiled Yara signatures. In Ventura, those scans occur whenever an app or executable code is to be run, although in earlier macOS they were only performed in app first-run when a quarantine flag was set.


Next the notarization ticket is checked. As this is here stapled to the app bundle, it can be looked up directly with Apple’s service via iCloud at https: // This is performed through CFNetwork with TLS
1.078226 cloudkit record fetch: https: //, 2/2/f382b9b4ade8395e9c08e541d8bcd969a8d4c63e
1.078244 cloudkit request cache info:, max-age=300

This is thought to involve checking of cryptographic hashes to verify the notarization and the integrity of the app bundle. Note that this is being run in a VM which has no Apple ID and no iCloud sign-in, and is an example of an iCloud service that is used by all Macs regardless of whether they’re signed into iCloud.

Apple declares with TCP on port 443 as one of its required network services, for notarization checks.

As that’s completing, XProtect results come in and are recorded by syspolicyd.


The second remote connection made from within Gatekeeper’s processes checks the code signing certificate with Apple’s OCSP service. This is now performed with TLS:
1.246623 Network [C2 9700F665-9EB7-411B-B539-3B9DB847CC23 quic-connection, url hash: 58998593, definite, attribution: developer, context:{56391B2B-1A5B-451E-B726-A38553FA22CD}{(null)}{Y}{2} (private), proc: AFEBD0C4-9C35-30CE-9D1F-861ECE4EB6B7, effective proc: 2E7AA7E7-714F-319B-81B4-0EB2CA5E0930, pid: 208, uid: 0, account id:] start
1.247014 mDNSResponder [R175] getaddrinfo start -- flags: 0xC000D000, ifindex: 0, protocols: 0, hostname:, options: 0x8 {use-failover}, client pid: 182 (trustd), delegator pid: 208 (syspolicyd)

This has been the most controversial phase of Gatekeeper checks since it was discovered in 2020 that those checks were being made using plain HTTP rather than HTTPS. At the time, Apple made an undertaking that it would improve the reliability of its OCSP servers, would adopt a secure means of communicating with them, and would provide users with an option allowing them to turn off these checks altogether. That promise remains visible today, at the end of this article, but Apple still hasn’t fulfilled the last of those promises.

Apple declares with TCP on port 443 as one of its required network services, for certificate checks.

Gatekeeper complete

With that check complete, syspolicyd declares the Gatekeeper scan complete
1.352375 syspolicyd GK scan complete: PST: (path: /Applications/, (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
which is then confirmed with the kernel
1.367333 kernel AppleSystemPolicy evaluation result: 3, allowed, cache, 1678266601

Finally, nearly half a second after the user first started its launch process, Cormorant gets under way, loading its preference settings
1.476026 Cormorant CoreFoundation Loading Preferences From User CFPrefsD
then running its code.


Although Ventura still completes Gatekeeper checks on every app launch now, once an app has been entered into the LaunchServices and security databases, some of the tasks completed here can be omitted for subsequent runs. Certificate validations using OCSP are cached locally, reducing the frequency of online checks. However, as tests demonstrate, checks for malware using XProtect and for code integrity are now universal.