It's more a defense against getting NSA'd (via the specific threat model of an attacker secretly replacing a security service with an implementation that looks very similar but is much easier to crack).
I think that's right. I would strengthen that statement slightly - it's about ensuring that no actor - whether an insider, or someone who has stolen their credentials, or otherwise compromised them - can perform an action that single handedly accesses user data, without it being known to another actor - via access logs, via approvals, etc.
In terms of the upstream introduction of a new vulnerability, Binary Authorization for Borg can only verify that the code was in fact merged. See the section on third party code, "When importing changes from third party or open source code, we verify that the change is appropriate (for example, the latest version)."
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.
You might not think that's much of a guarantee, but it beats the alternative where things happen due to shadow processes.