The list itself definitely lives in the OS base-image, so there’s a bit of a catch-22 there. (Imagine if it didn’t! That’d be a bit of an easy loophole for malware authors to exploit!)
I haven’t looked into it specifically, but I’m guessing that like many other basically-static system policy property-lists in macOS, the whitelist lives embedded in a Kernel Extension (kext)—probably the kext responsible for update validation. So you’d have to write your own kext to either replace that extension wholesale, or—hopefully—“inject” over just that element of it.
Of course, to run your own Kernel Extensions these days, you have to run your Mac in bputil --enable-kexts mode, which is “reduced security” from Apple’s perspective (reduced compared to the security model of iOS, they mean.)
On the other hand, the Hackintosh crowd have long agreed that it’s better to just “inject” data into the kernel/OS by either memory-patching the kernel during early boot (Clover), or patching the kernel as it’s being composed into a loadable image (OpenCore), rather than actually modifying anything in /System. (This was before modifying /System was even hard; they just didn’t like making a mess!)
I have a strong feeling that that same community that loves their little quality-of-life kext tweaks so very much, is pretty likely to come out with a way to use OpenCore as the boot-loader on real Apple-Silicon Macs, and thus to overlay arbitrary kexts into macOS without actually reducing macOS’s (OS-stage) security policy at all. (Provided you’re okay with the reduction in security of using a third-party bootloader, that is!)
I haven’t looked into it specifically, but I’m guessing that like many other basically-static system policy property-lists in macOS, the whitelist lives embedded in a Kernel Extension (kext)—probably the kext responsible for update validation. So you’d have to write your own kext to either replace that extension wholesale, or—hopefully—“inject” over just that element of it.
Of course, to run your own Kernel Extensions these days, you have to run your Mac in bputil --enable-kexts mode, which is “reduced security” from Apple’s perspective (reduced compared to the security model of iOS, they mean.)
On the other hand, the Hackintosh crowd have long agreed that it’s better to just “inject” data into the kernel/OS by either memory-patching the kernel during early boot (Clover), or patching the kernel as it’s being composed into a loadable image (OpenCore), rather than actually modifying anything in /System. (This was before modifying /System was even hard; they just didn’t like making a mess!)
I have a strong feeling that that same community that loves their little quality-of-life kext tweaks so very much, is pretty likely to come out with a way to use OpenCore as the boot-loader on real Apple-Silicon Macs, and thus to overlay arbitrary kexts into macOS without actually reducing macOS’s (OS-stage) security policy at all. (Provided you’re okay with the reduction in security of using a third-party bootloader, that is!)