This is about managing security risks of using OSS libraries. Many organizations end up using OSS code/libs/products without having the capability or the motivation to validate them. Google addresses some of those issues with this.
In this way Google can (possibly) have a lot of influence on what components
/ libraries / solutions to pick.
Do you want to use our secure packages, which are guaranteed (to some extent) to be safe, or do you feel better using unsecure packages from somewhere else?
It is your choice.
I can imagine a lot of enterprise mandating using what Google is providing.
It is interesting to compare this old post to what has happened since. There were roots placed in the standardisation process at that time which is still in progress but with a good draft [1].
There was also a stronger push to use SBOMs from NIST [2] which was kind of dropped by Google.
As for the OSS Google integrated NPM registry with the public Rekor which collects and signs info about packages in the ledger [3]. I am not sure if that integration helps much though as it is quite fiddly to work with Rekor signatures and proofs.
AFAIK if you sell to the gov they will ask for SBOMs like NIST suggests.
Part of this thorough process of verification and checking open source projects is also ensuring that those critical projects are also funded appropriately to reflect their mission critical nature in your corporate software stack.
It seems this is about helping with security, not about helping with development. (?) If anything, faster development would increases security risks instead of decreasing them, no?
Mixed bag. Some would say more development is more churn is more risk, some would say that bugs are inevitable and a slow development velocity implies that vulnerabilities are unlikely to be fixed quickly. This is one of those questions we'd probably have to answer in aggregate with actual science and probably still conclude that it still goes the other way in some cases
Does this mean that Google will be actively patching all the vulnerabilities
they find?
Then donating their work to the OSS project, they belong to?
Or do they deprecate / remove from registry packages that are found to
be vulnerable?
Or sticking to the last version they can find without the bug?
All of those can in one way or another become a headache for people who
use the service. Projects that depend on other projects and libraries
and suddenly a library and suddenly they are not available?
On the other hand these artifacts not being available for security reasons
means customers owont deploy insecure products.
Does that mean Google can take them away at any time? Does Google have any contractual obligation to keep them available, or transfer them to some trusted third party to host them when Google kills the product?
> Does that mean Google can take them away at any time?
It's open source software, so no. The product is basically google vetting the software, building it in a reproducible way and then packaging it up so you can have some more confidence in where it's come from. If they shut it down you could switch back to downloading the same builds from wherever you used to get them, though obviously you wouldn't then benefit from the vetting etc.
Readit News
https://cloud.google.com/security/products/assured-open-sour...
Do you want to use our secure packages, which are guaranteed (to some extent) to be safe, or do you feel better using unsecure packages from somewhere else? It is your choice.
I can imagine a lot of enterprise mandating using what Google is providing.
The list of what they already support https://cloud.google.com/assured-open-source-software/docs/s... Is fairly long and that is good, but it ofcourse leaves out a hell of a lot.
There was also a stronger push to use SBOMs from NIST [2] which was kind of dropped by Google.
As for the OSS Google integrated NPM registry with the public Rekor which collects and signs info about packages in the ledger [3]. I am not sure if that integration helps much though as it is quite fiddly to work with Rekor signatures and proofs.
AFAIK if you sell to the gov they will ask for SBOMs like NIST suggests.
[1]: https://datatracker.ietf.org/group/scitt/about/
[2]: https://www.nist.gov/itl/executive-order-14028-improving-nat...
[3]: https://slsa.dev/blog/2023/05/bringing-improved-supply-chain...
Oh, hang on, no that's not part of it.
Then donating their work to the OSS project, they belong to?
Or do they deprecate / remove from registry packages that are found to be vulnerable? Or sticking to the last version they can find without the bug?
All of those can in one way or another become a headache for people who use the service. Projects that depend on other projects and libraries and suddenly a library and suddenly they are not available?
On the other hand these artifacts not being available for security reasons means customers owont deploy insecure products.
It's open source software, so no. The product is basically google vetting the software, building it in a reproducible way and then packaging it up so you can have some more confidence in where it's come from. If they shut it down you could switch back to downloading the same builds from wherever you used to get them, though obviously you wouldn't then benefit from the vetting etc.