[14/04/2023] Esta semana, Google lanzó un servicio gratuito de API que proporciona a los desarrolladores de software datos de dependencia e información relacionada con la seguridad sobre más de cinco millones de componentes de software en diferentes lenguajes de programación. Hoy, la empresa también ha anunciado la disponibilidad general de su servicio Assured Open Source Software (Assured OSS), que proporciona a los equipos de desarrollo un repositorio de paquetes de seguridad comprobada para Python y Java.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Ambos servicios forman parte de los esfuerzos de Google por reducir los riesgos de la cadena de suministro de software que existen en el ecosistema de código abierto, proporcionando amplios metadatos de seguridad, información sobre vulnerabilidades y la información necesaria para crear listas de materiales de software (SBOM). Una de las formas más comunes en que los atacantes pueden introducir código malicioso en los proyectos de software es comprometiendo un componente popular de código abierto o una de sus muchas dependencias.
Las vulnerabilidades transitivas heredadas de las dependencias también son un problema importante, ya que muchas de ellas ni siquiera se detectan si los equipos de desarrollo no disponen de buenas herramientas para rastrear los avisos de software en las dependencias indirectas, es decir, varias capas hacia abajo en la cadena de dependencias.
La API gratuita deps.dev de Google
El equipo Open Source Insights de Google ha recopilado metadatos de seguridad de múltiples fuentes para cinco millones de paquetes con 50 millones de versiones que se encuentran en los registros públicos Go, Maven (Java), PyPI (Python), npm (JavaScript) y Cargo (Rust). También está prevista la compatibilidad con paquetes NuGet (.NET framework).
Los metadatos recopilados incluyen gráficos de dependencias transitivas, información sobre licencias, informes sobre el impacto de los avisos de seguridad e información de la OpenSSF Security Scorecard. Estos datos se organizan ahora como un conjunto de datos BigQuery, y están disponibles para su consulta y análisis de forma gratuita a través de la API deps.dev.
Por ejemplo, utilizando esta API los desarrolladores pueden responder a preguntas como: ¿Qué versiones están disponibles para un paquete específico? ¿Qué licencias de software utiliza una versión concreta? ¿Cuántas dependencias tiene un paquete y cuáles son? ¿A qué paquetes y versiones corresponde un determinado archivo? Esto puede ayudar a los desarrolladores a tomar decisiones mejor fundadas a la hora de evaluar el riesgo asociado a un paquete o versión que se plantean consumir como parte de su proyecto.
La nueva API ya se ha integrado en Graph for Understanding Artifact Composition (GUAC), una herramienta de código abierto para construir SBOM, pero Google espera más integraciones en el futuro. Por ejemplo, como complemento de los entornos de desarrollo integrados (IDE), la API puede poner inmediatamente a disposición de los desarrolladores información sobre dependencias y seguridad. Sin embargo, también podría integrarse en marcos CI/CD para evitar la distribución de código vulnerable, en herramientas de compilación y motores de políticas por razones de cumplimiento, en herramientas de análisis posteriores a la publicación para detectar vulnerabilidades de las que se haya informado recientemente en bases de código existentes, en herramientas de gestión de inventario de software que puedan ayudar a identificar archivos misteriosos y en herramientas de visualización para obtener una mejor comprensión y visión del gráfico de dependencias de un programa de software.
Vulnerabilidades como Log4Shell, una falla crítica en el componente log4j de Java, demostraron lo frágil que es el ecosistema del software. Muchas empresas de software y equipos de desarrollo tardaron en determinar si sus productos estaban afectados o no; porque, aunque log4j podía no ser una dependencia directa para su software, sí podía serlo de forma indirecta, incluida estáticamente en algún otro paquete que utilizaban.
En estos casos, la integración de la API deps.dev puede resultar muy útil. Por ejemplo, la API admite la búsqueda por hash de archivo para ver a qué versión de un paquete pertenece, y si está afectado por una vulnerabilidad conocida. Una herramienta CI/CD que utilice la API podría alertar inmediatamente de que una vulnerabilidad conocida afecta a la base de código, y una herramienta de visualización podría basarse en la API para mostrar un gráfico de dependencias que podría indicar qué dependencia directa tiene el archivo log4j vulnerable e iniciar los esfuerzos para ponerse en contacto con el mantenedor de ese paquete para pedirle o contribuir con un parche rápido.
Para entender lo generalizado y grave que es el problema de las vulnerabilidades transitivas, casi un año después de que se descubriera Log4Shell y recibiera una amplia cobertura en las comunidades tecnológicas, el 72% de las organizaciones seguían teniendo activos vulnerables a él, y el número de intentos de explotación de la falla seguía siendo elevado. Una de las razones era que no sólo log4j estaba afectado directamente y requería un parche. La clase Java vulnerable llamada JndiManager incluida en Log4j-core fue tomada prestada por otros 783 proyectos y se encuentra ahora en más de 19 mil componentes de software.
El servicio API de deps.dev está replicado globalmente y altamente disponible utilizando la infraestructura en la nube de Google. Su uso es gratuito y no requiere autenticación ni clave de API. Los desarrolladores sólo tienen que realizar consultas a la API a través de HTTPS y recibir las respuestas en forma de objetos JSON.
"La seguridad de la cadena de suministro de software es difícil, pero a todos nos interesa hacerla más fácil", afirman los miembros del equipo de seguridad de código abierto de Google en una entrada de blog. "Cada día, Google trabaja duro para crear una Internet más segura, y estamos orgullosos de liberar esta API para ayudar a hacer precisamente eso y hacer que estos datos sean universalmente accesibles y útiles para todos".
OSS garantizado sin costo alguno
Además de la API deps.dev, Google ha anunciado la disponibilidad general de su servicio Assured OSS. Se trata esencialmente de un repositorio de más de mil de los paquetes Java y Python más populares cuya procedencia ha sido verificada y cuya seguridad ha sido comprobada por los propios equipos de Google. Este servicio se lanzó originalmente en vista previa pública hace un año.
"Disponible hoy sin costo alguno, Assured OSS ofrece a cualquier organización que utilice software de código abierto la oportunidad de aprovechar la seguridad y la experiencia que Google aplica a las dependencias de código abierto, incorporando a sus propios flujos de trabajo de desarrollo los mismos paquetes de OSS que Google protege y utiliza", afirmó Andy Chang, director de grupo de productos de seguridad y privacidad de Google Cloud, en una entrada de blog.
Todos los paquetes alojados en este repositorio cumplen el marco Supply-chain Levels for Software Artifacts (SLSA) y ofrecen tres niveles de garantía:
- Nivel 1, creado y firmado por Google
- Nivel 2, creado de forma segura a partir de fuentes verificadas y certificado para todas las dependencias transitivas.
- Nivel 3, que incluye el cierre transitivo de todas las dependencias y se somete a un escaneado y una comprobación continuos.
Los paquetes se someten periódicamente a análisis y pruebas de vulnerabilidad, e incluyen datos de la base de datos Open-Source Vulnerabilities (OSV). Los paquetes también están firmados y se distribuyen desde un repositorio seguro y mantenido por Google. Por último, cada paquete incluye SBOM y metadatos de Cloud Build, análisis de artefactos, estado del paquete y datos sobre el impacto de las vulnerabilidades en varios formatos estándar para que puedan ser utilizados por diferentes herramientas.
Además de las pruebas de seguridad, Google cuenta con un equipo de aplicación de parches que solucionará rápidamente los problemas de seguridad detectados en los paquetes y los trasladará a versiones anteriores que no sean compatibles con el desarrollador original. "El proceso de curación aporta importantes beneficios de seguridad a quienes adoptan Assured OSS y a la comunidad en general", afirmó Chang. "Desde que nuestro equipo de Assured OSS curó los primeros 278 paquetes, hemos sido los primeros en encontrar el 48% de las nuevas vulnerabilidades (CVE) -cada uno de estos CVE ha sido corregido y actualizado".
Mantener copias de los paquetes más utilizados dentro de los repositorios locales en lugar de extraerlos siempre de los repositorios públicos, es una práctica que llevan a cabo muchas empresas. En teoría, esto proporciona un amortiguador en caso de que la versión pública de un paquete popular se vea comprometida y se le inyecte código malicioso. Sin embargo, también podría retrasar la adopción de parches de seguridad. Numerosos estudios han demostrado a lo largo de los años que las organizaciones suelen utilizar versiones obsoletas y vulnerables de componentes de código abierto en sus aplicaciones.
Assured OSS de Google pretende resolver algunos de los inconvenientes de mantener un repositorio privado empleando a un equipo especializado de profesionales de la seguridad con experiencia para gestionarlo y garantizar la calidad de la seguridad de los paquetes que contiene, algo que la mayoría de las empresas no pueden permitirse hacer internamente.
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú