Anuncio de un esquema de vulnerabilidad unificado para código abierto


En los últimos meses, Google ha lanzado varios esfuerzos para fortalecer la seguridad de código abierto en múltiples frentes. Un enfoque importante es mejorar la forma en que identificamos y respondemos a las vulnerabilidades de seguridad conocidas sin hacer un trabajo manual extenso. Es esencial tener un formato de datos común preciso para clasificar y remediar las vulnerabilidades de seguridad, particularmente cuando se comunican los riesgos a las dependencias afectadas; permite una automatización más fácil y permite a los consumidores de software de código abierto saber cuándo se ven afectados y hacer arreglos de seguridad lo antes posible. como sea posible.

Liberamos el Base de datos de vulnerabilidades de código abierto (OSV) en febrero con el objetivo de automatizar y mejorar la clasificación de vulnerabilidades para desarrolladores y usuarios de software de código abierto. Este esfuerzo inicial se arrancó con un conjunto de datos de algunos miles de vulnerabilidades del OSS-Fuzz proyecto. La implementación de OSV para comunicar datos de vulnerabilidad precisos para cientos de proyectos críticos de código abierto demostró el éxito y la utilidad del formato, y obtuvo comentarios para ayudarnos a mejorar el proyecto; por ejemplo, eliminamos el requisito de clave de la API de la nube, lo que facilita aún más el acceso a la base de datos para más usuarios. La respuesta de la comunidad también mostró que había un gran interés en extender aún más el esfuerzo.

Hoy, nos complace anunciar un nuevo hito en la expansión de OSV a varios ecosistemas clave de código abierto: Ir, Oxido, Pitón, y DWF. Esta expansión une y agrega cuatro importantes bases de datos de vulnerabilidades, brindando a los desarrolladores de software una mejor manera de rastrear y remediar los problemas de seguridad que los afectan. Nuestro esfuerzo también se alinea con los recientes Orden ejecutiva de EE. UU. Sobre la mejora de la ciberseguridad de la nación, que enfatizó la necesidad de eliminar las barreras para compartir información sobre amenazas a fin de fortalecer la infraestructura nacional. Esta base de datos de vulnerabilidad compartida ampliada marca un paso importante hacia la creación de un entorno de código abierto más seguro para todos los usuarios.
Un esquema simple y unificado para describir las vulnerabilidades con precisión

Al igual que con el desarrollo de código abierto, las bases de datos de vulnerabilidades en código abierto siguen un modelo distribuido, con muchos ecosistemas y organizaciones creando su propia base de datos. Dado que cada uno usa su propio formato para describir las vulnerabilidades, un cliente que rastrea las vulnerabilidades en varias bases de datos debe manejar cada una por separado. El intercambio de vulnerabilidades entre bases de datos también es difícil.

El equipo de seguridad de código abierto de Google, el equipo de Go y la comunidad de código abierto en general han estado desarrollando un sencillo esquema de intercambio de vulnerabilidades para describir vulnerabilidades que está diseñado desde el principio para ecosistemas de código abierto. Después de comenzar a trabajar en el esquema hace unos meses, solicitó comentarios del público y recibió cientos de comentarios. Hemos incorporado la información de los lectores para llegar al esquema actual:

"identificación": cuerda,

"modificado": cuerda,

"publicado": cuerda,

"retirado": cuerda,

"alias": ( cuerda ),

"relacionados": ( cuerda ),

"paquete":

"ecosistema": cuerda,

"nombre": cuerda,

"puntilla": cuerda,

,

"resumen": cuerda,

"detalles": cuerda,

"afecta": (

"rangos": (

"tipo": cuerda,

"repositorio": cuerda,

"introducido": cuerda,

"reparado": cuerda

),

"versiones": ( cuerda )

),

"referencias": (

"tipo": cuerda,

"url": cuerda

),

"ecosistema_específico": ver especificaciones ,

"database_specific": ver especificaciones ,

Este nuevo esquema de vulnerabilidades tiene como objetivo abordar algunos problemas clave con la gestión de vulnerabilidades en código abierto. Descubrimos que no existía un formato estándar que:

  • Hace cumplir la especificación de versión que coincide con precisión con los esquemas de nombres y versiones utilizados en ecosistemas de paquetes de código abierto reales. Por ejemplo, hacer coincidir una vulnerabilidad como un CVE a un nombre de paquete y un conjunto de versiones en un administrador de paquetes es difícil de hacer de forma automatizada utilizando mecanismos existentes como CPE.
  • Puede usarse para describir vulnerabilidades en cualquier ecosistema de código abierto, sin requerir una lógica dependiente del ecosistema para procesarlas.
  • Es fácil de usar tanto para sistemas automatizados como para humanos.

Con este esquema esperamos definir un formato que todas las bases de datos de vulnerabilidades puedan exportar. Un formato unificado significa que las bases de datos de vulnerabilidades, los usuarios de código abierto y los investigadores de seguridad pueden compartir fácilmente herramientas y consumir vulnerabilidades en todo el código abierto. Esto significa una visión más completa de las vulnerabilidades en código abierto para todos, así como tiempos de detección y corrección más rápidos como resultado de una automatización más sencilla.

El estado actual


La especificación de esquema de vulnerabilidad ha pasado por varias iteraciones, y estamos invitando a recibir más comentarios a medida que se acerque a su finalización. Varias bases de datos públicas de vulnerabilidades ya están exportando este formato, y hay más en proceso:

El servicio OSV también ha agregado todas estas bases de datos de vulnerabilidades, que se pueden ver en nuestro interfaz de usuario web. También se pueden consultar con un solo comando a través del mismo API existentes:


rizo X POST D

'"confirmar": "a46c08c533cfdf10260e74e2c03fa84a13b6c456"'

"https://api.osv.dev/v1/query"

rizo X POST D

'"versión": "2.4.1", "paquete": "nombre": "jinja2", "ecosistema": "PyPI"'

"https://api.osv.dev/v1/query"


Automatización del mantenimiento de la base de datos de vulnerabilidades


También es difícil producir datos de vulnerabilidad de calidad. Además de Automatización existente de OSV, construimos más herramientas de automatización para el mantenimiento de la base de datos de vulnerabilidades, y utilizó estas herramientas para oreja la comunidad Base de datos de asesoramiento de Python. Esta automatización toma los feeds existentes, los empareja con precisión con los paquetes y genera entradas conteniendo rangos de versiones precisos y validados con mínima intervención humana. Planeamos extender esta herramienta a otros ecosistemas para los cuales no existe una base de datos de vulnerabilidades o hay poco soporte para el mantenimiento continuo de la base de datos.


Involucrarse


Gracias a todos los desarrolladores de código abierto que han proporcionado comentarios y han adoptado este formato. Continuamos trabajando con comunidades de código abierto para desarrollar esto aún más y lograr una adopción más generalizada en todos los ecosistemas. Si está interesado en adoptar este formato, agradeceríamos cualquier comentario sobre nuestro especificación pública.





Enlace a la noticia original