Una nueva esperanza para la seguridad del software

Por Matt Asay

Colaborador, InfoWorld |

La vulnerabilidad Log4j de diciembre de 2021 destacó la cadena de suministro de software como un área de seguridad enormemente descuidada. Reveló cuán interconectados están nuestros artefactos de software y cómo nuestros sistemas son tan seguros como sus eslabones más débiles. También reforzó la idea de que podemos pensar que la seguridad es algo que podemos comprar, pero en realidad se trata de cómo funcionamos como equipos de desarrollo.

Desde entonces, hemos estado corriendo para mejorar.

Quizás lo más notable sea que el proyecto Sigstore, de código abierto de Google, se convirtió en el método de firma de facto para artefactos de software, adoptado por todos los principales ecosistemas de lenguajes, incluidos Java, Python, Node, Ruby y más. Se convirtió en uno de los proyectos de seguridad de código abierto de adopción más rápida de la historia y brindó a los desarrolladores un “sello de cera” de autenticidad para determinar los orígenes y la procedencia de sus componentes básicos de software.

Entonces, ¿ya llegamos a ese punto?

No precisamente. Aún no. El concepto de lista de materiales de software (SBOM) introducido por decreto de la Casa Blanca en mayo de 2021 sigue pareciendo distante. Este concepto de lengua franca para que los desarrolladores compartan listas de ingredientes en paquetes de software tiene múltiples formatos emergentes (SPDX, CycloneDX), lo que complica las cosas. Peor aún, no ha quedado claro cómo los SBOM encajarían realmente en los flujos de trabajo de los desarrolladores y qué ventajas específicas obtendría un desarrollador en el proceso.

Lo que está empezando a unir todo esto (y a crear más urgencia para crear una estrategia cohesiva en torno a la firma de software, los SBOM y el flujo de trabajo de los desarrolladores) es la regulación, que exigiría una propiedad más estricta de la integridad de la seguridad del software.

En abril, la Agencia de Infraestructura y Ciberseguridad (CISA) publicó una solicitud de comentarios sobre un formulario de certificación de desarrollo de software seguro recientemente propuesto que responsabilizará a los directores ejecutivos de las empresas de software de dar fe de que su software se ha creado en entornos seguros y que Se han realizado esfuerzos razonables y de buena fe para mantener cadenas de suministro de código fuente confiables.

¿Qué se considera “razonable”?

Hasta ahora, los esfuerzos “razonables” parecen ser las pautas establecidas en los Requisitos de escaneo de vulnerabilidades para contenedores de FedRAMP y el Marco de desarrollo de software seguro del Instituto Nacional de Estándares y Tecnología. Pero la interpretación mucho más matizada y de lectura entre líneas de los nuevos requisitos de autocertificación se encuentra en las cláusulas que cubren el código de terceros incorporado al software. En resumen, los proveedores de software serán responsables del código abierto popular no financiado y no mantenido que utilizan en sus cadenas de suministro.

¿Esperar lo? ¿Responsable del código de algún mantenedor de proyecto aleatorio? Aparentemente sí. ¿Es eso “razonable”?

Esta vertiginosa variedad de consideraciones para los CISO se ha convertido en el blanco de varios memes de Twitter:

Esta es una comprobación un tanto impactante, si es necesaria, de la adopción ilimitada del código abierto. No estoy sugiriendo que las empresas no deban utilizar código abierto, sino todo lo contrario. Les recuerdo que no hay nada gratis, incluso cuando viene empaquetado como software gratuito (y de código abierto). Alguien debe pagar para mantener las luces encendidas para los mantenedores, y alguien debe ayudar a los desarrolladores a darle sentido a todo este software entrante de código abierto.

Chainguard podría ser alguien así.

Chainguard es una empresa dirigida por ex empleados de Google detrás del proyecto Sigstore. Está tratando de reunirlo todo en una cadena de herramientas cohesiva para los desarrolladores. Los primeros esfuerzos de la startup se centraron en medidas para bloquear el proceso de construcción y hacer que características como firmas, procedencia y SBOM sean nativas de las cadenas de suministro de software y el proceso de construcción de software. El año pasado, con Wolfi, introdujeron la primera (des)distribución comunitaria de Linux construida específicamente en torno a las primitivas de seguridad de la cadena de suministro. También lanzaron Chainguard Images, que son imágenes base para binarios independientes, aplicaciones como nginx y herramientas de desarrollo como compiladores Go y C.

Recientemente, Chainguard introdujo otra actualización importante en su plataforma Enforce, ampliando esos componentes básicos para bloquear los sistemas de compilación a una cadena de herramientas que se encuentra entre los desarrolladores y los equipos de seguridad.

Los desarrolladores, los profesionales de la seguridad e incluso los auditores necesitan saber qué paquetes de software se implementan, dónde y quién los implementa. Los SBOM están diseñados para ayudar a responder estas preguntas y más, pero cuanto más complejo es un entorno, más difícil es lograrlo. Los clústeres suelen ejecutar cientos de cargas de trabajo con cientos de imágenes de contenedor, mientras que cada imagen de contenedor tiene cientos, si no miles, de paquetes. Todavía estamos en una fase tan temprana de los SBOM que la mayoría de los paquetes no se envían con SBOM; necesitan ser generados.

Chainguard apunta a ambos extremos del problema. Primero, como mantenedores de Sigstore, la compañía ha estado impulsando la firma de software, las certificaciones y los administradores de certificados en todos los principales lenguajes de programación y registros para que haya uniformidad y coherencia en la forma en que estos proyectos de código abierto crean SBOM. Con el reciente lanzamiento de Enforce, la plataforma creará automáticamente un SBOM usando Syft para que los desarrolladores no tengan que realizar ningún paso adicional para poder ver información completa del paquete para cada imagen.

El desafío más difícil para los nuevos requisitos regulatorios de autocertificación es que las imágenes de contenedores tienden a ir a la zaga de las actualizaciones anteriores, por lo que las cadenas de suministro aún ejecutan imágenes con vulnerabilidades conocidas. Además, la mayoría de los escáneres de vulnerabilidades y exposiciones comunes (CVE) actuales utilizan bases de datos de paquetes para ver qué paquetes están instalados dentro de los contenedores, pero el software instalado fuera de estos sistemas es invisible para los escáneres.

Al facilitar a los desarrolladores la ingesta o la creación automática de SBOM para paquetes que aún no los tienen, Chainguard proporciona un corpus de datos de mucha mayor fidelidad para la detección de vulnerabilidades. Además, el nuevo análisis de vulnerabilidades de Enforce puede indicar a los equipos si están ejecutando un artefacto con un CVE y exactamente dónde.

Todo esto llega justo a tiempo. Ningún desarrollador quiere ser el primero en descubrir cómo utilizar los SBOM. Sin embargo, no tienen otra opción: la combinación de FedRAMP y los requisitos de autocertificación está generando una necesidad inmediata de visibilidad constante de los paquetes de software y los procesos automatizados para encontrar y eliminar vulnerabilidades.

Si desea vender al gobierno federal de EE. UU., los SBOM pronto serán un requisito. Pero no es sólo para quienes venden al gobierno. Es razonable suponer que el nuevo modelo de autocertificación para asignar responsabilidad legal por software inseguro probablemente hará que los SBOM sean una tarifa de seguridad común en toda la industria tecnológica, o al menos para las empresas de software que no quieren ser nombradas en futuras demandas colectivas.

A continuación lee esto:

Matt Asay dirige las relaciones con los desarrolladores en MongoDB. Las opiniones expresadas aquí son las de Matt y no reflejan las de su empleador.

Copyright © 2023 IDG Communications, Inc.