Esta sería la recompensa por errores de código abierto de Google tiene como objetivo tomar medidas drásticas contra los ataques a la cadena de suministro

Google ha introducido un nuevo programa de recompensas por vulnerabilidades para pagar a los investigadores que encuentran fallas de seguridad en su software de código abierto o en los componentes básicos en los que se basa su software. Pagará entre $ 101 y $ 31,337 por información sobre errores en proyectos como Angular, GoLang y Fuchsia o por vulnerabilidades en las dependencias de terceros que se incluyen en las bases de código de esos proyectos.

Si bien es importante que Google corrija errores en sus propios proyectos (y en el software que utiliza para realizar un seguimiento de los cambios en su código, que también cubre el programa), quizás la parte más interesante es la parte sobre las dependencias de terceros. Los programadores a menudo usan código de proyectos de código abierto para no tener que reinventar continuamente la misma rueda.

Pero dado que los desarrolladores a menudo importan directamente ese código, así como cualquier actualización, eso presenta la posibilidad de ataques a la cadena de suministro. Ahí es cuando los piratas informáticos no apuntan al código directamente controlado por Google, sino que persiguen estas dependencias de terceros.

Como mostró SolarWinds, este tipo de ataque no se limita a proyectos de código abierto. Pero en los últimos años, hemos visto varias historias en las que las grandes empresas han puesto en riesgo su seguridad debido a las dependencias. Hay formas de mitigar este tipo de vector de ataque: Google mismo ha comenzado a investigar y distribuir un subconjunto de programas populares de código abierto, pero es casi imposible verificar todo el código que usa un proyecto. Incentivar a la comunidad para que verifique las dependencias y el código propio ayuda a Google a crear una red más amplia.

De acuerdo con las reglas de Google, los pagos del Programa de recompensas por vulnerabilidad de software de código abierto dependerán de la gravedad del error, así como de la importancia del proyecto en el que se encontró (Fuchsia y similares se consideran proyectos «insignia» y, por lo tanto, tienen la mayores pagos).

También hay algunas reglas adicionales sobre las recompensas por las vulnerabilidades de la cadena de suministro: los investigadores deberán informar primero a quien esté realmente a cargo del proyecto de terceros antes de decírselo a Google. También tienen que demostrar que el problema afecta al proyecto de Google; si hay un error en una parte de la biblioteca que la empresa no usa, no será elegible para el programa.

Google también dice que no quiere que la gente husmee en los servicios o plataformas de terceros que utiliza para sus proyectos de código abierto. Si encuentra un problema con la configuración de su repositorio de GitHub, está bien; si encuentra un problema con el sistema de inicio de sesión de GitHub, eso no está cubierto. (Google dice que no puede autorizar a las personas a «realizar investigaciones de seguridad de activos que pertenecen a otros usuarios y empresas en su nombre»).

Para los investigadores que no están motivados por el dinero, Google ofrece donar sus recompensas a una organización benéfica elegida por el investigador; la compañía incluso dice que duplicará esas donaciones.

Obviamente, este no es el primer intento de Google de obtener una recompensa por errores: tuvo algún tipo de programa de recompensa por vulnerabilidades durante más de una década. Pero es bueno ver que la compañía está tomando medidas sobre un problema sobre el que ha estado dando la voz de alarma.

A principios de este año, a raíz del exploit Log4Shell que se encuentra en la popular biblioteca Log4j de código abierto, Google dijo que el gobierno de EE. UU., debe involucrarse más en la búsqueda y el tratamiento de problemas de seguridad en proyectos críticos de código abierto. Desde entonces, como señala BleepingComputer, la compañía ha aumentado temporalmente los pagos para las personas que encuentran errores en ciertos proyectos de código abierto como Kubernetes y el kernel de Linux.