Apple security releases - Apple Support shows last updates, related to security, since May and June of this year. :O
I imagine that we’ll see the x.6 releases of all the operating systems fairly soon, with a large selection of security updates. I presume none have been zero-day vulnerabilities that required a quick response from Apple.
That list is for OS updates with security fixes. There is more to security updates. In particular updates to XProtect which are done without interaction from the user/administrator - they are silent.
Howard Oakley keeps track of XProtect updates - start here Search Results for “xprotect” – The Eclectic Light Company Three updates already in July.
I would say Apple is quiet (unless you listen hard), but active with security updates.
1 Like
Details of some of what is going on are in the links I recently added to macOS, diskarbitrationd.
As well as patching system vulnerabilities, much of the work on macOS 15 seems to be fixing bugs in macOS which have long been known, especially in Intel code. It occurs to me that more fully debugging macOS (Intel) may be background which enables M-series Apple Silicon advances.
Years ago iOS was created as a single-user fork of the OS X/macOS variant of BSD UNIX, with security, stability, reduced code size, and battery-saving reduced compute overhead being driving virtues. Complementing these software advances, Apple moved iOS onto the newly created Apple Silicon A series. The complex A series SOC (System On a Chip) was the incarnation in silicon of iOS.
Encoding in silicon seriously hardwires software. For this to work, economically as well as by other criteria, the software model which becomes siliconized must be as close to free of bugs as possible. The success of Apple’s A series processors, and the products they enable, reflects the stability and lack of error in the simplified iOS branch of macOS on which this Apple silicon is based.
Similarly, the software basis for Apple’s M series processors is the much more complex multi-user, multi-processor, multi-much more many other things, macOS. As Apple Computer became Apple (“the iPhone company”), many of us were dismayed as more and more bugs accumulated in the neglected macOS. When the iPhone company returned to encode the full UNIX macOS system in M-series silicon, its SOC expertise developed creating the A series based on iOS indicated bugs in macOS on which the M chips would be based would be a serious liability. Software work-arounds for bugs immortalized by encoding in silicon reduce compute efficiency as well as economic viability.
I think Apple’s recent (last several years?) focus on debugging macOS is driven by the newly recognized need for software model which is as bug-free as possible on which to base M-series silicon. Debugging and hardening against intrusion can be done much more efficiently and economically in software than in silicon. Though requiring considerable resources, and critically important for the future of Apple, none of this work is suitable for promotion in glossy retail advertisements. I suspect this explains at least a part of why Apple is quiet with its security, and bug fix, updates these days.
There is a wealth of great information and useful apps at Howard’s site (eclecticlight.co). His apps are all free and I particularly like Skint, which allows one to quickly check whether Xprotect and Xprotect Remediator are up to date and operational. Also good is Silentknight which provides more detail.
1 Like
Definitely correct, but note that the A series processors do not have iOS “encoded in silicon”. iOS, like macOS, is software installed to flash storage, and is replaced when the system updates.
Now, there are capabilities that are hard-coded in silicon (e.g. the encryption APIs that comprise the secure element), and those must be extremely thoroughly tested, because it may not be possible to fix bugs without replacing chips.
But that is a very small part of the overall system, which is closer to a Mac than it may seem to you.
1 Like
Resource: the official US repository for security alerts is here:
And its email listserv is here:
https://public.govdelivery.com/accounts/USDHSCISA/subscriber/new?qsp=CODE_RED
One way CISA alert information can be used is to know when an Apple vulnerability is identified and whether a fix is immediately available without relying on Apple to make an announcement.
Thank you for your comment. My thoughts are based on a high-level understanding of code, with relatively little knowledge of underlying details. What I think is particularly relevant is that macOS and all its derivatives are BSD UNIX modified into an Object Oriented form. My understanding is this began, at least as relevant to Apple, when Avie Tevenian’s doctoral thesis at CMU became the kernel for NextStep, which eventually morphed into today’s macOS. In 1984, after I bought a 128k Macintosh, my first home computer, I realized the FORTRAN IV I knew (sort of) would be insufficient, so I taught myself “the native programming language of the Macintosh,” Object Pascal. And a lot more. But I was busy with other things and could not keep up. Point is at one time I knew this stuff in more detail. Even though I am grossly out of date on current implementations, I think the general principles still apply. My current understanding is admittedly at a very general level, so I hope more knowledgable readers will correct and/or add to my comments as appropriate.
The strength and weakness of OS X have always been its modifications to conform to the Object Oriented paradigm. OO programming involves local encapsulation in software objects of variables and methods, with message passing between the objects to construct larger calculations. Organization of objects into larger constructs, as well as message passing between the objects, are functions of the kernel. This would included the APIs mentioned by Shamino. I suspect also many of the software objects with which these APIs interact. In the past the compute overhead of this form of organization has led to longer response times, making Macs less competitive for games, for example. Now, by keeping as much as possible on chip, Apple silicon as well as enabling much more efficient basic calculations greatly speeds up message passing and other kernel functions.
The first major target for Apple silicon was iOS, the OS X variant greatly simplified by stripping out multiuser and multi-other things (processors? …), which the A series processors enable. Now with that successful experience for guidance, Apple is working out the M series with much more complex kernel functions required to support the much more complex multiuser, multi-all kinds of things, macOS. And along a slightly different line, the super fast response R series (kernel highly optimized message passing?). Fast response as needed to support computing in real time has many applications beyond Apple Vision Pro and the Apple Car.
The gist of my original point was that designing and creating highly optimized Apple silicon processors is probably less reliable when the software used for quality control is itself of low reliability. That makes very thorough debugging of macOS critically important for the future of Apple.
I think this explains why so many of the “new features” these days are bug fixes and security enhancements which are very nearly unnoticeable. Except to users such as myself, for whom bugs which are known bug left unfixed have, for a long time, made many computer functions close to unusable.