La presión reguladora y legal sobre las organizaciones productoras de software para asegurar 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 exponencialmente sus ataques. Por ejemplo, basta con mirar el incidente de Log4j en 2021, donde Log4j (un marco de registro de código abierto mantenido por Apache y utilizado en una variedad de aplicaciones) fue la raíz de exploits que pusieron en riesgo miles de sistemas.
La funcionalidad de comunicación de Log4j era vulnerable y proporcionaba una apertura a los atacantes para inyectar código malicioso en los registros, el cual podía ser ejecutado en el sistema. Después de su descubrimiento, los investigadores de seguridad observaron millones de intentos de exploits, muchos de los cuales resultaron en exitosos ataques de denegación de servicio (DoS). Según la última investigación de Gartner, cerca de la mitad de las organizaciones empresariales habrán sido objetivo de un ataque a la cadena de suministro de software para 2025.
Pero, ¿qué es la cadena de suministro de software? Bueno, para empezar, se define como la totalidad del código, personas, sistemas y procesos que contribuyen al desarrollo y entrega de artefactos de software, tanto dentro como fuera de una organización.
‘
Y lo que hace tan desafiante asegurar la cadena de suministro de software es la naturaleza compleja y altamente distribuida en el desarrollo de aplicaciones modernas. Las organizaciones emplean equipos globales de desarrolladores que dependen de un número sin precedentes de dependencias de código abierto, junto con una amplia gama de repositorios de código, registros de artefactos, canalizaciones de CI/CD y recursos de infraestructura utilizados para construir e implementar sus aplicaciones.
Si bien la seguridad y el cumplimiento son consistentemente una preocupación principal para las organizaciones empresariales, el desafío de asegurar las cadenas de suministro de software de la organización es cada vez mayor. Muchas organizaciones están logrando avances significativos en la aplicación de prácticas de DevSecOps en sus operaciones, sin embargo, muchas de ellas aún se encuentran en las primeras etapas de descubrir qué hacer.
Es precisamente por eso que hemos creado este artículo. Aunque lo siguiente no es de ninguna manera una lista exhaustiva, aquí hay cuatro principios rectores para poner en marcha sus esfuerzos de seguridad en la cadena de suministro de software en la dirección correcta.
Debe considerar Todos los Aspectos de su Cadena de Suministro de Software al Aplicar Seguridad
Dado que más del 80% de las bases de código tienen al menos una vulnerabilidad de código abierto, tiene sentido que las dependencias de código abierto hayan sido un enfoque central de la seguridad de la cadena de suministro de software. Sin embargo, las cadenas de suministro de software modernas abarcan otras entidades cuyos posturas de seguridad son pasadas por alto o no comprendidas lo suficientemente ampliamente dentro de la organización como para ser gestionadas adecuadamente.
‘
Estas entidades son repositorios de código, canalizaciones de CI/CD, infraestructura y registros de artefactos, cada uno de los cuales requiere controles de seguridad y evaluaciones periódicas de cumplimiento.
Frameworks como OWASP Top-10 para CI/CD y CIS Software Supply Chain Security Benchmark. Cumplir con estos frameworks requerirá RBAC granular, aplicar el principio de menor privilegio, escanear contenedores y infraestructura como código en busca de vulnerabilidades y configuraciones incorrectas, aislar compilaciones, integrar pruebas de seguridad de aplicaciones y manejar adecuadamente secretos, por nombrar solo algunos.
‘
Los SBOMs son Esenciales para Remediar Vulnerabilidades Zero-day 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 de la nación, exige que los productores de software proporcionen a sus clientes federales un listado de materiales de software (SBOMs). Los SBOMs son registros formales destinados a proporcionar visibilidad de todos los componentes que componen un software. Proporcionan un inventario detallado y legible por máquina que enumera todas las bibliotecas de código abierto y de terceros, dependencias y componentes utilizados en la construcción del software.
Ya sea que una organización esté obligada por el EO 14028 o no, generar y administrar SBOMs para los artefactos de software es una práctica valiosa. Los SBOMs son una herramienta indispensable para remediar problemas de componentes o vulnerabilidades zero-day. Cuando se almacenan en un repositorio searchable, los SBOMs 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 modernas, los sólidos controles son una herramienta esencial para eliminar errores y acciones intencionales que comprometen la seguridad y el cumplimiento. Un gobierno adecuado en toda la cadena de suministro de software significa que la organización ha facilitado hacer las cosas correctas y extremadamente difícil hacer las cosas incorrectas.
Si bien muchas plataformas y herramientas ofrecen políticas prediseñadas que se pueden aplicar rápidamente, las políticas como código basadas en el estándar de la industria del Agente de Políticas Abiertas (Open Policy Agent) permiten la redacción y aplicación de políticas completamente personalizables.
‘
Estas políticas gobiernan desde los privilegios de acceso hasta permitir o denegar el uso de dependencias de código abierto basadas en criterios como proveedor, versión, URL del paquete y licencia.
Sea capaz de Verificar y Asegurar la Confianza en sus Artefactos de Software utilizando SLSA
¿Cómo pueden los usuarios y consumidores saber si un software es digno de confianza? Para determinar la confiabilidad de un artefacto de software, querría saber cosas como quién escribió el código, quién lo construyó y en qué plataforma de desarrollo se construyó. También querría saber qué componentes hay en él.
Tomar una decisión sobre si confiar en el software es posible una vez que se puede verificar la procedencia, el registro de los orígenes de un software y la cadena de custodia. Para esto, se creó el marco de Niveles de la Cadena de Suministro para Artefactos de Software (SLSA).
‘
Proporciona a las organizaciones productoras de software la capacidad de capturar información sobre cualquier aspecto de la cadena de suministro de software, verificar propiedades de los artefactos y su compilación, y reducir el riesgo de problemas de seguridad. En la práctica, es esencial que las organizaciones productoras de software adopten y cumplan con los requisitos del marco SLSA e implementen un medio para verificar y generar certificaciones de software, que son declaraciones autenticadas (metadatos) sobre los 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, las directrices anteriores apenas tocan la superficie. Pero, al igual que todo en el mundo de la construcción e implementación de aplicaciones modernas, la práctica está evolucionando rápidamente. Para ayudarlos a comenzar, les 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.
Vía The Hacker News
