Google lance un programme pour lutter contre les attaques visant la supply chain de ses logiciels.
Google a récemment lancé un nouveau programme de bug bounty pour ses projets open source. La firme offre de payer les développeurs entre 100 à 31 337 dollars selon le bug trouvé. Le but est de sécuriser leur écosystème contre les attaques de la supply chain. Ces derniers ont connu une montée en puissance ces dernières années.
Google, un acteur majeur de l’open source
Le géant de la technologie est derrière des projets majeurs tels qu’Angular, Bazel, Golang, Protocol Buffers ou encore Fuchsia. Son programme vise à récompenser les découvertes de vulnérabilités qui pourraient avoir un impact significatif sur le paysage plus large des logiciels libres.
L’offre est l’un des premiers programmes de vulnérabilité destinés aux technologies open source. Elle a été baptisée l’Open Source Software Vulnerability Rewards Program. Les autres projets gérés par Google et hébergés dans des dépôts publics tels que GitHub, ainsi que les dépendances third-party incluses dans ces projets sont également éligibles.
Venir à bout des vulnérabilités de la supply chain
Les soumissions doivent correspondre à des critères précis :
- Des vulnérabilités qui impactent la supply chain.
- Des problèmes de design qui causent des vulnérabilités.
- D’autres problèmes de sécurité tels que la divulgation des informations sensibles, des mots de passe faibles ou des installations non sécurisées.
Le renforcement des composants open source, en particulier des bibliothèques tierces qui constituent la base de nombreux logiciels, est devenu une priorité pour Google. Cette décision a été motivée par l’escalade constante des attaques de la supply chain visant Maven, NPM, PyPI et RubyGems. La vulnérabilité Log4Shell de la bibliothèque Java Log4j, révélée en décembre 2021, montre bien les conséquences de ces failles. Elle a causé des ravages à grande échelle.
ompelling that Google ties its bug bounty to supply‑chain threats, especially the emphasis on upstream dependencies—a point that resonates with my own work mapping material routes for ecosystem resilience. It reminds me of how tracing indirect impacts can reveal hidden vulnerabilities. While the initiative is a solid first step, I think expanding the scope to include third‑party libraries would strengthen the effort, much like adding a verification layer in a mapping tool.