Also, all you need is one insider kernel developer to get all the source code anyways. I always find these kinds of initiatives silly -- A lot of companies think that an insider is a side-channel attack when really it's the main vector.
Yah, I've had this discussion numerous times. Especially with regard to hiring people from a competitor. Often you wonder how much information is traveling via unintentional side channels (not just employees that are also on the payroll of a 3 letter agency).
OTOH, there does seem to be a fair amount of competence where it matters though. In the couple companies I worked for the private keys used for signing things were very quietly kept hidden from the vast majority of the engineering teams/etc. AKA, it was possible to create an development/test builds all day long, but creating valid license keys/firmware updates/etc for the builds given to customers was limited to a formal process which contained the keys. The private keys were only available to a couple people tasked with maintaining the automation from which the builds/keys/etc came from. Those people rarely had a need to move/etc them either, and such activities were done in the open.
That is, unfortunately, by no means "all the source code" of the kernel-level code that is running on your Mac, iPhone, iPad, iPod, Apple TV, or Apple Watch.
Also, given enough money available, why ask people to build vulnerabilities in ? Does anyone seriously think Apple's (or anyone's) kernel team doesn't have a single guy/girl that made at least one mistake ?
And Apple, as well as Microsoft, Intel, and other companies have already voluntarily agreed to give the NSA and other agencies "early notice" of a vulnerability which can be exploited by the time it's fixed anyway. CISA also pretty much mandated it into law as well.
Or perhaps the three-letter-agencies demanded they do such a backdoor (i.e. a deliberate but obscure security hole), so they are open-sourcing it so hackers can find it.
I know that. But who knows how much secret sauce they have in the iOS build?
Also, even on OS X, it takes a while after new versions of the OS are released for new kernel source bundles to drop. So sometimes poking around with IDA is your only recourse.
A non-trivial amount of the iOS platform has been rev-eng'd (incidentally, largely with IDA and those kernel sources to create binaries with intact symbols + binary comparison heuristics[1]). XNU is largely based on FreeBSD so I'd be surprised if that wasn't an additional vehicle people were using (In a similar vein, fail0verflow used the syscode table information from FreeBSD with WebKit and ROPgadgets to fully compromise the PS3.)
Apple continues to open source their version of XNU, although there has been an increasing lag between the release of each OS version and the corresponding sources. The latest available sources are from 10.11.2, three minor versions behind.
Apple has also shifted to pushing a lot of sensitive/proprietary code into kernel extensions (the new Apple File System being one example), for which they don't release source code (generally speaking).
Filesystems, by and large, are supposed to be pushed into the kernel (via extension, or direct compilation). I'd hardly say that they've "shifted" into pushing code into their kernel, but that much of what differentiates Apple's XNU kernel vs FreeBSD's Kernel or Linux is what they choose the exclude.
That's an interesting point of view that I hadn't considered before. Apple (or any company) doesn't have infinite eyeballs and can't possibly inspect every nuance to their systems. So, you release it to the world and have them surface any issues. If there are no trade secrets and everyone is honest and reliable, then it is a great way to increase your security footprint. :)