Navegar por las amenazas de la cadena de suministro de código abierto: Protección de su ecosistema de software
En el mundo empresarial actual, las empresas están decididas a crear software más rápido que nunca. Los desarrolladores están sometidos a una inmensa presión para entregar rápidamente los productos a los clientes. Para acelerar este proceso, los desarrolladores recurren a menudo a "bloques de construcción" prefabricados: componentes de código abierto. Esto significa que el software moderno suele ensamblarse a partir de piezas ya existentes, en lugar de construirse por completo desde cero. Las empresas suelen mezclar varios componentes de código abierto para crear un único producto, personalizándolo con su código exclusivo según sea necesario, y así terminan el trabajo.
Según Forresterel uso del código abierto en el desarrollo de software ha crecido significativamente, pasando del 36% en 2016 al 78% en 2021. Y sigue haciéndose más popular. Aunque el uso de estas soluciones ya preparadas hace que el proceso sea más eficiente, también conlleva vulnerabilidades potenciales. Si los adversarios logran comprometer estas bibliotecas integradas, podrían controlar todo el proceso de entrega de software, poniendo en peligro todo el proyecto. Es lo que se denomina una amenaza a la cadena de suministro.
Hablemos de la magnitud del problema y de cómo hacerlo más seguro.
¿Por qué los piratas informáticos atacan el código abierto?
Bueno, los proyectos de código abierto suelen ser creados por grupos de personas que realmente aman lo que hacen: desarrolladores que trabajan juntos en algo que les importa. El software de código abierto suele ser gratuito y puede utilizarse en distintos tipos de sistemas. Las empresas tienen libertad para utilizarlo y adaptarlo a sus productos. Como estos proyectos implican a mucha gente trabajando junta, a veces los malos pueden utilizarlos para cosas malas.
Los repositorios de proyectos de código abierto invitan con frecuencia a los desarrolladores a añadir actualizaciones y nuevas funciones, lo que significa que cualquier usuario, incluidos los agentes maliciosos, puede introducir su propio código en la plataforma. Muchas comunidades relajan los controles sobre los nuevos miembros una vez establecida la confianza. En consecuencia, un atacante puede contribuir inicialmente de forma constructiva y más tarde colar código malicioso sin ser advertido.
Los piratas informáticos suelen emplear amenazas de código abierto para la cadena de suministro porque les resulta más fácil que dirigirse directamente a objetivos concretos, como los servidores de los bancos, e intentar burlar su seguridad. Para entrar en el sistema informático de un banco, un atacante puede explotar una vulnerabilidad en una biblioteca de código abierto que utiliza el banco. Esto les permite colarse por una "puerta trasera" sin demasiados problemas. Si el banco identifica el ataque con prontitud y toma medidas, aún puede afectar a otras empresas que utilicen la misma biblioteca, dando lugar a un ataque a gran escala en la cadena de suministro.
Amenazas para la cadena de suministro de software
Los ataques a la seguridad de la cadena de suministro de software están causando furor en el ecosistema del software de código abierto, acaparando más atención y provocando mayores trastornos. Los investigadores de la empresa de seguridad de aplicaciones Synopsys investigaron y encontraron al menos una vulnerabilidad de código abierto conocida en el 84% de las bases de código. Según el 9º informe anual de Sonatype de Sonatype sobre el estado de la cadena de suministro de softwarese ha triplicado el número de paquetes maliciosos de código abierto con respecto al informe del año anterior.
Todo esto demuestra que la cadena de suministro de software se ha convertido en uno de los vectores de más rápido crecimiento para que los actores de amenazas ejecuten código malicioso. Veamos rápidamente algunas herramientas que pueden ayudar a mantener seguro el software mientras se fabrica.
Herramientas de análisis de la composición del software (SCA)
Las herramientas SCA, que utilizan un archivo de ensamblaje de la aplicación, analizan automáticamente la base de código (incluidos los artefactos asociados), generan una lista de bibliotecas y componentes de terceros utilizados en el software y buscan vulnerabilidades. Además, estos escáneres pueden comprobar si los elementos de código abierto cumplen los requisitos de licencia.
Básicamente, estas herramientas comprueban si existe una versión más reciente de una pieza de software y si hay problemas conocidos con ella que se hayan hecho públicos.
Lista de materiales de software (SBOM)
SBOM es una lista de elementos de código abierto y de terceros utilizados en la base de código del software. Contiene información técnica sobre todos los componentes y sus relaciones entre sí. SBOM también puede incluir información breve sobre el nombre del componente, versión, licencia, vulnerabilidades, dependencias transitivas, etc.
Los programas SBOM le ayudan a identificar y mitigar vulnerabilidades mediante el seguimiento de los componentes de código, la gestión de licencias de software y la mejora del ciclo de vida de desarrollo de software (SDLC). La primera etapa de la creación de un programa consiste en implementar herramientas de SCA y otros analizadores que puedan integrarse perfectamente en la canalización de CI/CD.
Marco de niveles de la cadena de suministro para artefactos de software (SLSA)
Este marco fue lanzado por Google en colaboración con la Open Source Security Foundation (OpenSSF). SLSA contiene una lista de normas y directrices para proteger contra el acceso no autorizado y garantizar la integridad de los artefactos de software en las cadenas de suministro. SLSA muestra claramente qué partes de la cadena de suministro son susceptibles de sufrir vulnerabilidades.
Fuente: https://slsa.dev/spec/v1.0/threats-overview
Antes de utilizar cualquier dependencia, debemos asegurarnos de que procede de una fuente de confianza. Para que se considere de confianza, una fuente debe confirmar que su biblioteca cumple todos los requisitos establecidos y no contiene ninguna carga útil que pueda perjudicar a quienes la utilicen. Lo ideal sería disponer de la llamada procedencia: información adicional sobre el origen de un artefacto, que puede utilizarse para rastrear desde el principio quién, dónde, cuándo y cómo se creó algo.
Para seguir este principio, SLSA introduce 4 niveles de seguridad: desde el primer nivel, que implica una ausencia total de garantías, hasta el cuarto, que proporciona el mayor grado de confianza.
Nivel | Descripción |
0 | Sin garantías |
1 | Documentación del proceso de creación |
2 | Resistencia a la manipulación del servicio de construcción |
3 | Mayor resistencia a amenazas específicas |
4 | Máxima confianza |
Cada nivel contiene requisitos para la fuente del código (Source), el proceso de ensamblaje (Build), así como información adicional sobre el origen de los artefactos (Provenance).
Repositorio fiable de componentes de código abierto verificados
Disponer de un repositorio de confianza para componentes de código abierto, que se actualizan constantemente, se prueban y se examinan contra vulnerabilidades, puede reducir significativamente la carga de los desarrolladores. Al garantizar que siempre se dispone de las versiones correctas de las bibliotecas, se pueden mitigar los riesgos asociados a las dependencias.
Esto es lo que hace TuxCare SecureChain para Java de TuxCare. El proceso de proceso de selección de SecureChain le permite aprovechar las mejores y más seguras bibliotecas de uso común para sus aplicaciones. Esto reduce el tiempo dedicado a las actualizaciones manuales y el riesgo de incorporar una biblioteca con posibles vulnerabilidades.
SecureChain le ofrece la tranquilidad de saber que su cadena de suministro de software es segura, lo que le permite centrarse más en crear y mejorar sus aplicaciones.
Una puerta para los atacantes, pero no un callejón sin salida
El código abierto puede ser una puerta de entrada para que los atacantes pongan en peligro a muchas empresas. No todas las organizaciones pueden detectar rápidamente las amenazas a la cadena de suministro de código abierto. Los atacantes ocultan sus acciones y utilizan técnicas engañosas, como explotar debilidades en la configuración de la gestión de paquetes o piratear repositorios. Sin embargo, estas amenazas no deberían hacernos evitar por completo el código abierto. Por el contrario, empujan a las empresas a elegir los componentes de código abierto con más cuidado y a mejorar sus medidas de seguridad.


