Justo cuando los desarrolladores y los equipos de seguridad se preparaban para tomar un respiro y encender la barbacoa para el fin de semana festivo, las agencias de seguridad más prestigiosas de los EE. UU. (NSA, CISA y ODNI) lanzaron una guía práctica recomendada de más de 60 páginas, Asegurando el suministro de software Cadena para Desarrolladores .
¡Es genial! fue mi primera reacción al ver que estas agencias se suman al discurso público en los que todos estamos trabajando en las mejores prácticas de seguridad de la cadena de suministro de software. Esta es una voz importante para resaltar los muchos requisitos, marcos, mejores prácticas, y los felicito por compartir algunas de las lecciones aprendidas con tanto esfuerzo.
Pero creo que también es importante para los desarrolladores en general sopesar lo que tiene sentido en los entornos de seguridad nacional más extraordinariamente sensibles frente a lo que tiene sentido para el desarrollador empresarial, promedio y el equipo de seguridad.
Esto es lo que me llamó la atención como las implicaciones buenas, malas y feas del informe.
Lo bueno
Hay algunas recomendaciones prescriptivas excelentes en el informe en las que estas agencias abogan por marcos específicos como los Niveles de cadena de suministro para artefactos de software (SLSA, pronunciado “salsa”) y el Marco de desarrollo de software seguro (SSDF). El informe menciona estos marcos 14 y 38 veces, respectivamente para los desarrolladores y equipos de seguridad que se dan cuenta de que tienen un problema de seguridad en la cadena de suministro de software pero no saben por dónde empezar, ahora tienen un camino claro para dar sus primeros pasos.
El resultado de estos marcos es que brindan a los desarrolladores una guía clara sobre (1) cómo desarrollar código seguro, desde problemas de diseño hasta problemas de estructura organizacional para un software más seguro; (2) integridad del sistema de compilación (asegurarse de que no se inyecte código malicioso en nuestros sistemas de compilación); y (3) qué sucede después de que se construye el software y cómo operar la seguridad de los sistemas (remediación de vulnerabilidades, monitoreo, ese tipo de aspectos).
También creo que el informe hace un excelente trabajo al enfatizar lo que la firma de software compra a los desarrolladores en términos de seguridad de artefactos, y cómo al invertir en firmar y verificar al comienzo del ciclo de vida del desarrollo de software, puede ahorrarse mucho trabajo. tener que preocuparse por la seguridad de los administradores de paquetes más adelante.
Lo malo
La guía sugiere que “todos los sistemas de desarrollo deben restringirse únicamente a las operaciones de desarrollo”… y continúa diciendo que “ninguna otra actividad, como el correo electrónico, debe realizarse para uso comercial o personal”.
No puedo ver un futuro en el que se les diga a los desarrolladores que no pueden usar Slack, correo electrónico y navegación web en sus máquinas de desarrollo, y aquí hay un ejemplo en el que lo que es obligatorio en entornos con brechas de aire como la NSA realmente no se asigna a la corriente principal escenarios de desarrollador.
También encuentro que la guía SBOM tiene excelentes puntos pero también pierde amenazas concretas y ejemplos de mitigación. En general, la industria continúa diciéndoles a todos que usen SBOM pero realmente no explica qué hacer con ellos o cuáles son los beneficios reales. Y aunque me gusta la guía para comparar los SBOM con los resultados del análisis de composición de software (SCA), la realidad es que los escáneres de vulnerabilidades actuales pasan por alto muchas de las dependencias transitivas que hacen que las cadenas de suministro de software sean una superficie de amenaza atractiva en primer lugar.
Lo feo
Si bien el código abierto se menciona 31 veces en la guía, en su mayoría son referencias superficiales, sin nuevas recomendaciones. Todos sabemos que la mayoría del código fuente que se usa hoy en día es de código abierto y tiene aspectos únicos de seguridad: el informe no presta atención a cómo elegir qué proyectos de código abierto usar, qué buscar al decidir sobre una nueva dependencia, enfoques para los sistemas de puntuación o cómo saber el estado de seguridad de un proyecto OSS.
Hay bastante sobrecarga de información. La mitad del documento explica cuáles son sus contenidos, y la otra mitad presenta un par de marcos y las intersecciones de esos marcos. Creo que lo que vamos a ver a continuación es un maremoto de blanqueamiento de productos de proveedores de seguridad, afirmando tener las primeras capacidades que se ajustan a estas pautas, pero es importante recordar que no hay un proceso de acreditación y la mayor parte de esto simplemente será presunción de marketing.
La seguridad de la cadena de suministro de software es bastante única: tiene muchos tipos diferentes de ataques que pueden apuntar a muchos puntos diferentes en el ciclo de vida del software. No puede simplemente tomar una pieza de software de seguridad, encenderla y protegerse de todo.
Las guías y recomendaciones como esta que provienen de las organizaciones más sofisticadas que han pasado por los primeros pasos brindan muchas pistas excelentes para los desarrolladores en general, espero que la NSA/CSA/ODNI continúe divulgando este tipo de información eh incluso si puede requerir alguna decodificación de lo que se aplica a escenarios de desarrolladores más convencionales fuera del Pentágono.
Es un conocido experto en seguridad móvil y análisis de malware. Estudió Ciencias de la Computación en la NYU y comenzó a trabajar como analista de seguridad cibernética en 2003. Trabaja activamente como experto en antimalware. También trabajó para empresas de seguridad como Kaspersky Lab. Su trabajo diario incluye investigar sobre nuevos incidentes de malware y ciberseguridad. También tiene un profundo nivel de conocimiento en seguridad móvil y vulnerabilidades móviles.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
