Blog de seguridad en línea de Google: Midiendo riesgos de seguridad en software de código abierto: Scorecards lanza V2



Colaboradores de la Proyecto de cuadros de mando, una herramienta de seguridad automatizada que produce una "puntuación de riesgo" para proyectos de código abierto, han logrado mucho desde nuestro lanzamiento el otoño pasado. Hoy, en colaboración con el Fundación de seguridad de código abierto comunidad, estamos anunciando Tarjetas de puntuación v2. Agregamos nuevos controles de seguridad, aumentamos la cantidad de proyectos que se califican y facilitamos el acceso a estos datos para su análisis.

Con tanto software hoy en día que depende de proyectos de código abierto, los consumidores necesitan una manera fácil de juzgar si sus dependencias son seguras. Los cuadros de mando ayudan a reducir el trabajo y el esfuerzo manual necesarios para evaluar continuamente los cambios de paquetes cuando se mantiene 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 cómo aceptar estos riesgos, evaluar soluciones alternativas o trabajar con los encargados de mantenimiento para realizar mejoras.

Identificación de riesgos

Desde el otoño pasado, la cobertura de Scorecards ha crecido; hemos agregado varias comprobaciones nuevas, siguiendo las Conocer, prevenir, reparar el marco propuesto por Google a principios de este año, para priorizar nuestras adiciones:

Colaboradores maliciosos

Los colaboradores con intenciones maliciosas o cuentas comprometidas pueden introducir posibles puertas traseras en el código. Las revisiones de código ayudan a mitigar estos ataques. Con el nuevo Protección de rama Verifique, los desarrolladores pueden verificar que el proyecto exige la revisión obligatoria del código por parte de otro desarrollador antes de que se confirme el código. Actualmente, esta verificación solo la puede ejecutar un administrador de repositorio debido a las limitaciones de la API de GitHub. Para un repositorio de terceros, use el menos informativo Revisión de código comprobar en su lugar.

Código vulnerable

A pesar de los mejores esfuerzos de los desarrolladores y las revisiones por pares, el código vulnerable puede ingresar al control de la fuente y permanecer sin ser detectado. Por eso es importante habilitar el análisis de código estático y fuzzing continuo para detectar errores en las primeras etapas del ciclo de vida del desarrollo. Hemos agregado comprobaciones para detectar si un proyecto usa Fuzzing y SAST herramientas como parte de su sistema CI / CD.

Compromiso del sistema de construcción

Una solución común de CI / CD utilizada por los proyectos de GitHub es Acciones de GitHub. Un peligro con estos flujos de trabajo de acciones es que pueden manejar entradas de usuarios que no son de confianza. Es decir, un atacante puede crear una solicitud de extracción maliciosa para obtener acceso al token de GitHub privilegiado y, con él, la capacidad de enviar código malicioso al repositorio sin revisión. Para mitigar este riesgo, Scorecard's Permisos de token La comprobación de prevención ahora verifica que los flujos de trabajo de GitHub sigan el principio de privilegio mínimo al hacer que los tokens de GitHub sean de solo lectura de forma predeterminada.

Malas dependencias

Cualquier software es tan seguro como su dependencia más débil. Esto puede parecer obvio, pero el primer paso para conocer nuestras dependencias es simplemente declararlas … y hacer que nuestras dependencias las declaren también. Una vez que tenemos esta información de procedencia, podemos evaluar los riesgos de nuestro software y mitigar esos riesgos. Desafortunadamente, existen varios anti-patrones ampliamente utilizados que rompen este principio de procedencia. El primero de estos anti-patrones son los binarios registrados, ya que no hay forma de verificar o verificar fácilmente el contenido del binario en el proyecto. Scorecards proporciona Artefactos binarios verifique para probar esto.

Otro anti-patrón es el uso de rizos | bash en scripts que extrae dependencias dinámicamente. Los hash criptográficos nos permiten fijar nuestras dependencias a un valor conocido: si este valor cambia alguna vez, el sistema de compilación lo detectará y se negará a compilar. Anclar dependencias es útil en todos los lugares donde tenemos dependencias: no solo durante la compilación, sino también en Dockerfiles, flujos de trabajo de CI / CD, etc. Frozen-Deps cheque. Esta comprobación es útil para mitigar los ataques de dependencia maliciosos, como el reciente CodeCov ataque.

Incluso con la fijación de hash, los hashes deben actualizarse de vez en cuando cuando las dependencias reparan vulnerabilidades. Herramientas como dependiente o renovarbot Danos la oportunidad de revisar y actualizar los valores hash. Los cuadros de mando Actualización automática de dependencias check verifica que los desarrolladores confíen en dichas herramientas para actualizar sus dependencias.

Es importante conocer las vulnerabilidades de un proyecto antes de asumirlo como dependencia. Los cuadros de mando pueden proporcionar esta información a través del nuevo Vulnerabilidades comprobar, sin la necesidad de suscribirse a un sistema de alerta de vulnerabilidad.


Escalando el impacto


Hasta la fecha, el proyecto Scorecards se ha ampliado para evaluar los criterios de seguridad para más de 50.000 proyectos de código abierto. Para escalar este proyecto, realizamos un rediseño masivo de nuestra arquitectura y usamos un modelo PubSub que logró escalabilidad horizontal y mayor rendimiento. Esta herramienta totalmente automatizada evalúa periódicamente los proyectos críticos de código abierto y expone la información de verificación de Scorecards a través de un conjunto de datos público de BigQuery que se actualiza semanalmente.


Estos datos se pueden recuperar utilizando el herramienta de línea de comandos bq. El siguiente ejemplo muestra cómo exportar datos para el proyecto de Kubernetes. Sustituya la URL del repositorio para exportar datos de un proyecto diferente:

$ bq query –nouse_legacy_sql 'SELECT Repo, Date, Checks FROM openssf.scorecardcron.scorecard_latest WHERE Repo = "github.com/kubernetes/kubernetes"'

Para exportar los datos más recientes de todos los proyectos analizados, consulte las instrucciones aquí.

¿Cómo está Internet a la altura?

Los datos de los cuadros de mando de los proyectos disponibles ahora se incluyen en el Anunciado Estadísticas de código abierto de Google proyecto y también exhibido en Proyecto de métricas de seguridad de OpenSSF. Los datos de estos sitios muestran que todavía hay importantes lagunas de seguridad que llenar, incluso en los paquetes más utilizados. como Kubernetes.

También analizamos los datos de Scorecards a través de Google Data Studio, una de nuestras herramientas de análisis y visualización de datos. El diagrama a continuación muestra un desglose de las verificaciones que se ejecutaron y el resultado de pasa / falla para los 50.000 repositorios:

Como podemos ver, queda mucho por hacer para mejorar la seguridad de estos proyectos críticos. Un gran número de estos proyectos no se realizan de forma continua borroso, no defina una política de seguridad para informar vulnerabilidades y no fije dependencias, por nombrar solo algunos problemas comunes. Todos debemos unirnos como industria para generar conciencia sobre estos riesgos de seguridad generalizados y realizar mejoras que beneficien a todos.

Cuadros de mando en acción

Varios proyectos grandes han adoptado Scorecards y nos mantienen actualizados sobre sus experiencias con ellos. A continuación, se muestran algunos ejemplos de cuadros de mando en acción:

Enviado
Al principio nosotros habló sobre cómo los mantenedores de Envoy adoptaron Scorecards para su proyecto y lo integraron dentro de su política sobre la introducción de nuevas dependencias. Desde entonces, las solicitudes de extracción que introducen nuevas dependencias en Envoy deben obtener la aprobación de un responsable de mantenimiento de dependencias que utilice cuadros de mando para evaluar la dependencia frente a un conjunto de criterios.

Además, Envoy también hizo bien en trabajar para mejorar sus propias métricas de salud de seguridad de acuerdo con su propia evaluación de Scorecards, y ahora está fijando dependencias de C ++ y requiriendo pip hashes para las dependencias de Python. Acciones de Github también se fijan en el flujo de integración continuo.

Anteriormente, Envoy había creado un herramienta que genera datos de cuadros de mando en sus dependencias como un CSV que se puede utilizar para generar una tabla de resultados:

Ahora, con más datos del proyecto, Envoy puede generar automáticamente información actualizada del cuadro de mando sobre sus dependencias y publicarla en documentación, como el siguiente:

Cuadros de mando
¡Mejoramos nuestra propia puntuación para las tarjetas de puntuación! Por ejemplo, ahora estamos fijando nuestras propias dependencias mediante hash (p. Ej. dependencias de Docker, dependencias del flujo de trabajo) para prevenir CodeCov ataques de estilo. También hemos incluido un Politica de seguridad basado en esto plantilla recomendada.

Involucrarse

Esperamos seguir haciendo crecer la comunidad de Scorecards. El proyecto ahora tiene contribuciones de 23 desarrolladores. Gracias a Azeem, Naveen, Laurent, Asra y Chris por su trabajo en la creación de estas nuevas funciones y la ampliación de cuadros de mando.

Si quieres unirte a la diversión, echa un vistazo a estos buenos novatos asuntos.

Si desea que lo ayudemos a ejecutar cuadros de mando en proyectos específicos, envíe una solicitud de extracción de GitHub para agregar esos proyectos aquí.

Por último, pero no menos importante, tenemos muchas ideas y muchos más cheques que nos gustaría agregar, pero queremos saber de usted. Díganos qué comprobaciones le gustaría ver en la próxima versión de Scorecards.


¿Que sigue?

Hay un par de grandes mejoras que nos entusiasman especialmente:
Gracias de nuevo a toda la comunidad de Scorecards y OpenSSF por hacer que este proyecto sea un éxito. Si está adoptando y mejorando la puntuación de los proyectos que mantiene, Dinos sobre eso. Hasta la próxima, ¡sigue mejorando esos puntajes!



Enlace a la noticia original