Frank Crane no estaba hablando de fuente abierta cuando dijo: «Puedes ser engañado si confías demasiado, pero vivirás en tormento si no confías lo suficiente».
Pero esa es una excelente manera de resumir la brecha actual entre cómo es el código abierto de hecho que se consume, versus los patrones de confianza cero que las empresas están tratando de codificar en sus DevSecOps prácticas.
Cada estudio que veo sugiere que entre el 90% y el 98% del software del mundo es de código abierto. Todos tomamos código escrito por otras personas (sobre los hombros de gigantes) y construimos y modificamos todo ese código, confiando implícitamente en todos los autores, mantenedores y contribuyentes que nos precedieron.
Incluso antes de comenzar a escribir nuestro código, confiamos en que el código fuente abierto subyacente se escribió de forma segura. Luego, cuando lo usamos, confiamos en que los autores no fueron maliciosos y que el código no fue alterado antes de instalarlo. Eso es lo opuesto a la confianza cero. Eso es máximo confianza.
Echemos un vistazo a la evolución de la distribución de software y a las nuevas raíces de confianza Es necesario plantar recursos para respaldar las próximas décadas de innovación de código abierto.
El software de código abierto es seguro
Al principio, los detractores del código abierto provocaron mucho miedo, incertidumbre y dudas en torno a su seguridad. Su argumento era que el código fuente del software propietario estaba protegido de miradas indiscretas y, por lo tanto, era más seguro que el código abierto, cuyo código fuente estaba fácilmente disponible para cualquiera.
Pero el código abierto ha demostrado que existe una positivo efecto cuando tienes transparencia del código fuente. El efecto de red de muchos ojos sobre el código fuente revela vulnerabilidades más rápidamente y crea ciclos de remediación mucho más rápidos. Los resultados hablan por sí solos: el 90% de las vulnerabilidades explotadas conocidas (en la lista CVE mantenida por CISA) son software propietario, a pesar de que alrededor de El 97% de todo el software es de código abierto..
Es demasiado fácil cuando hay una vulnerabilidad importante difamar el estado general de la seguridad del código abierto. De hecho, muchas de estas vulnerabilidades de alto perfil muestran el poder de la seguridad de código abierto. Log4shellpor ejemplo, fue el peor de los casos para una vulnerabilidad de OSS a escala y nivel de visibilidad: esta era una de las bibliotecas más utilizadas en uno de los lenguajes de programación más utilizados. (Log4j incluso se estaba ejecutando en el rover de Marte. ¡Técnicamente, esta fue la primera vulnerabilidad OSS intergaláctica!) La vulnerabilidad Log4shell fue trivial de explotar, increíblemente extendida y con graves consecuencias. Los encargados de su mantenimiento pudieron parchearlo e implementarlo en cuestión de días. Fue una gran victoria para la respuesta de seguridad de código abierto a nivel de mantenedor, no un fracaso.
Y ese logro debería ser ampliamente reconocido. Compare ese tiempo de divulgación y reparación de un par de días con los programas de divulgación de proveedores de firmware o proveedores de nube que tardan 30, 60 o incluso 90 días en implementar correcciones para algo como esto en el mejor de los casos. Sin embargo, las empresas se han quedado rezagadas a la hora de tomar las medidas necesarias contra la vulnerabilidad. De acuerdo a un informe reciente de Veracode, más de una de cada tres, o el 38%, de las aplicaciones que ejecutan Log4j todavía utilizan versiones vulnerables del programa.
Pero el código abierto requiere confianza
Cuando comienzas a desarrollar tu software, eso es solo la punta del iceberg sobre la superficie. Estás construyendo sobre millones de líneas de software gratuito creado para el bien público, de forma gratuita. Eso es posible gracias a confianza.
A las distribuciones de Linux, además de encargarse de la compilación del código fuente y evitar que los usuarios de OSS tengan que compilar y depurar, se les debe acreditar el enorme papel que desempeñaron en el establecimiento de esa confianza. Cuando utiliza archivos binarios de una distribución de Linux, confía en los mantenedores anteriores que escriben el código fuente. y la distribución. Son dos grupos diferentes de personas. Las distribuciones de Linux entendieron esto y realmente avanzaron en el estado del arte en seguridad de software durante las últimas décadas, al ser pioneros en enfoques para las cadenas de suministro de software y al establecer métodos estrictos para examinar a los mantenedores de paquetes.
Debian es uno de los más notables en el campo por su sofisticación a la hora de codificar la confianza dentro de la distribución. Debian utiliza el sistema de firma de claves PGP, donde sólo si suficientes mantenedores firman las claves para los eventos de cifrado, se agregan al conjunto de claves de Debian. Estas firmas se verifican a medida que se cargan nuevos paquetes y luego la propia distribución Debian vuelve a firmar todos los paquetes que se han incorporado. Entonces, cuando se publican desde Debian, los usuarios pueden verificar esas firmas sin importar dónde encuentren esos paquetes y asegurarse de que esos paquetes llegaron a través de una distribución Debian de mantenedores en los que confían y que los paquetes no han sido manipulados en el camino.
Es un modelo que ha funcionado fenomenalmente bien.
Y las dependencias de OSS han superado los modelos de confianza
Pero hoy en día, la mayor parte del consumo de software se produce fuera de las distribuciones. Los propios administradores de paquetes de lenguajes de programación: npm (javascript), pipa (Pitón), gemas de rubí (Rubí), compositor (PHP): se ven y se sienten como administradores de paquetes de distribución de Linux, pero funcionan de manera un poco diferente. Básicamente, no ofrecen curación: cualquiera puede cargar un paquete e imitar a un mantenedor de idioma. ¿Y cómo saber en qué está confiando, cuando la instalación de un solo paquete a menudo instala paquetes de docenas de personas al azar en Internet?
Estibador multiplicó aún más este problema de confianza transitiva. Las imágenes de Docker son fáciles de crear porque utilizan los administradores de paquetes existentes dentro de ellas. Puede usar una instalación de npm para obtener paquetes de npm y luego agruparlos en una imagen de Docker. Puede instalar una aplicación con los administradores de paquetes de cualquier idioma y luego enviarla como una gran bola TAR. Docker reconoció esta brecha de confianza y hay que reconocer que intentó cerrarla con algo llamado Verified Builds, que evolucionó hasta convertirse en una función dentro de Docker Hub.
Estas compilaciones verificadas de Docker eran una forma para que los usuarios especificaran el script de compilación para una imagen de Docker en forma de archivo Docker, en el repositorio de código fuente. El mantenedor escribe el archivo Docker, pero luego Docker realiza la compilación, por lo que lo que ve en la imagen es el mismo código de sus mantenedores originales. Docker implementó esto hace años y continúa mejorándolo, por lo que merecen un gran reconocimiento.
Docker no es el único actor en esta red de confianza para software nativo de la nube, aunque; se vuelve más complicado. Hay una capa encima de Docker que se usa comúnmente en el Kubernetes reino. Helm te permite empaquetar un montón de imágenes y configuraciones de Docker. Es un paquete de paquetes.
Entonces, si instala el gráfico Helm para Prometheus, por ejemplo, es probable que también obtenga muchas otras imágenes de proyectos personales aleatorios. Puede estar seguro de que está obteniendo Prometheus de los mantenedores de Prometheus, porque el centro de artefactos muestra que proviene de un editor verificado, pero Prometheus a menudo tiene dependencias que no provienen de editores verificados.
El repositorio oficial de gráficos de Helm mantenido por los creadores originales de Helm fue un intento curado de codificar la confianza en estas imágenes. Tenía el potencial de llevar a las aplicaciones nativas de la nube el mismo tipo de seguridad que ofrecen las distribuciones de Linux. Pero desafortunadamente resultó demasiado difícil de escalar y tomó un modelo más federado como los administradores de paquetes de lenguajes de programación, donde cada proyecto mantiene sus propios gráficos Helm.
Todas estas capas de dependencias transitivas son las que constituyen una parte importante del sistema moderno. problema de seguridad de la cadena de suministro de software y una de las áreas más jugosas para que la exploten los actores maliciosos. Esta es la primera línea de la nueva batalla para preservar toda la gran confianza en el código abierto que se ha ido acumulando a lo largo de décadas.
Hacer que el software sea seguro desde el principio
La distribución de software es dramáticamente diferente de lo que era hace 20 años, cuando solías comprar software empaquetado en una tienda como CompUSA o Best Buy. Cuando compraste una caja de software, sabías exactamente lo que obtenías. Sabías que provenía de la persona que se suponía que debía ser y que no había sido manipulado.
A medida que la distribución de software pasó de los CD-ROM a Internet, las distribuciones de Linux demostraron un éxito sorprendente a la hora de generar confianza.
Cuando Log4j y SolarWinds mostraron algunas de las grietas que están explotando los nuevos ataques a la cadena de suministro de software, los equipos comenzaron a bloquear los sistemas de compilación, utilizando marcos como SSDF y SLSAy comprobar las firmas de software producidas por tienda de firmas (ahora el método de firma de software predeterminado utilizado por Kubernetes y todos los principales registros de lenguajes de programación). Eso es progreso.
Este dominio de seguridad de código abierto es complejo. ¡Estamos hablando de modelos de confianza con décadas de antigüedad comparados con 372 millones de repositorios solo en GitHub!
Todavía existe una desconexión importante entre los CVE conocidos y los desarrolladores que los reinstalan sin saberlo a través de dependencias transitivas. Todavía hay toda una clase de vulnerabilidades que viven completamente fuera de las distribuciones de Linux y, por lo tanto, no son detectadas por los escáneres de seguridad. Ya es bastante difícil para los consumidores de software darse cuenta de cuándo están ejecutando paquetes de software malicioso, y mucho menos ser lo suficientemente ágiles para parchearlos rápidamente con actualizaciones cuando estén disponibles.
En 2024, veremos cómo se cierran las brechas de seguridad de la cadena de suministro de software entre CVE, distribuciones de Linux y paquetes de software. Vamos a ver una reducción importante en los artefactos de software no esenciales que se incluyen tanto en las distribuciones como en las imágenes, y las distribuciones mismas comenzarán a competir en función de la eficiencia con la que pueden enviar correcciones de vulnerabilidades lo más rápido posible, como lobo.
Comenzaremos a escuchar a los equipos de seguridad alinear sus expectativas de seguridad de la infraestructura de aplicaciones con conceptos de confianza cero y ya no aceptarán un montón de detalles en sus distribuciones e imágenes que pueden introducir grietas y puertas traseras a las dependencias transitivas. Veremos equipos de seguridad que quieren acercarse al kernel con tecnologías como eBPF y cilioy utilizar la aplicación de políticas de seguridad en tiempo de ejecución que proyectos como Tetragon pueden proporcionar. Y veremos este bloqueo acelerado por casos de uso de IA que piden a las empresas que confíen en aún más marcos con dependencias aún más transitivas, incluidas arquitecturas de GPU especializadas y puertas traseras cada vez más matizadas.
Para que los desarrolladores sigan disfrutando de la libertad de elegir sus componentes OSS favoritos sobre los que construyen, es necesario repensar la distribución de software. Necesitamos formas más uniformes de crear, empaquetar, firmar y verificar todo el código fuente que se incluye en los paquetes en contenedores, y la distribución de estos componentes nativos de la nube, manteniéndolos al mismo tiempo al mínimo y seguros de forma predeterminada. Todos están en la cima de la pila, que es el lugar perfecto para refactorizar las raíces de confianza que respaldarán las próximas décadas de innovación de código abierto en el mundo nativo de la nube. Es hora de contar con una fuente segura estándar de facto para el software de código abierto.
Dan Lorenc es director ejecutivo y cofundador de Guardacadenas. Anteriormente, fue ingeniero de software y líder del equipo de seguridad de código abierto (GOSST) de Google. Fundó proyectos como Minikube, Skaffold, TektonCD y Sigstore.
—
New Tech Forum ofrece un lugar para que los líderes tecnológicos, incluidos proveedores y otros contribuyentes externos, exploren y debatan la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva y se basa en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para su publicación y se reserva el derecho de editar todo el contenido aportado. Envia todo consultas a doug_dineley@foundryco.com.
Copyright © 2024 IDG Communications, Inc.