El 22 de marzo, NIST lanzó la versión final del SSDF 1.1 (marco de desarrollo de software seguro).
El marco se publicó inicialmente en septiembre de 2021 como versión borrador. Todas las prácticas y tareas de alto nivel siguen siendo las mismas y muchas de las diferencias se centran en los diversos ejemplos proporcionados.
¿Qué es el marco NIST SP 800-218? El SSDF consolida recomendaciones de mejores prácticas de larga data para el desarrollo de software seguro. Su enfoque personalizable e independiente del sector está diseñado para facilitar las comunicaciones entre departamentos (y entre productores y adquirentes) para ayudar a definir objetivos estratégicos y evaluar las brechas actuales.
NIST recomienda equilibrar el riesgo con el costo, la viabilidad y la aplicabilidad al decidir qué prácticas implementar. La automatización es una característica clave a considerar con el objetivo deseado de automatizar la mayor cantidad posible de comprobaciones y procesos que promuevan la seguridad del software.
Diferencias entre la versión final y borrador:
Verificación de integridad – Cuando se habla de vulnerabilidades, se presta más atención a la verificación de la integridad. al mirar tanto su código como las bibliotecas/productos adquiridos de fuentes externas.
Certificados inmutables – La responsabilidad de implementar las prácticas puede distribuirse entre diferentes organizaciones, especialmente si se considera la complejidad de las cadenas de suministro de software. La visibilidad disminuye significativamente cuanto más arriba o abajo se avanza en la cadena. Es por eso que el NIST recomienda codificar la responsabilidad compartida que involucra tanto a los proveedores como a los consumidores de una plataforma/servicio en un contrato o acuerdo. Debe quedar claro quién es responsable de cada práctica y tarea y cómo cada proveedor dará fe de su conformidad con el acuerdo. El axioma de "confiar pero verificar" es válido aquí: certificaciones inmutables que puedan compartirse fácilmente entre los productores de software y los adquirentes de software son clave para aumentar la confianza de todas las partes interesadas en la cadena de suministro de software.
Participación de la comunidad de código abierto – NIST afirma que el trabajo futuro probablemente tomará la forma de casos de uso específicos y que tiene la intención de colaborar con la comunidad de código abierto. Teniendo en cuenta que la mayoría de los productos de código comercial que se utilizan hoy en día incluyen importantes elementos de código de fuente abierta, es natural incluir a la comunidad de código abierto en la planificación e implementación de la seguridad del ciclo de vida del software.
Puntuaciones de gravedad de la vulnerabilidad como KRI (indicador clave de riesgo) – Otro cambio que está surtiendo efecto son las puntuaciones de gravedad como indicador clave. Sabiendo que gran parte del personal de seguridad cibernética sufre fatiga de alerta, tiene sentido que cada organización defina la escala de puntuación de vulnerabilidad adecuada para ella y el tratamiento específico que merece cada puntuación.
Menos acceso humano, más automatización – NIST fomenta minimizar el acceso humano directo a los sistemas de cadena de herramientas, como los servicios de construcción. Cuanta más gente tenga acceso, más errores podrían ocurrir. Esto, nuevamente, está en la misma línea que la recomendación de una mayor automatización.
SBOM con integridad – Cuando se habla de la SBOM (Lista de materiales de software), NIST recomienda emplear una protección sólida para la integridad del artefacto, además de proporcionar una forma para que los destinatarios verifiquen esa integridad. Los destinatarios pueden ser personas tanto de dentro como de fuera de la organización, por lo que tiene sentido emplear un sistema de terceros para compartir SBOM seguros.
Integridad binaria vs código fuente – Si no se puede confirmar la integridad o procedencia de los binarios adquiridos, se sugiere construir esos binarios nuevamente a partir del código fuente. Eso supone que puede verificar la integridad y procedencia del código fuente. Es responsabilidad de todos los eslabones de la cadena de suministro de software proporcionar pruebas verificables de integridad, a través de firmas digitales u otros mecanismos como un SBOM.
Resum
En general, el NIST considera que “las prácticas, tareas y ejemplos de implementación del SSDF representan un punto de partida a considerar. Deben cambiarse, personalizarse y evolucionar con el tiempo”.
El SSDF no es una lista de verificación que deba seguir, sino que proporciona orientación para planificar e implementar un enfoque basado en riesgos para el desarrollo de software seguro.
A diferencia de las regulaciones basadas en leyes estadounidenses, el SSDF se basará en los negocios: el gobierno aprovechará su poder adquisitivo para lograr que el mercado se adhiera a este nuevo marco de mejores prácticas. Si no puede demostrar cumplimiento del marco, no será considerado para contratos gubernamentales. Es probable que veamos un efecto de goteo en el que las organizaciones que estén considerando solicitar contratos gubernamentales exigirán que todos sus vendedores y proveedores también cumplan, y así sucesivamente a lo largo de la cadena de suministro de software.
Para obtener más información sobre las nuevas regulaciones y SSDF, consulte nuestro seminario web en “Desmitificando las nuevas regulaciones de ciberseguridad en 2022”.
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
