Google mejora su herramienta de control de riesgos Scorecards

Google ha anunciado hoy una importante actualización Scorecards, proyecto de seguridad automatizada que genera una puntuación de riesgo para los proyectos de software de código abierto.

Google es uno de los principales impulsores de Scorecard y, en una entrada de su blog, ha anunciado hoy una serie de nuevas funciones en la versión 2 de Scorecards.

La herramienta Scorecards fue lanzada en noviembre de 2020 por Google y Open Source Security Foundation. El objetivo era ayudar a las empresas a decidir si debían adoptar un determinado proyecto de software de código abierto en función de aspectos como su nivel de seguridad y su grado de confianza.

Aunque algunas empresas cuentan con sistemas y procesos para evaluar las carencias del software de código abierto, la mayoría de las organizaciones no lo hacen. Como resultado, pueden adoptar involuntariamente software plagado de vulnerabilidades en algunos de sus proyectos más críticos.

Scorecards funciona generando automáticamente una puntuación de riesgo para cualquier proyecto de código abierto basada en métricas como su política de seguridad, una revisión del código y una cobertura de pruebas continuas mediante herramientas de fuzzing y análisis estático del código.

En el blog de la empresa, los miembros del equipo de seguridad de código abierto de Google, Kim Lewandowski, Azeem Shaikh y Laurent Simon, escribieron: “Con tanto software que depende de proyectos de código abierto, los consumidores necesitan una manera fácil de juzgar si sus dependencias son seguras. Scorecards ayuda a reducir el trabajo y el esfuerzo manual necesarios para evaluar continuamente los paquetes cambiantes al mantener la cadena de suministro de un proyecto. Los consumidores pueden evaluar automáticamente los riesgos que introducen las dependencias y utilizar estos datos para tomar decisiones informadas sobre la aceptación de estos riesgos, la evaluación de soluciones alternativas o la colaboración con los responsables del mantenimiento para introducir mejoras.”

La actualización de Scorecards añade una serie de nuevas comprobaciones de seguridad. Una de las más importantes es la que ayuda a evitar que los colaboradores de los proyectos tengan propósitos maliciosos. Esto es importante porque una de las principales formas de introducir vulnerabilidades en el código es a través de colaboradores malintencionados que parecen estar ayudando a desarrollar un proyecto, sólo para deslizar un error dentro del código que de otra manera mejora o añade nuevas funciones.

La nueva comprobación de Branch-Protection garantizará que, cuando se realice una actualización en un proyecto de código abierto, se aplique una revisión obligatoria del código por parte de otro desarrollador antes de que pueda presentarse.

Una segunda comprobación nueva ayuda a garantizar que un proyecto utilice controles de calidad continuos, como el fuzzing y las pruebas estáticas de seguridad de aplicaciones, para tratar de detectar más vulnerabilidades innocuas que se cuelan en su código de forma habitual.

La nueva comprobación de prevención de permisos de tokens, por su parte, ayuda a proteger contra los atacantes que intentan crear una solicitud de extracción maliciosa para obtener acceso a tokens privilegiados de GitHub, y con ello añadir algún código malicioso sin que sea revisado primero.

Otras nuevas comprobaciones están diseñadas para asegurar que todas las dependencias de software de un proyecto han sido declaradas, para que luego puedan ser revisadas. Entre ellas se encuentran la comprobación de artefactos binarios, el control Frozen-Deps y la comprobación automatizada de actualización de dependencias.

“Esta herramienta totalmente automatizada evalúa periódicamente los proyectos críticos de código abierto y expone la información de las comprobaciones a través de un conjunto de datos público de BigQuery que se actualiza semanalmente. Como vemos, queda mucho por hacer para mejorar la seguridad de estos proyectos críticos. Un gran número de estos proyectos no se someten a un fuzzing continuo, no definen una política de seguridad para informar de las vulnerabilidades y no fijan las dependencias, por nombrar solo algunos problemas comunes. Es necesario que todos nos unamos como industria para impulsar la concienciación sobre estos riesgos de seguridad generalizados, y para introducir mejoras que beneficien a todos”, termina diciendo la empresa.

Ilustración: Canva


Únase a la conversación

Contacto | Diario TI es una publicación de MPA Publishing International Ltd., Reino Unido. © Copyright 1997-2022