Hacker News Reader

Comment by trishankdatadog | Hacker News Reader

On a related note, we have built an E2E-verified, tamper-evident CI/CD pipeline for the Datadog Agent integrations [1]: the Agent will trust and install only integrations that correspond to source code that have signed by our developers. If there is an attack anywhere between our developers and end-users, it will be caught.

Unlike Binary Authorization for Borg, our security guarantees are publicly verifiable.

[1] https://www.datadoghq.com/blog/engineering/secure-publicatio...

View on HN

That's a bit of disingenuous reply...

Binary Authorization for Borg is for verifying binaries running inside Google, not code installed on end-user machines. Having the authorization be "publicly verifiable" makes no sense.

Publicly verifiable is a (stronger) superset of privately verifiable

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.

in-toto.io also addresses the "proof it went through some steps". How would you compare the two systems?

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.

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

I saw this before and meant to post about it, because it's really neat.

Thanks, Thomas!

Reply on news.ycombinator.com