What is macOS Ventura doing tracking provenance?

A few days ago, I revealed details of a new extended attribute (xattr) apparently involved in security and Gatekeeper assessment of apps in macOS Ventura. This article updates that announcement with some more details, specifically of how Ventura is starting to track quarantine history of apps.

The story so far

macOS 13 has introduced a new xattr named com.apple.provenance, which it attaches to apps when they clear quarantine. It contains binary data, including an 8-byte integer that is that app’s primary key in the provenance_tracking table in /var/db/SystemPolicyConfiguration/ExecPolicy, which also stores the app’s cdhash and other information about it.

So far, this provenance xattr has varied considerably in the way that it’s applied. Earlier in Ventura, it has been applied to every single file within an app bundle, but currently is only added to the .app folder. It has also at times been protected, possibly by SIP or by TCC, although as of macOS 13.2.1 it appears to be unprotected. There are sporadic reports of apparent errors, in which the xattr has been applied to other files outside app bundles, and one instance of a xattr that ended up with an additional 4085 bytes of trailing zero padding in its data.

Creating the xattr

The best opportunity to observe the provenance xattr being created and attached to an app is when it clears quarantine, having had a com.apple.quarantine xattr attached as a result of being downloaded from the internet. In this example, I’ll show what happened to my app Nalaprop in a lightweight VM.

As the app was in quarantine, it underwent an XProtect scan, notarization check with api.apple-cloudkit.com, and an OCSP check for the validity of its signing certificate at ocsp2.apple.com. The latter appeared particularly thorough.

App launch started at just over 1 second elapsed:
1.008060 LaunchServices LAUNCH: Opening file:///Applications/Nalaprop.app/ with 0 items on behalf of 405 role=e flags=8000001 (null)

The Gatekeeper scan was complete just over 0.4 seconds later, and because this was the app’s first run with quarantine enabled, the user was notified with the standard dialog:
1.421598 syspolicyd GK scan complete: PST: (path: /Applications/Nalaprop.app), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
1.421902 syspolicyd App gets first launch prompt because responsibility: /Applications/Nalaprop.app/Contents/MacOS/Nalaprop, /Applications/Nalaprop.app
1.421906 syspolicyd GK evaluateScanResult: 0, PST: (path: /Applications/Nalaprop.app), (team: QWY4LRW926), (id: co.eclecticlight.Nalaprop), (bundle_id: co.eclecticlight.Nalaprop), 1, 0, 1, 0, 4, 4, 0
1.422836 syspolicyd GK eval - was allowed: 1, show prompt: 1

Following user acceptance of the app, its provenance data were created and written to the xattr attached to the .app folder:
3.181571 syspolicyd Created provenance data for target: TA(c313f6185de3d3ea, 0), PST: (path: /Applications/Nalaprop.app), (team: QWY4LRW926), (id: co.eclecticlight.Nalaprop), (bundle_id: co.eclecticlight.Nalaprop)
3.181577 syspolicyd Handling provenance root: TA(c313f6185de3d3ea, 0)
3.181640 syspolicyd Wrote provenance data on target: TA(c313f6185de3d3ea, 0), PST: (path: /Applications/Nalaprop.app), (team: QWY4LRW926), (id: co.eclecticlight.Nalaprop), (bundle_id: co.eclecticlight.Nalaprop)

Once the xattr was attached, the app was entered into the provenance_tracking table in /var/db/SystemPolicyConfiguration/ExecPolicy:
3.181654 syspolicyd Putting executable into provenance with metadata: TA(c313f6185de3d3ea, 0)
3.181656 syspolicyd Putting process into provenance tracking with metadata: 746, TA(c313f6185de3d3ea, 0)
3.181658 syspolicyd Tracking process with attributes: 746, TA(c313f6185de3d3ea, 0)

Although an attractive idea, the TA value shown of c313f6185de3d3ea sadly didn’t correspond to the binary provenance data.

The end result was the .app folder with its provenance xattr, which wasn’t protected by SIP or TCC, and a corresponding entry in the ExecPolicy database, enabling macOS to track the app’s provenance.

Using provenance

Because of the caching of trust and LaunchServices data, running that same app a second time a few minutes after it had completed its first run resulted in no Gatekeeper checks being repeated, and no attempt was made to access its provenance data.

Running another app, SilentKnight, which had completed Gatekeeper checks previously and had a provenance xattr attached, triggered a fuller set of checks, including an XProtect scan, notarization lookup, and OCSP checks, although the latter didn’t appear to be as extensive as those performed on a quarantined app.

In this case, app launch started at almost 1.1 seconds elapsed:
1.089083 LaunchServices LAUNCH: Opening file:///Applications/SilentKnight.app/ with 0 items on behalf of 377 role=e flags=8000001 (null)

The Gatekeeper scan was completed 0.4 seconds later:
1.484682 syspolicyd GK scan complete: PST: (path: /Applications/SilentKnight.app), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
by which time there had been no mention of provenance data in the log. That didn’t occur until after the scan had completed:
1.502739 syspolicyd Found provenance data on target: TA(e7115e5d49cf1f82, 0), PST: (path: /Applications/SilentKnight.app), (team: QWY4LRW926), (id: co.eclecticlight.SilentKnight), (bundle_id: co.eclecticlight.SilentKnight)
following which the policy evaluation result was announced:
1.502898 AppleSystemPolicy evaluation result: 1, allowed, cache, 1678266301

It’s surprising that macOS didn’t appear to check the provenance xattr on this app until after the Gatekeeper scan was complete. Neither had there been any reference to the TA number given, or an entry indicating comparison of cdhash values stored in the ExecPolicy database for that app.


While it’s clear that macOS Ventura is now tracking the provenance of apps that have completed their first run with the quarantine flag set, this provenance tracking doesn’t (yet) appear to be used to tailor or modify the checks run by Gatekeeper. It’s possible that provenance tracking isn’t yet mature enough to be used for that purpose, or that it’s intended for something else. Perhaps Ventura 13.3 will reveal more.

I’m very grateful to Randy Saldinger of Mothers Ruin and Pico, who have contributed substantially to the information above.