La creación de productos o aplicaciones de software seguros en esta era requiere un conocimiento completo de los componentes exactos de la aplicación que está creando. Las dependencias, licencias, archivos y otros activos que componen su paquete de software son puntos potenciales de vulnerabilidad a través de los cuales actores malintencionados pueden lanzar un ataque a su software y otras aplicaciones en la cadena de suministro.
Como parte de los esfuerzos para combatir el reciente aumento en la frecuencia y el impacto de ataques a las cadenas de suministro de software, el Gobierno Federal en coordinación con la NTIA emitió una orden ejecutiva que detalla varias medidas para mejorar la ciberseguridad y garantizar la integridad de los componentes de terceros utilizados en los paquetes de software. Una de esas medidas es la Lista de materiales del software.
Este es un documento formal que contiene todos los componentes de un paquete de software y las relaciones de la cadena de suministro entre estos componentes. La preparación de una lista de materiales de software integral no es sólo una práctica estándar, sino que también lo exige la ley. Esta publicación define el alcance de la Lista de materiales de software y la elementos mínimos que debe incluirse en una lista completa de materiales.
¿Qué proporcionan los componentes mínimos de una SBOM de la NTIA?
El SBOM sirve como una guía formal para las empresas que crean, compran u operan software, brindándoles toda la información que necesitan para mejorar su comprensión de la cadena de suministro de software. También ayuda a rastrear fácilmente las vulnerabilidades emergentes en caso de que ocurran, y reducir los riesgos de la cadena de suministro de software. Sin embargo, para que el SBOM cumpla con los requisitos estipulados por el Gobierno Federal, existen algunos elementos básicos que debe contener. Estos elementos suelen clasificarse en tres categorías:
- Campos de información: Se espera que un SBOM proporcione datos importantes sobre los componentes de software, como el nombre del componente, el nombre del proveedor, la versión del software y otros identificadores únicos. También debe detallar las relaciones entre dependencias. Estos datos permiten identificar con precisión todos los componentes del software y rastrearlos a lo largo de la cadena de suministro del software.
- Soporte de automatización: La lista de materiales del software debe ser legible por máquina y también capaz de generarse automáticamente. Esto permite un seguimiento continuo de los datos incluidos en el SBOM. Por lo general, estos documentos están en formatos estándar como etiquetas SPDX, CycloneDX y SWID, lo que los hace también legibles por humanos.
- Prácticas y procesos: También se espera que la documentación del SBOM detalle las prácticas y procesos estándar para preparar y actualizar el SBOM. También debe incluir prácticas para distribuir y acceder al SBOM, así como medidas para manejar errores incidentales.
Los elementos mínimos requeridos de la documentación SBOM de la NTIA brindan un criterio claro de lo que se espera en una guía SBOM para los casos de uso básicos de su Lista de materiales de software, como la gestión de vulnerabilidades, la realización de un inventario de componentes de software y la gestión de licencias de software. El marco se está actualizando y puede incluir elementos adicionales que amplíen su usabilidad en el futuro más cercano. En las secciones siguientes de esta página, explicaremos con mayor detalle estos componentes clave de su lista de materiales de software. Los elementos mínimos requeridos de una Lista de materiales de software incluyen siete campos de datos como se especifica a continuación.
Campos de datos: requisitos mínimos
El propósito de la Lista de materiales del software es proporcionar información que ayude a los usuarios y otras partes interesadas a identificar fácilmente los componentes del software. Como era de esperar, uno de los primeros y más importantes elementos del SBOM son los datos que deben incluirse para cada componente detallado en el documento. Además de ayudar en la identificación de componentes individuales, los datos también facilitan el seguimiento de los componentes en los distintos lugares donde se utilizan en la cadena de suministro de software.
- Nombre del proveedor: El proveedor es el creador o fabricante del componente de software en cuestión. Este es el nombre del individuo u organización que crea, define e identifica los componentes del software.
- Nombre del componente: Esto se refiere al nombre designado asignado al software según lo definido por el proveedor o fabricante original. En los casos en que existan varios nombres y alias para el software, también se podrán anotar.
- Versión del componente: El SBOM debe incluir el número de versión o el número de categoría según lo especificado por el proveedor o fabricante. Los datos de la versión sirven como un identificador que especifica cualquier cambio en el software desde una versión previamente identificada de la versión posterior del software.
- Otros identificadores únicos: Esto se refiere a identificadores adicionales además del nombre y la versión del componente. Estos identificadores adicionales proporcionan una capa adicional de identificación para el componente y también se pueden utilizar como clave de búsqueda para encontrar el componente en bases de datos relevantes.
- Relación de dependencia: Este es uno de los componentes de datos más importantes de una lista de materiales de software, ya que el SBOM está destinado a detallar cómo encajan los componentes del software. La relación de dependencia especifica la relación entre el software X utilizado dentro de su aplicación y sus componentes ascendentes.
- Autor de datos SBOM: Esto se refiere a la persona que creó los datos de SBOM. A veces, el proveedor del software también puede actuar como autor. Sin embargo, en muchos casos, el autor es otro individuo o grupo.
Soporte de automatización: requisitos mínimos
El uso de la Lista de materiales del software a menudo trasciende las fronteras organizativas. Esto significa que los datos contenidos en el SBOM suelen ser utilizados por varios departamentos dentro de una organización y también por varias organizaciones. Para garantizar la facilidad de uso de esta documentación, la NTIA recomienda que el SBOM esté en un formato que sea legible tanto por máquinas como por humanos. La preparación y transmisión del SBOM en formatos automatizados estándar como este mejora la interoperabilidad de este documento para los diversos fines previstos.
La NTIA reconoce tres formatos de entrega para generar y transmitir SBOM. Su lista de materiales de software debe coincidir con cualquiera de estos formatos para cumplir con los estándares establecidos por la orden ejecutiva del gobierno sobre ciberseguridad. Estos formatos estándar incluyen:
- Intercambio de datos de paquetes de software (SPDX)
- Etiquetas de identificación de software (SWID)
- CiclónDX
Intercambio de datos de paquetes de software (SPDX)
SPDX es un estándar abierto para entregar datos SBOM. Captura información importante sobre el software, incluidos sus componentes, procedencia, licencias y derechos de autor. También proporciona referencias de seguridad. El SPDX La versión 2.2 es la versión más reciente y admite el tipo de archivo YAML 1.2, la notación de objetos JavaScript y el marco de descripción de recursos (RDF/XML). Etiqueta: valorar archivo de texto plano y hojas de cálculo .xls
Etiquetas de identificación de software (SWID)
Las etiquetas SWID están diseñadas para ayudar a identificar y contextualizar los componentes de cualquier producto de software. El proyecto de etiquetas de identificación de software (SWID Tags) es un conjunto de herramientas para generar y validar las etiquetas de identificación de una pieza de software. Estas herramientas basadas en Java admiten etiquetas XML SWID basadas en el formato estandarizado definido por ISO/IEC 19770-2:2015 y la representación concisa de objetos binarios (CBOR). El NIST tiene un sitio web con una lista de recursos útiles para:
- Creación de etiquetas SWID y CoSWID
- Validación de etiquetas SWID y CoSWID según requisitos de esquema específicos y pautas de mejores prácticas
- Una aplicación web que proporciona un servicio de validación de etiquetas SWID que se puede implementar en un servidor de aplicaciones Java.
- Cliente de repositorio SWID para publicar etiquetas en la base de datos nacional de vulnerabilidades
CiclónDX
CiclónDX afirma ser un "estándar ligero de lista de materiales de software (SBOM)". Es útil para el análisis de componentes de la cadena de suministro y la seguridad de aplicaciones. Las organizaciones que adoptan CycloneDX pueden cumplir sin problemas los requisitos mínimos de SBOM y madurar hacia casos de uso más sofisticados de la documentación de SBOM con el tiempo.
Los SBOM de CycloneDX normalmente se presentan en formatos XML, JSON o Protocol Buffers. La especificación suele incluir estos cinco campos:
- Metadatos de la lista de materiales: incluye la información general sobre la aplicación o el producto de software en sí.
- Componentes: este es un inventario completo que cubre todos los componentes propietarios y de código abierto del software.
- Información de servicios: esto detalla todas las API externas a las que es probable que llame la aplicación durante su funcionamiento. Incluye todas las URL de los puntos finales, los requisitos de autenticación y los cruces de límites de confianza.
- Dependencias: La documentación también detalla todos los componentes y servicios dentro del paquete de software. Esto incluye relaciones tanto directas como transitivas.
- Composiciones: Esto se refiere a la integridad de todas las partes constituyentes, incluidos los componentes individuales, los servicios y las relaciones de dependencia. Cada composición generalmente se describe en términos de si está completa, incompleta, solo incompleta de primera parte, solo incompleta de terceros o completamente desconocida.
Prácticas y Procesos: Requisitos Mínimos
El elemento final de su lista de materiales de software se centra en la mecánica del uso del SBOM en sí. Las prácticas y procesos cubren los detalles operativos de generación y uso del SBOM y deben estar incluidos en cualquier póliza o contrato que lo solicite. Los siguientes son los requisitos clave que deben detallarse en la sección Prácticas y procesos de su Lista de materiales de software:
- Frecuencia: Esta sección detalla la frecuencia con la que una organización debe generar una nueva factura de software para materiales. Generalmente, la NTIA recomienda que genere un nuevo SBOM cada vez que se actualice su componente de software o se publique una nueva versión. También se espera que los proveedores generen nuevos SBOM cada vez que encuentren un error en la versión original o conozcan nuevos detalles sobre los componentes de su software que no estaban incluidos en la documentación inicial.
- Profundidad: La profundidad de su SBOM depende de lo que se incluye en el documento. Para cumplir con las normas, se espera que su SBOM incluya todos los componentes de nivel superior y todas las dependencias transitivas. En situaciones en las que el autor no puede incluir todas las dependencias transitivas, el documento debe indicar al consumidor dónde puede encontrarlas.
- Hay casos en los que el autor de SBOM no puede proporcionar un gráfico de dependencia completo por una razón u otra. Esto puede deberse a que el componente no tiene más dependencias o no saben si estas dependencias existen o no. El autor de SBOM debe especificar este motivo.
- Distribución y Entrega: El objetivo de este requisito es garantizar que los SBOM se entreguen rápidamente y en un formato fácilmente digerible. Aunque este requisito no especifica el número de días o semanas en que deben entregarse los SBOM, deben entregarse lo más rápido posible. Además, el SBOM debe tener roles y permisos de acceso apropiados establecidos cuando se entrega. Finalmente, el requisito estipula que el SBOM puede distribuirse con cada instancia del producto o estar disponible de cualquier otra manera fácilmente accesible, como a través de un sitio web público.
- Control de acceso: En los casos en que el proveedor decida limitar el acceso a los datos de SBOM a usuarios o clientes específicos, el autor deberá especificar los términos de control de acceso. También es necesario ofrecer prestaciones específicas a los consumidores que deseen integrar los datos de SBOM en sus propias herramientas de seguridad.
- Acomodación de errores: SBOM puede ayudar a mejorar la garantía del software y gestión de riesgos de la cadena de suministro de software. Sin embargo, todavía está lejos de ser perfecto. Por lo tanto, los consumidores deben ser tolerantes con los errores u omisiones ocasionales no intencionales que pueden ocurrir al preparar los SBOM.
Pensando más allá de los requisitos mínimos de la NTIA
Hasta ahora, hemos analizado los elementos mínimos que se requieren en su Lista de materiales de software. Estos elementos mínimos representan los requisitos recomendados, especialmente para los casos de uso más básicos de esta documentación. Si bien sientan una buena base para la procedencia y la seguridad del software, hay que mirar más allá de estos requisitos. Las siguientes son algunas recomendaciones a considerar para casos de uso de SBOM más avanzados.
Campos de datos adicionales
Además de los campos de datos cubiertos en el documento de requisitos mínimos, existen campos de datos adicionales que se recomiendan para los casos en los que es necesario un mayor nivel de seguridad. Algunos de estos campos de datos adicionales incluyen:
- Un hash criptográfico de los componentes del software.
- Datos de la fase del ciclo de vida del software.
- Relaciones entre otros componentes
- Información de licencia
Software basado en la nube y software como servicio
Otra área potencial donde los requisitos de SBOM pueden ir más allá de lo básico es la gestión de productos de software como servicio (SaaS). Estos tipos de productos de software presentan desafíos únicos en lo que respecta a los datos SBOM. Para empezar, los riesgos de seguridad en el contexto de la nube son únicos. Además, la responsabilidad de manejar esos riesgos recae en el proveedor del servicio. La preparación de documentación SBOM para software basado en la nube también es más compleja ya que tienden a tener un ciclo de lanzamiento más corto.
Integridad y autenticidad de SBOM
Otro problema probable que vale la pena señalar es el proceso de autenticación de la fuente de datos SBOM. Actualmente, las firmas y la infraestructura de clave pública son las soluciones de referencia para verificar la integridad del software en el mundo digital actual. Es posible que los autores y proveedores de SBOM necesiten aprovechar estas firmas de software existentes para mejorar la confiabilidad de los datos de SBOM.
Vulnerabilidad y explotabilidad en dependencias
Aunque el propósito de los SBOM es facilitar la detección de vulnerabilidades, es importante señalar que no todas las vulnerabilidades en las dependencias constituyen riesgos importantes para el software que depende de ellas. Para evitar perder tiempo y recursos, los proveedores de software deberán implementar medidas para determinar los impactos potenciales de una vulnerabilidad de dependencia en el software que se utiliza en sentido descendente y comunicar el nivel de riesgo (o la falta de él en este caso) a los usuarios del SBOM. datos aguas abajo.
Flexibilidad versus uniformidad en la implementación
Siempre que se habla de seguridad del software, la cuestión de la flexibilidad y la uniformidad siempre pasa a primer plano. Esto también se aplica a casos de uso avanzados de SBOM. Para implementar con éxito las SBOM será necesario contar con políticas amplias que se apliquen a todas las áreas, así como a casos específicos en los que será necesaria flexibilidad.