To address the security concerns - All code should require manual review from at least one other person (some orgs require 2+). It should be impossible to intr

To address the security concerns - All code should require manual review from at least one other person (some orgs require 2+). It should be impossible to introduce a code change to any code base with a single compromised developer account. This is true of mono or multi repo - The only really dangerous shit (like private keys, admin credentials) should not be accessible or committed to repos at all, ever. - I've never worked anywhere where a source code leak was a legitimate threat (note: not that it wasn't a concern, just that it doesn't normally have drastic consequences, your code isn't as special as you think) - I have worked places with silo'd repos with granular access and I won't do that again, I ask about it in technical interviews and if your company is doing this it's not really a positive - making it harder for engineers to get work done for bad reasons is a sure fire way to get a toxic engineering culture. There's plenty of places that give us engineers access to everything in the meanwhile. So to me I don't see the utility of multi repo from a security perspective - I'd argue the infrastructure problem it solves is the same as a package manager (having portions of systems moving at different rates without breaking dependent systems). If you have this problem in your code base then a multi repo org makes a lot of sense.