La mayor presión regulatoria y legal sobre las organizaciones productoras de software para proteger sus cadenas de suministro y garantizar la integridad de su software no debería sorprender. En los últimos años, la cadena de suministro de software se ha convertido en un objetivo cada vez más atractivo para los atacantes que ven oportunidades para multiplicar sus ataques por órdenes de magnitud. Por ejemplo, no busquemos más allá de la violación de Log4j de 2021, donde Log4j (un marco de registro de código abierto mantenido por Apache y utilizado en innumerables aplicaciones diferentes) fue la raíz de vulnerabilidades que pusieron en riesgo miles de sistemas.
La funcionalidad de comunicación de Log4j era vulnerable y, por lo tanto, proporcionaba una oportunidad para que un atacante inyectara código malicioso en los registros que luego podría ejecutarse en el sistema. Después de su descubrimiento, los investigadores de seguridad vieron millones de intentos de explotación, muchos de los cuales se convirtieron en ataques exitosos de denegación de servicio (DoS). Según algunas de las últimas investigaciones de Gartner, cerca de la mitad de las organizaciones empresariales habrán sido objeto de un ataque a la cadena de suministro de software en 2025.
Pero ¿qué es la cadena de suministro de software? Bueno, para empezar, se define como la suma total de todo el código, las personas, los sistemas y los procesos que contribuyen al desarrollo y entrega de artefactos de software, tanto dentro como fuera de una organización. Y lo que hace que asegurar la cadena de suministro de software sea tan desafiante es la naturaleza compleja y altamente distribuida del desarrollo de aplicaciones modernas. Las organizaciones emplean equipos globales de desarrolladores que dependen de una cantidad sin precedentes de dependencias de código abierto, junto con una variedad de repositorios de código y registros de artefactos, canalizaciones de CI/CD y recursos de infraestructura utilizados para crear e implementar sus aplicaciones.
Y si bien la seguridad y el cumplimiento son constantemente una de las principales preocupaciones de las organizaciones empresariales, el desafío de proteger las cadenas de suministro de software de la organización es cada vez mayor. Muchas organizaciones están logrando avances materiales en la puesta en práctica de las prácticas de DevSecOps; sin embargo, muchas de ellas todavía se encuentran en las primeras etapas para determinar qué hacer.
Es exactamente por eso que hemos elaborado este artículo. Aunque la siguiente no es de ninguna manera una lista exhaustiva, aquí hay cuatro principios rectores para que sus esfuerzos de seguridad de la cadena de suministro de software avancen en la dirección correcta.
Considere todos los aspectos de su cadena de suministro de software al aplicar la seguridad
Dado que más del 80% de las bases de código tienen al menos una vulnerabilidad de código abierto, es lógico que las dependencias de OSS hayan sido un foco central de la seguridad de la cadena de suministro de software. Sin embargo, las cadenas de suministro de software modernas abarcan otras entidades cuyas posturas de seguridad se pasan por alto o no se comprenden lo suficientemente ampliamente dentro de la organización como para gestionarlas adecuadamente. Estas entidades son repositorios de código, canalizaciones de CI y CD, infraestructura y registros de artefactos, cada uno de los cuales requiere controles de seguridad y evaluaciones periódicas del cumplimiento.
Marcos como OWASP Top-10 para CI/CD y Punto de referencia de seguridad de la cadena de suministro de software CIS. Adherirse a estos marcos requerirá RBAC granular, aplicar el principio de privilegio mínimo, escanear contenedores e infraestructura como código en busca de vulnerabilidades y configuraciones incorrectas, aislar compilaciones, integrar pruebas de seguridad de aplicaciones y una gestión adecuada de los secretos, solo por nombrar algunos.
Los SBOM son esenciales para solucionar los problemas de días cero y otros problemas de componentes
Parte de la Orden Ejecutiva 14028, emitida por la Casa Blanca a mediados de 2021 para fortalecer la postura de ciberseguridad del país, exige que los productores de software proporcionen a sus clientes federales una lista de materiales de software (SBOM, por sus siglas en inglés). Las SBOM son esencialmente registros formales destinados a brindar visibilidad sobre todos los componentes que forman una pieza de software. Proporcionan un inventario detallado y legible por máquina que enumera todas las bibliotecas, dependencias y componentes de código abierto y de terceros utilizados en la creación del software.
Ya sea que una organización esté obligada por la EO 14028 o no, generar y administrar SBOM para artefactos de software es una práctica valiosa. Los SBOM son una herramienta indispensable para solucionar problemas de componentes o vulnerabilidades de día cero. Cuando se almacenan en un repositorio con capacidad de búsqueda, los SBOM proporcionan un mapa de dónde existe una dependencia específica y permiten a los equipos de seguridad rastrear rápidamente las vulnerabilidades hasta los componentes afectados.
Gobierne el ciclo de vida del desarrollo de software con políticas como código
En el mundo del desarrollo de aplicaciones moderno, las barreras de seguridad sólidas son una herramienta esencial para eliminar errores y acciones intencionales que comprometen la seguridad y el cumplimiento. Una gobernanza adecuada en toda la cadena de suministro de software significa que la organización ha hecho que sea fácil hacer las cosas correctas y extremadamente difícil hacer las cosas incorrectas.
Si bien muchas plataformas y herramientas ofrecen políticas listas para usar que se pueden aplicar rápidamente, la política como código basada en el estándar de la industria Open Policy Agent permite crear y aplicar políticas totalmente personalizables. Políticas que rigen todo, desde privilegios de acceso hasta permitir o denegar el uso de dependencias de OSS según criterios como proveedor, versión, URL del paquete y licencia.
Ser capaz de verificar y garantizar la confianza en sus artefactos de software utilizando SLSA
¿Cómo pueden los usuarios y consumidores saber que un software es confiable? Para determinar la confiabilidad de un artefacto de software, querrá saber cosas como quién escribió el código, quién lo creó y en qué plataforma de desarrollo se creó. Saber qué componentes contiene también sería algo que deberías saber.
Es posible tomar una decisión sobre si se debe confiar en el software una vez que se puede verificar la procedencia (el registro de los orígenes y la cadena de custodia de un software). Para esto, el Marco de niveles de cadena de suministro para artefactos de software (SLSA) fue creado. Brinda a las organizaciones productoras de software la capacidad de capturar información sobre cualquier aspecto de la cadena de suministro de software, verificar las propiedades de los artefactos y su construcción, y reducir el riesgo de problemas de seguridad. En la práctica, es esencial que las organizaciones productoras de software adopten y cumplan los requisitos del marco SLSA e implementen un medio para verificar y generar certificaciones de software que son declaraciones autenticadas (metadatos) sobre artefactos de software a lo largo de sus cadenas de suministro de software.
Dada la magnitud y complejidad de asegurar la cadena de suministro de software moderna, la guía anterior apenas toca la superficie. Pero como todo lo demás en el mundo de la creación e implementación de aplicaciones modernas, la práctica está evolucionando rápidamente. Para ayudarle a empezar, le recomendamos leer Cómo entregar software de forma segura – un libro electrónico lleno de mejores prácticas diseñadas para fortalecer su postura de seguridad y minimizar el riesgo para su negocio.