Los riesgos del uso de código abierto continúan amenazando la estabilidad de negocios digitales. Los incidentes de la cadena de suministro de software como Log4j y Spring4Shell, han puesto en riesgo a miles de millones de dispositivos de sufrir ataques de ejecución por control remoto. No solo eso, sino que una multitud de otras vulnerabilidades yacen latentes, conocidas o desconocidas, dentro de la raíz de las aplicaciones de software modernas que dependen en gran medida de innumerables proyectos de código abierto. Como resultado, los estudios han encontrado un aumento anual promedio extraordinario del 742 % en los ataques a la cadena de suministro durante los últimos tres años.
En respuesta a este problema de ampliación de la cadena de suministro de software , las organizaciones están comenzando a estandarizar su proceso de consumo de software y administrar mejor las dependencias. También hay un ímpetu liderado por el gobierno ee Estados Unidos para evolucionar: parte de la Orden ejecutiva presidencial de 2021 sobre la mejora de la ciberseguridad de la nación requiere que las empresas de software que trabajan con el gobierno de EE. UU. proporcionen una lista de materiales de software (SBOM) que enumere las dependencias del proyecto en cuestión.
El informe ‘El estado de la cadena de suministro de software’ de Sonatype proporciona datos fascinantes sobre la amenaza de la cadena de suministro de software global. El extenso informe calcula las vulnerabilidades en los administradores de paquetes populares y sopesa la madurez de la respuesta de seguridad a los riesgos apremiantes. A continuación, resumiré los puntos clave del estudio para comprender mejor cómo las divisiones de tecnología de la información (TI) deben abordar la seguridad de código abierto frente a la cadena de suministro de software interconectada actual.
La demanda de código abierto aumenta, al igual que las vulnerabilidades
La creación y descargas de proyectos de código abierto han alcanzado máximos históricos. Por ejemplo, el informe encontró 396,000 proyectos de Python dentro del ecosistema PyPI, con un crecimiento de descargas del 33% interanual. Se estima que el volumen total de solicitudes en 2022 será de 3,1 billones. Esta cifra representa la cantidad acumulada de descargas en los principales administradores de paquetes de código abierto Java (Maven), JavaScript (npm), Python (PyPI) y .NET (NuGet).
Aunque 2022 vio el mayor volumen de descargas de código abierto, hubo una ligera disminución en la aceleración de la adopción y el uso de código abierto. Esto quizás se deba a las nuevas políticas de adquisiciones que surgieron en respuesta a Log4j. Es bueno que las organizaciones se estén dando cuenta de la realidad de las amenazas relativas al uso de código abierto, especialmente desde que Sonatype descubrió 97,334 paquetes maliciosos sospechosos en sus procesos de monitoreo.
Sin embargo, la falta de conocimiento y visibilidad de las dependencias sigue siendo un problema apremiante. Seis de cada siete vulnerabilidades de proyectos provienen de dependencias transitivas, que son componentes adicionales de los que depende una herramienta de software para funcionar, pero que no siempre son accesibles. La confusión de dependencia puede surgir de tácticas como el typosquatting o el brandjacking. O bien, las dependencias legítimas de código abierto pueden incluir, sin saberlo, inyecciones de código aportadas por actores con malas intenciones.
Otras métricas de la cadena de suministro de software
Entonces, ¿cuál es el estado de los proyectos individuales? Bueno, las bibliotecas comunes tienen 5,7 dependencias en promedio. Aunque solo el 10 % de estos tienen una vulnerabilidad que afecta directamente al código, el 62 % tenía un problema de seguridad directo o una vulnerabilidad transitiva derivada de su árbol de dependencia de terceros. En general, este hecho significa que cada mes se consumen 1200 millones de dependencias vulnerables.
Una muestra aleatoria de 55,000 aplicaciones empresariales reveló que 68 de las aplicaciones tenían vulnerabilidades conocidas en los componentes subyacentes del software de código abierto. Sin embargo, probablemente se trate de datos incompletos, ya que es complicado resumir el panorama total de vulnerabilidad. Dado que los piratas informáticos apuntan a bibliotecas populares en proyectos más especializados o inactivos, los proyectos populares tienen más vulnerabilidades conocidas, no vulnerabilidades inherentes.
Realmente hay una amplia superficie que cubrir, y el árbol de dependencias es interminable. Sorprendentemente, los ingenieros tienen que realizar un seguimiento de una media de 1500 cambios de dependencia al año por aplicación. Esto subraya la necesidad de SBOM (Software Bill Of Materials), así como un enfoque automatizado para auditar las dependencias.
Regulaciones globales para la integridad de la cadena de suministro de software maduro
La seguridad de la cadena de suministro de software aún se encuentra en un proceso de maduración. La mayoría de las empresas aún no catalogan los SBOM ni realizan la corrección de cada vulnerabilidad. Sin embargo, se están realizando avances para formalizar este proceso, y gran parte del futuro de la seguridad de la cadena de suministro podría estar dirigido por la regulación.
Por ejemplo, en enero de 2022, la Oficina de Administración y Presupuesto (OMB, por sus siglas en inglés) emitió el Memorándum: “Moving the US Government Toward Zero Trust Cybersecurity Principles”, alentando la alineación con los cinco puntos de confianza cero de la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA, por sus siglas en inglés).
Otro ejemplo de nueva regulación: “Cuando una agencia federal (comprador) adquiere software o un producto que contiene software, la agencia debe recibir un certificado del productor de software de que el desarrollo del software cumple con las prácticas de desarrollo de software seguras especificadas por el gobierno”. — Guía de seguridad de la cadena de suministro de software según la orden ejecutiva (EO) 14028, NIST (Instituto Nacional de Estándares y Tecnología)
Otros países han seguido su ejemplo, aunque con menos condiciones obligatorias. Por ejemplo, Alemania emitió recientemente la Ley de Seguridad de la Información 2.0 (IT-SiG) y Japón aprobó una Ley de Promoción de la Seguridad Económica mediante la Implementación Integrada de Medidas Económicas. Se han visto proclamaciones similares para combatir los riesgos de la cadena de suministro de agencias como la Agencia Europea para la Seguridad Cibernética (ENISA) y la OTAN.
Perspectivas futuras
A medida que aumenta la dependencia digital, es probable que la cantidad de vulnerabilidades continúe creciendo y, junto con ella, la frecuencia de los ataques al software empresarial. El treinta y uno por ciento de las empresas estima que un ataque cibernético ocurre al menos una vez a la semana. Estos ataques podrían resultar en ataques de ransomware, cryptojacking o grandes campañas de denegación de servicio.
Gran parte del área de superficie del software aún no se ha descubierto. El informe encontró que solo el 7% de las empresas han analizado su cadena de suministro más amplia. Será necesario compartir conocimientos para mejorar las prácticas de seguridad en el desarrollo. También requerirá un esfuerzo coordinado de la comunidad de código abierto para democratizar el acceso a las herramientas de seguridad necesarias. Por ejemplo, los estándares emergentes como Sigstore y SLSA (niveles de cadena de suministro para artefactos de software) están configurados para agregar nuevas capas para proteger la procedencia de los paquetes de código abierto.
“Esta tasa de crecimiento anual promedio durante los últimos tres años es asombrosa y subraya la necesidad de intensificar los esfuerzos gubernamentales e impulsados por la industria para frenar y defenderse de estos ataques”, dice el informe.
Para obtener más información y un análisis más profundo de cómo se generaron estos datos, los lectores pueden ver el 8º informe anual completo sobre el estado de la cadena de suministro de software, presentado por Sonatype.
Artículo original aquí
Autor: Bill Doerrfeld
