Eight months ago I wrote an article about the true and false security benefits of Mac app notarization, in which I argued that the publicly touted benefits of notarization — revocation and malware scans — are bunk, but there was one true benefit — two-factor authentication. Now I must admit that I was wrong.
I wasn't wrong that the publicly touted benefit are bunk. Rather, I was wrong that there's a true benefit. It turns out that notarization does not in fact provide real 2FA to Mac app developers, and thus there are no benefits at all to Mac app notarization. It's entirely security theater.
In my previous article I claimed that notarization protects your Developer ID certificate from unauthorized use, because once your app is signed with the certificate, it also has to be uploaded to Apple's notary service using your Apple developer account, which itself requires 2FA. Consequently, unauthorized distribution would require compromise of both your Developer ID certificate and your developer account, and you would still receive email notification of any notarization performed with your account, or indeed any changes whatsoever to your account, including change of the email address associated with the account. Nobody can notarize an app using your account without your knowledge.
My mistake was assuming that a Mac app signed with your Developer ID certificate would have to be notarized with your Apple developer account. However, this does not appear to be required. A few days ago, Apple published their new Platform Security Guide. There's a very interesting paragraph in the section App code signing process in macOS:
On macOS, code signing and notarization work independently—and can be performed by different actors—for different goals. Code signing is performed by the developer using their Developer ID certificate (issued by Apple), and verification of this signature proves to the user that a developer's software hasn't been tampered with since the developer built and signed it. Notarization can be performed by anyone in the software distribution chain and proves that Apple has been provided a copy of the code to check for malware and no known malware was found. The output of Notarization is a ticket, which is stored on Apple servers and can be optionally stapled to the app (by anyone) without invalidating the signature of the developer.
It seems that anyone with an Apple developer account can notarize any signed Mac app, even if the signer and the notarizer have no knowledge of each other. I believe this happened to a developer friend of mine. Uploading an app to Apple for notarization requires an active developer account, but my friend's account had lapsed. Maintaining an Apple developer account costs $99 USD plus tax every year, which can be a burden for developers who distribute free apps. DevID signing certs, on the other hand, last for years before they expire. My personal DevID Application signing cert expires in 2021, while my Dev ID Installer signing cert expires in 2024 (I renewed the certs at different times). Thus, you can continue to sign Mac apps with a non-expired cert even after your Apple developer account membership expires. My friend's signed app was notarized somehow, despite the lapsed developer account, and we have no idea who notarized it. There's no way for us to find out who notarized the app. We suspect that a user of the app notarized it in order to run it on macOS Catalina.
You don't even have to be a developer to obtain the "ticket" of a notarized app. When you first launch an app, macOS "phones home" to Apple to check for a notarization ticket. It's available to everyone. Once you have the ticket, you can "staple" it to the app for distribution. A stapled ticket isn't required for distribution, but it helps in the case where the user has no internet connection and thus cannot phone home to check the notarization status. You need an active developer account to notarize an app, but you don't need one to staple an app.
It's unclear why the notarization requirements are so lax, and whether that will change in the future. I'd say that Apple should publicly comment on this, but that's a false hope. Apple almost never explains itself on these matters. We developers are as much in the dark as everyone else.