OSV, el servicio de google para conocer sobre vulnerabilidades en el open source

Google dio a conocer hace poco el lanzamiento de un nuevo servicio llamado «OSV» (Open Source Vulnerabilities), que ofrece acceso a una base de datos de información sobre vulnerabilidades en software de código abierto.

El servicio proporciona una API que permite automatizar la formación de solicitudes para obtener información sobre vulnerabilidades, con referencia al estado del repositorio con el código. A las vulnerabilidades se les asignan identificadores OSV separados que complementan el CVE con información ampliada.

En particular, la base de datos OSV refleja el estado de la solución del problema, se indican las confirmaciones con la aparición y reparación de la vulnerabilidad, el rango de versiones vulnerables, los enlaces al repositorio del proyecto con el código y la notificación del problema.

Estamos muy contentos de lanzar OSV (Vulnerabilidades de código abierto), nuestro primer paso hacia la mejora de la clasificación de vulnerabilidades para desarrolladores y consumidores de software de código abierto. El objetivo de OSV es proporcionar datos precisos sobre dónde se introdujo una vulnerabilidad y dónde se solucionó, ayudando así a los consumidores de software de código abierto a identificar con precisión si se ven afectados y luego hacer las correcciones de seguridad lo más rápido posible. Hemos iniciado OSV con un conjunto de datos de vulnerabilidades fuzzing encontradas por el servicio OSS-Fuzz . El proyecto OSV evolucionó a partir de nuestros esfuerzos recientes para mejorar la gestión de vulnerabilidades en código abierto ( marco «Conocer, prevenir, reparar»).

La gestión de vulnerabilidades puede resultar dolorosa tanto para los consumidores como para los encargados del mantenimiento del software de código abierto, y en muchos casos implica un tedioso trabajo manual.

El propósito principal de crear OSV es simplificar el proceso de informar a los mantenedores de paquetes sobre las vulnerabilidades identificando con precisión las versiones y confirmaciones que se ven afectadas por el problema. Los datos presentes permiten a nivel de commits y tags rastrear la manifestación de la vulnerabilidad y analizar la susceptibilidad al problema de derivadas y dependencias.

Además de la búsqueda de vulnerabilidades, también debería automatizar la búsqueda de versiones afectadas. Para ello, el servicio se basa en procesos automatizados de análisis de impacto y bisección. Este último se usa para encontrar la confirmación que introdujo un error particular en el proyecto. 

Cualquiera que utilice una biblioteca de código abierto puede acceder a OSV a través de una API y consultar si una versión en particular se ve afectada por una vulnerabilidad encontrada. Se requiere una clave de API de la consola de API de Google para la consulta.

Para los consumidores de software de código abierto, a menudo es difícil asignar una vulnerabilidad como una entrada de Vulnerabilidades y Exposiciones Comunes (CVE) a las versiones de paquete que están usando. Esto se debe al hecho de que los esquemas de control de versiones de los estándares de vulnerabilidad existentes (como Common Platform Enumeration (CPE) ) no se corresponden bien con los esquemas de control de versiones de código abierto reales, que normalmente son versiones / etiquetas y hashes de confirmación. El resultado son vulnerabilidades pasadas por alto que afectan a los consumidores intermedios.

Por ejemplo, la API permite solicitar información sobre la presencia de vulnerabilidades por número de confirmación o versión del programa. Actualmente, la base de datos contiene cerca de 25 mil problemas identificados en el proceso de pruebas de fuzzing automatizado en el sistema OSS-Fuzz, que cubre el código de más de 380 proyectos de código abierto en C/C ++.

Estamos planeando trabajar con comunidades de código abierto para ampliar con datos de varios ecosistemas de lenguaje (por ejemplo, NPM, PyPI) y elaborar una canalización para que los mantenedores de paquetes envíen vulnerabilidades con un trabajo mínimo.

En el futuro, está previsto conectar fuentes adicionales de información sobre vulnerabilidades a la base de datos. Por ejemplo, se está trabajando para integrar información sobre vulnerabilidades en proyectos en el lenguaje Go, así como en los ecosistemas NPM y PyPl.

Finalmente si deseas conocer más al respecto, puedes consultar el siguiente enlace.