Google's Open-Source Bug Bounty Aims To Clamp Down on Supply Chain Attacks (theverge.com) 3
Google has introduced a new vulnerability rewards program to pay researchers who find security flaws in its open-source software or in the building blocks that its software is built on. It'll pay anywhere from $101 to $31,337 for information about bugs in projects like Angular, GoLang, and Fuchsia or for vulnerabilities in the third-party dependencies that are included in those projects' codebases. From a report: While it's important for Google to fix bugs in its own projects (and in the software that it uses to keep track of changes to its code, which the program also covers), perhaps the most interesting part is the bit about third-party dependencies. Programmers often use code from open-source projects so they don't continuously have to reinvent the same wheel. But since developers often directly import that code, as well as any updates to it, that introduces the possibility of supply chain attacks. That's when hackers don't target the code directly controlled by Google itself but go after these third-party dependencies instead.
As SolarWinds showed, this type of attack isn't limited to open-source projects. But in the past few years, we've seen several stories where big companies have had their security put at risk thanks to dependencies. There are ways to mitigate this sort of attack vector -- Google itself has begun vetting and distributing a subset of popular open-source programs, but it's almost impossible to check over all the code a project uses. Incentivizing the community to check through dependencies and first-party code helps Google cast a wider net.
As SolarWinds showed, this type of attack isn't limited to open-source projects. But in the past few years, we've seen several stories where big companies have had their security put at risk thanks to dependencies. There are ways to mitigate this sort of attack vector -- Google itself has begun vetting and distributing a subset of popular open-source programs, but it's almost impossible to check over all the code a project uses. Incentivizing the community to check through dependencies and first-party code helps Google cast a wider net.
$31337? (Score:2)
elite.
Re: (Score:1)
Our Software Dependency Problem (Score:3)
Just the other day I read a very interesting article (Our Software Dependency Problem [swtch.com]) where the author writes about how we got where we are today with regards to code sharing and dependencies, and the main reason is automated dependency managers:
For decades, discussion of software reuse was far more common than actual software reuse. Today, the situation is reversed: developers reuse software written by others every day, in the form of software dependencies, and the situation goes mostly unexamined.
A dependency manager (sometimes called a package manager) automates the downloading and installation of dependency packages. As dependency managers make individual packages easier to download and install, the lower fixed costs make smaller packages economical to publish and reuse.
Before dependency managers, publishing an eight-line code library would have been unthinkable: too much overhead for too little benefit. But NPM has driven the overhead approximately to zero, with the result that nearly-trivial functionality can be packaged and reused. In late January 2019, the escape-string-regexp package is explicitly depended upon by almost a thousand other NPM packages, not to mention all the packages developers write for their own use and donâ(TM)t share.
The whole article is interesting and I recommend reading it.