Con tanta incógnita sobre en qué confían sus desarrolladores y sistemas para ser productivos, y en qué dependen a su vez esas herramientas y bases de código, es hora de tomarse en serio la seguridad de su cadena de suministro de software.
Una de las razones por las que el código abierto es popular en la empresa es que proporciona componentes básicos bien probados que pueden acelerar la creación de aplicaciones y servicios sofisticados. Pero los componentes de software de terceros y la conveniencia de los paquetes y contenedores conllevan riesgos junto con los beneficios porque las aplicaciones que crea son tan seguras como esas dependencias.
Los ataques a la cadena de suministro de software se están generalizando tanto que Gartner los catalogó como la segunda mayor amenaza para 2022.
Para 2025, la firma de investigación predice que el 45% de las organizaciones en todo el mundo habrán experimentado uno o más ataques a la cadena de suministro de software, y el 82% de los CIO creen que serán vulnerables a ellos.
Estos incluyen ataques a través de vulnerabilidades en componentes de software ampliamente utilizados como Log4j, ataques contra la canalización de compilación (cf, SolarWinds, Kaseya y Codecov hacks) o piratas informáticos que comprometen los propios repositorios de paquetes.
“Los atacantes han cambiado la prioridad de los entornos de producción a las cadenas de suministro de software porque las cadenas de suministro de software son el eslabón más débil”, explica Lior Levy, director ejecutivo de Cycode. “Mientras las cadenas de suministro de software sigan siendo objetivos relativamente fáciles, los ataques a la cadena de suministro de software aumentarán”.
Los recientes incidentes de alto perfil han sido una llamada de atención para la industria del desarrollo de software, señala Rani Osnat, vicepresidente senior de estrategia de Aqua Security. “Hemos descubierto décadas de opacidad y falta de transparencia y es por eso que es tan importante”.
Los estudios de bases de código que usan código fuente abierto muestran que las vulnerabilidades y los componentes desactualizados o abandonados son comunes: el 81% de las bases de código tenía al menos una vulnerabilidad, el 50% tenía más de una vulnerabilidad de alto riesgo y el 88% usaba componentes que no eran la última versión o no tenían ningún nuevo desarrollo en dos años.
Sin embargo, es poco probable que estos problemas afecten la popularidad del código abierto, y el software y los servicios comerciales también son vulnerables. Cuando LastPass fue atacado, no perdió los datos del cliente, pero una parte no autorizada pudo ver y descargar parte de su código fuente, lo que podría facilitar el ataque a los usuarios del administrador de contraseñas en el futuro, y la violación de Twilio permitió a los atacantes. para lanzar ataques a la cadena de suministro en organizaciones aguas abajo.
La amenaza del ‘código sombra’
Así como los equipos de seguridad defienden sus redes como si ya hubieran sido violadas, los CIO deben asumir todo el código, interno o externo, e incluso los entornos de desarrollo y las herramientas que usan sus desarrolladores ya se han visto comprometidos y deben implementar políticas para protegerse y minimizar el impacto de los ataques. contra sus cadenas de suministro de software.
De hecho, Osnat sugiere que los CIO piensen en este “código en la sombra” de la misma manera que lo hacen con la TI en la sombra. “Esto debe verse como algo que no es sólo un problema de seguridad, sino algo que realmente profundiza en cómo obtiene el software, ya sea de código abierto o comercial: cómo lo trae a su entorno, cómo lo actualiza, qué tipo de controles que desea tener y qué tipo de controles desea exigir de sus proveedores”, afirma.
Transparencia: Hacia una lista de materiales de software
Las cadenas de suministro físicas ya usan etiquetas, listas de ingredientes, hojas de datos de seguridad y listas de materiales para que los reguladores y los consumidores sepan qué termina en los productos. Las nuevas iniciativas apuntan a aplicar enfoques similares al software, ayudando a las organizaciones a comprender la red de dependencias y la superficie de ataque de su proceso de desarrollo de software.
La orden ejecutiva 14028 de la Casa Blanca sobre seguridad de la cadena de suministro de software requiere que los proveedores de software que suministran al gobierno federal proporcionen una lista de materiales de software (SBOM) y utilicen la lista de verificación de seguridad de niveles de cadena de suministro para artefactos de software (SLSA) para evitar la manipulación. Debido a esto, “vemos que muchas empresas analizan con más seriedad su cadena de suministro de software”, asevera Janet Worthington, analista sénior de Forrester. “Todas las empresas hoy en día producen y consumen software y vemos que más productores se acercan a nosotros y nos preguntan: ‘¿Cómo produzco software que sea seguro y del que pueda dar fe con una lista de materiales de software?’”.
Existen numerosos proyectos intersectoriales, incluida la Iniciativa nacional para mejorar la ciberseguridad en las cadenas de suministro ( NIICS ) del NIST, la iniciativa Integridad, transparencia y confianza de la cadena de suministro ( SCITT ) de Microsoft y otros miembros del IETF, así como la Integridad de la cadena de suministro de OpenSSF. Grupo de trabajo.
“Todo el mundo está adoptando un enfoque más holístico y diciendo, espera un minuto, necesito saber lo que estoy trayendo a mi cadena de suministro con lo que estoy creando el software”, dice Worthington.
Una encuesta reciente de la Fundación Linux encontró que el conocimiento de SBOM es alto, ya que el 47% de los proveedores de TI, los proveedores de servicios y las industrias reguladas usan SBOM en la actualidad y el 88% espera usarlos en 2023.
Los SBOM serán más útiles para las organizaciones que ya cuentan con gestión de activos para componentes de software y API. “A las personas que tienen procesos sólidos de desarrollo de software hoy en día les resulta más fácil incorporar herramientas que puedan generar una lista de materiales de software”, opina Worthington.
Los SBOM pueden ser creados por el sistema de construcción, o pueden ser generados por herramientas de análisis de composición de software después del hecho. Muchas herramientas pueden integrarse en las canalizaciones de CI/CD y ejecutarse como parte de una compilación, o incluso cuando extrae bibliotecas, apunta. “Puede advertirle: ‘Oye, tienes este componente en tu canalización y tiene un problema crítico, ¿quieres continuar?’”
Para que eso sea útil, necesita políticas claras sobre cómo los equipos de desarrolladores adquieren software de código abierto, opina el CEO de Chainguard, Dan Lorenc. “¿Cómo saben los desarrolladores cuáles son las políticas de su empresa para lo que se considera ‘seguro’ y cómo saben que el código abierto que están adquiriendo, que constituye la gran mayoría de todo el software que utilizan los desarrolladores en estos días, no está manipulado?”
Señala el proyecto de código abierto Sigstore que utilizan JavaScript, Java, Kubernetes y Python para establecer la procedencia de los paquetes de software. “Sigstore es para la integridad del software algo así como los certificados para los sitios web; básicamente establecen una cadena de custodia y un sistema de verificación de confianza”, afirma.
“Creo que un CIO debería comenzar por adoctrinar a sus equipos de desarrolladores en estos pasos fundamentales de usar enfoques estándar emergentes de la industria para uno, bloquear los sistemas de compilación y dos, crear un método repetible para verificar la confiabilidad de los artefactos de software antes de llevarlos al entorno”, apunta Lorenc.
Haciendo la contribución
Ya se trate de componentes, API o funciones sin servidor, la mayoría de las organizaciones subestiman lo que están usando en un orden de magnitud a menos que ejecuten inventarios de rutina, señala Worthington. “Descubrieron que algunas de estas API no están utilizando métodos de autenticación adecuados o tal vez no están escritas de la manera que esperaban y tal vez algunas de ellas incluso estén obsoletas”.
Más allá de las vulnerabilidades, evaluar el soporte de la comunidad detrás de un paquete es tan importante como comprender lo que hace el código porque no todos los mantenedores quieren la carga de que su código sea tratado como un recurso crítico . “No todo el código abierto está hecho de la misma manera”, advierte.
“El código abierto puede ser de descarga gratuita, pero ciertamente su uso no es gratuito. Su uso significa que usted es responsable de comprender la postura de seguridad detrás de él, porque está en su cadena de suministro. Tienes que contribuir a ello. Sus desarrolladores deben participar en la reparación de vulnerabilidades”, dice Worthington, quien sugiere que las organizaciones también deben estar preparadas para contribuir monetariamente, ya sea directamente a proyectos de código abierto o a iniciativas que los apoyen con recursos y fondos. “Cuando creas una estrategia de código abierto, parte de eso es comprender el presupuesto y las implicaciones”.
No piense en eso sólo como un gasto, sino como una oportunidad para comprender mejor los componentes de los que depende. “Incluso ayuda a retener a los desarrolladores porque sienten que son parte de la comunidad. Están siendo capaces de contribuir con sus habilidades. Pueden usar esto en su currículum”, agrega.
Recuerde que las vulnerabilidades se pueden encontrar en cualquier lugar de su pila de tecnología, incluidos los mainframes, que cada vez más ejecutan Linux y código abierto como parte de la carga de trabajo, pero a menudo carecen de los procesos y marcos de seguridad que se han vuelto comunes en otros entornos.
Protegiendo su tubería
También es importante proteger su tubería de entrega de software. El marco de desarrollo de software seguro (SSDF) y SLSA de NIST es un buen lugar para comenzar: cubre las mejores prácticas en varios niveles de madurez, comenzando con un sistema de compilación simple, luego usando registros y metadatos para auditoría y respuesta a incidentes hasta una canalización de compilación totalmente segura. El libro blanco de mejores prácticas de la cadena de suministro de software de CNCF, la guía de Gartner sobre la mitigación de los riesgos de seguridad de la cadena de suministro de software y el marco de trabajo seguro de la cadena de suministro de OSS de Microsoft, que incluye procesos y herramientas, también son útiles.
Sin embargo, es importante tener en cuenta que el simple hecho de activar las herramientas de escaneo automático destinadas a encontrar código malicioso puede producir demasiados falsos positivos para ser útil. Y aunque los sistemas de control de versiones como BitBucket, GitHub, GitLab y otros incluyen funciones de seguridad y protección de acceso (incluidos controles de políticas de acceso cada vez más granulares , protección de sucursales, firma de código, requisito de MFA para todos los colaboradores y escaneo de secretos y credenciales), a menudo tienen que estar habilitados explícitamente.
Además, los proyectos como Factory for Repeatable Secure Creation of Artifacts ( FRSCA ) que tienen como objetivo proteger las canalizaciones de construcción mediante la implementación de SLSA en una sola pila aún no están listos para la producción, pero los CIO deben esperar que los sistemas de construcción incluyan más de estas prácticas en el futuro.
De hecho, si bien los SBOM son solo una parte de la respuesta, las herramientas para crearlos y trabajar con ellos también están madurando, al igual que los procesos para solicitarlos y consumirlos. Los contratos deben especificar no solo que desea SBOM, sino también con qué frecuencia espera que se actualicen y si incluirán informes y notificaciones de vulnerabilidad, aconseja Worthington. “Si se encuentra una nueva vulnerabilidad importante como Log4j, ¿el proveedor me lo dirá o tendré que buscar yo mismo en el SBOM para ver si estoy afectado?”
Las organizaciones también necesitarán herramientas para leer SBOM y poner en marcha procesos para tomar medidas sobre lo que encuentran estas herramientas. “Necesito una herramienta que pueda decirme cuáles son las vulnerabilidades conocidas [en el SBOM], cuáles son las implicaciones de la licencia y si eso sucede continuamente”, señala Worthington.
Los CIO deben tener en cuenta que un SBOM “es un facilitador, pero en realidad no resuelve nada en términos de seguridad de su cadena de suministro. Lo ayuda a hacer frente a los incidentes que se le presenten”, dice Osnat, quien es optimista sobre la velocidad de respuesta de la industria y la amplia colaboración que se está produciendo en torno a los estándares para SBOM y la atestación de código que ayudará a que las herramientas sean interoperables (algo que las organizaciones plantearon). como una preocupación particular en la investigación de la Fundación Linux). Eso podría conducir a las mismas mejoras en los estándares de transparencia e informes en toda la industria que entregó SOC 2.
Dicho esto, los CIO no tienen que esperar a nuevos estándares o herramientas para comenzar a hacer que la seguridad sea una parte tan importante del rol del desarrollador como lo ha sido la calidad en los últimos años, dice Osnat. Su sugerencia: “Comience reuniendo a su CISO y al ingeniero principal en una sala para descubrir cuál es el modelo correcto para que funcione para su organización y cómo se producirá esa transformación”.
Mary Branscombe, CIO.com
