Agreed with this statement.
It's a best practice generally to verify all software updates originate from a particular source before applying them in your environment. Most over the wire updates do this.
What's different with Binary Authorization for Borg is that within Google, that last verification step means more than just "came from Google", but "came from Google and went through all previous necessary checks", because of the way the CI/CD system works together.
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.
I am perfectly aware that Binary Authorization for Borg is for binaries running inside Google.
I am saying that our solution provides almost the opposite: publicly-verifiable assurance that you are running legitimate binaries, despite being built by automation
The biggest difference for me is that in-toto allows you to define any set of upstream metadata requirements, in a very open format, and Binary Authorization has a set of centrally defined requirements, that teams tend to implement in tranches, to meet minimum requirements. It may sound better to have a freeform format, but in practice, I've found that it makes it harder for people to know what they should actually do.
In Binary Authorization for Borg, services still define service-specific policies, but pick from a previously defined set of potential requirements. See the section on service-specific policies: https://cloud.google.com/security/binary-authorization-for-b...
You can more easily compare Grafeas and Kritis (OSS projects Google developed, which are similar to GCR Vulnerability Scanning and Binary Authorization for GKE), to in-toto. In fact, I gave a talk covering some of the options for this here: https://youtu.be/uDWXKKEO8NU?t=1314
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.