Code Signing and Notarizing Open-Source unsigned binaries

How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple?

Is this a trick question?

Only submit code that you have written yourself and that you're 100% sure isn't malware. Note that this also includes code written by an AI.

Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing.

I don't understand this question.

But it's a moot point. While Apple doesn't publish the internal mechanism behind notarization, it should be easy enough to guess. It does a basic malware check against known signatures. It also records the submission for malware that might not be discovered until later.

Anything you submit, regardless of provenance, goes against your account.

I really don't want to risk termination of my Apple Developer account because it has many high-value applications available.

So what's the value of these open-source packages to you then?

You haven't specified what these packages actually do, which is a really important point. In many cases, the risk of supply-chain malware from an open source project is very low. If you're a heavy AI user, the risk from 3rd party code might even be less than the risk from your own, AI-generated code.

But in certain domains, the risk of malware is very, very high.

Which domain are you working in? I don't know.

I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation.

Nothing new here. It's always a risk/value trade off, eh? It's a little bit different in software development just because standard industry practices are typically the most risky ones imaginable. If everyone else is doing it, it must be correct, amiright?

Only submit code that you have written yourself

I won't expose the exact binary I am talking about, but would you say ffmpeg is something people write themselves?

It's also an unsigned, unnotarized binary download from their official website. Or you can build from source code. Exactly the same case with my binary.

So we can use ffmpeg as an example. How do I defend against embedding ffmpeg in my installer, getting supply chain attacked, and afterwards signing and notarizing some malware under my name?

I won't expose the exact binary I am talking about, but would you say ffmpeg is something people write themselves?

Sorry. I've been on the internet too long. If you ask for advice, I'm going to give you guaranteed, risk-free, correct advice. I don't want your lawyers showing up at my house with a lawsuit. I'm not making a joke here. There are people who will do this. I've already been targeted.

If you want to take a risk and import some multi-million line project made by thousands of anonymous people, that's on you.

Apple includes a substantial number of media APIs in its system SDKs. Use those instead of ffmpeg and there's nothing to worry about. As an added bonus, instead of notarizing, you can distribute on the App Store. And since Apple SDKs are cross-platform, you can target iOS too. That's my official advice.

So we can use ffmpeg as an example. How do I defend against embedding ffmpeg in my installer, getting supply chain attacked, and afterwards signing and notarizing some malware under my name?

ffmpeg isn't a great example. It's grey market, certainly. It's big enough to be ubiquitous, which makes it high risk. Obviously crypto or AI would be even higher risk. But it's still high risk.

You can't defend against it because you can't review all the code. All you can do is assume the risk and hope nothing bad happens.

There are ways to increase your risk. As I said earlier, you can follow industry-standard practices and keep your dependencies updated. That will ensure you always incorporate the newest, highest-risk code. Of course, that puts your code at higher risk for security exploits on the other end.

The older your dependencies, the more likely any malicious code would have already been discovered. The risk is never zero because "sleeper cell" malware is always possible. It isn't commonly used because leveraging those high-risk, industry-standard practices is so much easier and efficient.

I can't say anything that I didn't say before. It's a risk/value trade-off. But when I say value, I mean that in a material way. What are you going to gain from this project - financially? What's the point of even doing the math on the risk/value tradeoff when one of the variables is zero?