Patched, and Still Blind: Why a Mac Fleet Cannot Tell You If You Were Hit First

A patch is a claim about the future: from the moment it lands, the hole is shut. It says nothing about the weeks the hole was open, and the only artefacts that can speak to that period are access records generated before deployment - which, on a Mac estate, exist by default and by default stay somewhere nobody investigating can query them.

Apple's Unified Logging is available in macOS 10.12 or later and, in the words of Jamf's own administrator documentation, "provides a central location to store log data on the Mac" ^[1]. That sentence is worth reading slowly, because the word doing the work is not "central" but "on the Mac". Nothing here is about a specific advisory; the material in front of me documents the collection mechanism and the pressure on remediation queues, and those two things are enough to explain why the post-patch question so often goes unanswered.

What "central" means when the vendor says it

The documented consumers of unified log data are the Console and Terminal apps, which let users view, stream and filter it on computers in order to troubleshoot errors or detect threats manually ^[2]. That is a per-machine, interactive activity performed by a person at a keyboard. It is a good fit for the question "why did this laptop misbehave this morning" and a poor fit for the question a security team actually asks after a late patch, which is asked once, retrospectively, about a date range, across an entire fleet.

Getting to a fleet answer requires a second system. Jamf Protect uses the same predicate-based filter criteria commonly used with the `log` command to collect relevant log entries from computers and forward them to a SIEM ^[3]. The documentation is blunt about the dependency: to use the feature at all, you must have integrated Jamf Protect with a SIEM, with a separate section for organisations running Splunk ^[4]. So three conditions must already be true before a single unified log entry on a Mac is searchable from outside that Mac: a SIEM integration exists, somebody has authored a predicate, and that predicate has been saved as a filter ^[17]. Each is a project. None of them is created by the incident that makes you want them.

Filters only ever look forward

The administrative flow is short: open Unified Logging in Jamf Protect, add a new filter, name it, optionally tag it, paste the predicate, save - after which, per the documentation, "All computers will now send logs that match your filter" to the SIEM ^[5]. Note the tense. The documented behaviour is that matching logs flow after the filter is saved, and the guide describes no retrospective query, no fetch-from-device and no backfill of entries already written on the endpoint ^[18].

That is the whole asymmetry in one line. Deployment of a fix is a push you can complete this week for events that have not happened yet. Determining whether the vulnerability was used before the fix is a pull against data you either forwarded at the time or did not - and forwarding was governed by predicates written before anyone knew which access path would matter. The set of questions you can answer about last month is fixed by the filter list you had last month.

The predicate is the entire control, and it fails quietly

The documented method for building one shows how narrow these things are. You open Console, search keywords relevant to the logs you want, then analyse and refine until only relevant entries are displayed ^[6]. Jamf's worked example is AirDrop: to isolate outbound transfers specifically, you send a file and search for its name, and the returned entries expose the underlying criteria - process "sharingd", subsystem "com.apple.sharingd", with both messages beginning "startSending" ^[7]. The resulting predicate stacks five conditions: process, subsystem, category, a `composedMessage BEGINSWITH[cd]` prefix match, and `logType='info'` ^[8].

Five conditions, all of which must be right, none of which announces itself when it is wrong. The documentation supplies its own demonstration of the hazard: the discovery step reports the subsystem as "com.apple.sharingd", while the example predicate written from it reads `subsystem = 'com.apple.sharing'` - a one-character difference between the observed value and the filter built to catch it ^[19]. A predicate with that defect does not error. It matches nothing, forwards nothing, and looks from the SIEM side exactly like a fleet on which no AirDrop transfers occurred.

Two other details in the same page exist for the same reason. There is an optional verification step - run `log stream` with your predicate in Terminal, perform an action that should generate a matching entry, and confirm the entry appears ^[9] - which is only "optional" in the sense that skipping it is permitted, not in the sense that skipping it is safe. And there is a note that only the predicate itself goes into Jamf Protect, without the `log` command and `--predicate` flag used during testing ^[10]. Both warnings describe the same failure mode: a silent zero. The supported keys are enumerated by `log help predicates`, which is to say the vocabulary is large and the burden of choosing from it sits with the administrator ^[11].

Multiply that by every access path you might one day need to prove or disprove. Each is a separate predicate, ideally each individually tested, each carrying an ingest cost from the moment it is saved.

The inflow side of the same problem

The reason this bites more often is on the remediation queue, and here the supplied evidence is framing rather than arithmetic. ActiveState surveyed 300 security and engineering leaders across technology, financial services, healthcare, manufacturing and government ^[12], and describes AI coding tools as a rapidly growing source of unvetted open source in production, leaving teams with packages they did not approve, vulnerabilities they do not know how to prioritise, and exposure they cannot control ^[13]. The company says its research quantifies the acceleration of remediation backlogs and maps that to liability and business outcomes ^[14].

Says. The supplied material discloses no figure other than the sample size: not one backlog measurement, not one prioritisation statistic ^[16]. This is a vendor webinar page, and the second half is ActiveState's Rebecca Banks and Moris Chen ^[15], so the appropriate posture is to take the shape of the claim seriously and wait for the methodology.

The shape does matter, though. If unvetted dependencies keep arriving unapproved while backlogs accelerate against remediation capacity that is not growing at the same rate, the average gap between disclosure and deployment per item widens, and "we patched it, but was it used first" becomes a routine question rather than an exceptional one ^[20]. And the most useful line on that page is Banks and Chen's own framing: which approaches mitigate remediation burden, and which ones might just redistribute it ^[15]. Unified log forwarding is a candidate for the second category. A broad predicate that ships everything vaguely relevant to a SIEM does not reduce anyone's workload; it moves cost from the endpoint to ingest volume and to whoever reads the results, and it still only covers the access paths somebody thought of in advance.

What to watch

Three things are checkable without procuring anything. First, whether the SIEM integration Jamf lists as a hard requirement actually exists and is receiving data, because without it the Unified Logging panel is decorative ^[4]. Second, whether the saved filter list contains predicates for the access paths that would matter after a late patch, and whether each was confirmed with the `log stream` verification the vendor documents as optional ^[9]. Third, whether the subsystem and process strings in those saved predicates match what Console reports today, given that the vendor's own published example does not ^[19].

The floor beneath all of it is fleet OS version, since unified logging is a macOS 10.12-or-later facility ^[1]. And on the inflow side, the number to wait for is a published ActiveState figure with a stated method behind it, rather than a registration page asserting that backlogs are accelerating ^[14][16]. Until then, the honest statement to put in an incident review is not that nothing happened before the patch. It is that no filter existed that would have shown it.