Google's Free Assured Open Source Software Service Hits General Availability (techcrunch.com) 24
An anonymous reader shares a report: About a year ago, Google announced its Assured Open Source Software (Assured OSS) service, a service that helps developers defend against supply chain security attacks by regularly scanning and analyzing some of the world's most popular software libraries for vulnerabilities. Today, Google is launching Assured OSS into general availability with support for well over a thousand Java and Python packages -- and while Google didn't initially disclose pricing when it first announced the service, the company has now revealed that it will be available for free.
Software development has long depended on third-party libraries (which are often maintained by only a single developer), but it wasn't until the industry got hit with a number of high-profile exploits that everyone (including the White House) perked up and started taking software supply chain security seriously. Now, you can't attend an open source conference without hearing about Software Bills of Materials (SBOMs), artifact registries and similar topics. It's no surprise then that Google, which has long been at the forefront of releasing open-source products, launched a service like Assured OSS.
Google promises that it will constantly keep these libraries up to date (without creating forks) and continuously scan for known vulnerabilities, do fuzz tests to discover new ones and then fix these issues and contribute these fixes back upstream. The company notes that when it first launched the service with around 250 Java libraries, it was responsible for discovering 48% of the new CVEs for these libraries and subsequently addressing them.
Software development has long depended on third-party libraries (which are often maintained by only a single developer), but it wasn't until the industry got hit with a number of high-profile exploits that everyone (including the White House) perked up and started taking software supply chain security seriously. Now, you can't attend an open source conference without hearing about Software Bills of Materials (SBOMs), artifact registries and similar topics. It's no surprise then that Google, which has long been at the forefront of releasing open-source products, launched a service like Assured OSS.
Google promises that it will constantly keep these libraries up to date (without creating forks) and continuously scan for known vulnerabilities, do fuzz tests to discover new ones and then fix these issues and contribute these fixes back upstream. The company notes that when it first launched the service with around 250 Java libraries, it was responsible for discovering 48% of the new CVEs for these libraries and subsequently addressing them.
Countdown To Google Dropping This Starts Now (Score:5, Insightful)
Re:Countdown To Google Dropping This Starts Now (Score:5, Insightful)
How long will this one last?
Just long enough for some poor souls' workflows to become completely dependent on it.
Re: (Score:3)
It's a free service that provides functionality people currently don't have. Worst case, when they ditch it they will go back to not having it.
It is pretty sad, though, that the first question you have to ask with anything from Google is "can I afford to use this knowing it will go away before its time"
Re: (Score:1)
That would be part of the "embrace, extend, extinguish" process (that's what the plan is here, in case it wasn't extremely obvious).
Re:Countdown To Google Dropping This Starts Now (Score:5, Insightful)
extinguish what, exactly?
it's just a list of publicly available software components, curated and security tested with (the promise of) security fixes being contributed upstream. even if they fail on that promise maintainers could fetch those fixes themselves since the service is free. and even if at some point the service ends, their contributions still remain. i really struggle to see your "extremely obvious" strategy.
Re: (Score:2)
Its probably the stuff they use internally. (Score:2)
Google has a great track record at dropping projects after a few years. How long will this one last?
It will last as long as google. I expect the 1,000 python and java packages are the ones google uses internally and scans/updates as part of their own internal development and security efforts.
What is the value proposition here? (Score:4, Insightful)
Why would pay for this? If they are going to push fixes upstream and not create forks - what does that mean Google is going to issue private patches to customers and sit on what are 0-days for everyone else some time or what?
What if upstream does not accept the patch or decides its a feature and files it under won't fix? Is Google going to drop the fix, since they are not going to make a fork?
Let's say I agree with Google's intitial assessment the behavior is vulnerable and patch, if upstream rejects the idea its a vuln am I not suck at whatever version Google's initial fix applies against or stuck maintaining my own patch?
TBH it seems like it would be a lot more 'helpful' to everyone if Google would just publish a list of FOSS they use in their own projects, Fuzz/Audit/SAST-Scan or whatever they are going to do to them and create pull requests to fix stuff. That would be socially responsible thing to do.
Re: (Score:2)
And as far as the supply chain assurance bit - they could just publish the a signature for the archive they audited/certified. No need to run their own repo..
Re: (Score:3)
running their own repo is more convenient and secure. first, you "know" everything in that repo is audited always, you don't have to check every external dependency for a signature that probably doesn't exist because the very latest patch (that you probably don't even need) hasn't been re-certified yet. second you have a single secure channel you can trust (ymmv) as opposed to a combination of them where funny stuff happens like e.g. github screwing up credentials, or developers inadvertently accepting mali
Re: (Score:2)
Is Google going to drop the fix, since they are not going to make a fork?
Excellent question. Others in the mix are: Will they drop this service the minute we start using it? Is it accurate? Will they start charging for it the minute we depend on it? What if the author disagrees and "wontfix" will someone arbitrate this dispute or will it be Google-is-always-right? What if Google's increasing political involvement impacts their judgement (ie.. "Your software isn't woke enough" or "This was used to harass trans people." or whatever) then they mislabel you as vulnerable or out of c
Re: (Score:3)
What if upstream does not accept the patch or decides its a feature and files it under won't fix? Is Google going to drop the fix, since they are not going to make a fork?
i guess that's a case by case scenario. security fixes tend to be objective stuff that is hard to argue, even if sometimes auditors like to split hairs just to be on the safe side, or maybe just to justify their job. but a security fix very rarely will negatively impact software unless there already was a glaring design flaw, so it's something really hard to reasonably reject.
so if upstream really rejects a patch then there will indeed be a "soft fork" for a while. i assume google will periodically re-audit
Re: (Score:1)
Great point, there is a system in place for these things, and in the case that Google doesn't trust the commit access that the maintainers have, they should probably be publicly highlighting that too vs just trying to route around any issues.
A fork is not a branch. (Score:2)
If they are going to push fixes upstream and not create forks
A fork is not a branch. Branches are an everyday thing within a repository. Updates and fixes will likely go into a patch specific branch and be merged into main branch at some point. One can always choose to use the patch branch prior to the merger into main.
Forks involve the creation of a new repository, a copy of the original. There may or may not be any intentions of merging changes with the original. It may be someone does not have the authorization to work on the original so they fork, make changes
Forefront of releasing, eh? (Score:1)
Assures Open Source Software Service (Score:3)
aka "Google insert itself in yet another area of online computing in order to become yet more unavoidable".
Re: (Score:2)
Re: (Score:3)
Never heard of Log4J?
And... (Score:1)
bodo (Score:1)