4 ms·

https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html https://security.googleblog.com/2021/02/know-prevent-fix-fra... At Google,

by mavhc 6y ago

https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html https://security.googleblog.com/2021/02/know-prevent-fix-fra... At Google, we have those resources and go to extraordinary lengths to manage the open source packages we use—including keeping a private repo of all open source packages we use internally

0xbadcafebee 6y ago
That's more for availability than security. Assuming you keep the crypto checksums / author signatures of all the source code and packages, you don't need to keep a copy of the source / packages. Just verify them at download time. Many Linux distros don't even have a copy of all those binaries, they rely on HTTP mirrors of random organizations. It's also useful for your organization to rebuild all of the source code from scratch (for reproducible packages anyway) and compare the new ones to the old ones, looking for things like compiler or hardware injection attacks. Secure build systems are definitely non-trivial.
- actuator 6y ago
  One more advantage of keeping it together can be easier development cycle. IDE features like autocompletion and building would be faster if artifacts can be cached.
  - lrem 6y ago
    My Vim is indeed magic. I start typing in a name and it autocompletes, then adds includes for whatever the package the thing I just used is in. I also can't imagine going back to not having code search, with its turning every identifier into a link.
- zaphar 6y ago
  It's not just that. Because it's all in the same repo and built with the same build tool it's also easier to run the same security checks you would use for your own code all automatically as part of your build process. All the tooling you use to secure your own code can be used to secure third party code as well with the same low level of friction.
- rrdharan 6y ago
  Google has a whitepaper on exactly how this works and the security aspects of the verifiable build system: https://cloud.google.com/security/binary-authorization-for-borg https://cloud.google.com/security/binary-authorization-for-b...
actuator 6y ago
But Google is more or less an exception in this regard, from hiring their own offensive penetration testing teams to having a lot of paranoia in general about anything from outside. They had adopted a lot of good practices early on. Even most big companies are not as thorough as them. I wonder how they built this culture and if it is even realistic for smaller companies to aim for it.
- ftio 6y ago
  I work on developer infrastructure at Google. Opinions my own. I think it typically comes down to a few key leaders having the political capital/will to enforce policies like this. Google's `third_party` policies[0] were created relatively early on and were, as far as I understand, supported by high level technical leaders. The ROI of policies like these is not always immediately evident, so you need the faith of key leaders in order to make room for them. Those leaders don't necessarily need to be high in the org chart — they just need to be respected by folks high in the org chart. As a counterfactual, establishing Google's strong testing culture seems to have been a mostly bottoms-up affair. Good article on the history of that at Mike Bland's blog[1]. 0. https://opensource.google/docs/thirdparty/ https://opensource.google/docs/thirdparty/ 1. https://mike-bland.com/2011/09/27/testing-grouplet.html https://mike-bland.com/2011/09/27/testing-grouplet.html
- tetraodonpuffer 6y ago
  At a previous job I pushed hard for this in a project I was responsible for, despite initial buy-in as time went on there was a consistent level of pushback about relaxing this requirement and allowing just importing anything ( the architecture of this was basically a separate repo storing ALL the dependencies where only a couple of people had commit access and where new dependencies were allowed after vetting ) Fortunately there was a hard legal requirement to vet every dependency license, otherwise I am not sure I would have been able to keep this workflow. As other posts say you do need a very strong commitment at the management level for this to work, besides security (where it feels that often it matters only until it costs money or until it’s even slightly inconvenient) it might be helpful to make a legal case (what if we ship something with a nested dependency on AGPL ) to get some help to establish these procedures. I have been writing and architecting security related software for pretty much all my career and I find it quite scary how these days so much software delegates so much control to unvetted external dependencies.

by mavhc 6y ago

0xbadcafebee 6y ago

That's more for availability than security. Assuming you keep the crypto checksums / author signatures of all the source code and packages, you don't need to keep a copy of the source / packages. Just verify them at download time. Many Linux distros don't even have a copy of all those binaries, they rely on HTTP mirrors of random organizations. It's also useful for your organization to rebuild all of the source code from scratch (for reproducible packages anyway) and compare the new ones to the old ones, looking for things like compiler or hardware injection attacks. Secure build systems are definitely non-trivial.

actuator 6y ago
One more advantage of keeping it together can be easier development cycle. IDE features like autocompletion and building would be faster if artifacts can be cached.
- lrem 6y ago
  My Vim is indeed magic. I start typing in a name and it autocompletes, then adds includes for whatever the package the thing I just used is in. I also can't imagine going back to not having code search, with its turning every identifier into a link.
zaphar 6y ago
It's not just that. Because it's all in the same repo and built with the same build tool it's also easier to run the same security checks you would use for your own code all automatically as part of your build process. All the tooling you use to secure your own code can be used to secure third party code as well with the same low level of friction.
rrdharan 6y ago
Google has a whitepaper on exactly how this works and the security aspects of the verifiable build system: https://cloud.google.com/security/binary-authorization-for-borg https://cloud.google.com/security/binary-authorization-for-b...

actuator 6y ago

But Google is more or less an exception in this regard, from hiring their own offensive penetration testing teams to having a lot of paranoia in general about anything from outside. They had adopted a lot of good practices early on. Even most big companies are not as thorough as them. I wonder how they built this culture and if it is even realistic for smaller companies to aim for it.

ftio 6y ago
I work on developer infrastructure at Google. Opinions my own. I think it typically comes down to a few key leaders having the political capital/will to enforce policies like this. Google's `third_party` policies[0] were created relatively early on and were, as far as I understand, supported by high level technical leaders. The ROI of policies like these is not always immediately evident, so you need the faith of key leaders in order to make room for them. Those leaders don't necessarily need to be high in the org chart — they just need to be respected by folks high in the org chart. As a counterfactual, establishing Google's strong testing culture seems to have been a mostly bottoms-up affair. Good article on the history of that at Mike Bland's blog[1]. 0. https://opensource.google/docs/thirdparty/ https://opensource.google/docs/thirdparty/ 1. https://mike-bland.com/2011/09/27/testing-grouplet.html https://mike-bland.com/2011/09/27/testing-grouplet.html
tetraodonpuffer 6y ago
At a previous job I pushed hard for this in a project I was responsible for, despite initial buy-in as time went on there was a consistent level of pushback about relaxing this requirement and allowing just importing anything ( the architecture of this was basically a separate repo storing ALL the dependencies where only a couple of people had commit access and where new dependencies were allowed after vetting ) Fortunately there was a hard legal requirement to vet every dependency license, otherwise I am not sure I would have been able to keep this workflow. As other posts say you do need a very strong commitment at the management level for this to work, besides security (where it feels that often it matters only until it costs money or until it’s even slightly inconvenient) it might be helpful to make a legal case (what if we ship something with a nested dependency on AGPL ) to get some help to establish these procedures. I have been writing and architecting security related software for pretty much all my career and I find it quite scary how these days so much software delegates so much control to unvetted external dependencies.