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




Contacto | Diario TI es una publicaci贸n de MPA Publishing International Ltd.