Gestión de riesgos de la cadena de suministro de software

Gestión de riesgos frente a seguridad

La seguridad de la cadena de suministro de software es el conjunto de controles técnicos: SBOM, dependencias fijadas, builds restringidos. La gestión de riesgos está por encima de eso. Pregunta de qué proveedores y componentes depende su negocio, qué ocurre si uno falla y si ha dedicado su esfuerzo al lugar adecuado.

¿Cuáles son los riesgos?

Riesgo	Ejemplo	Control principal
Componentes vulnerables	Un fallo en una biblioteca muy utilizada	SBOM y monitorización continua
Componentes maliciosos	Un paquete secuestrado o typosquatting	Revisión previa, adopción diferida, límites al tráfico saliente
Proyectos abandonados	Una dependencia con un único responsable de mantenimiento que ha pasado a otra cosa	Comprobaciones de salud y un plan de sustitución
Riesgo de licencias	Un componente copyleft en un producto propietario	Política de licencias
Build comprometido	Una GitHub Action secuestrada llega a sus secretos	Fijación de versiones, aislamiento, mínimo privilegio
Riesgo de proveedores	El producto o una actualización de un proveedor se ve comprometido	Evaluación, contratos, SBOM de los proveedores
Riesgo normativo	Un cliente o una ley exige evidencias que usted no puede aportar	Registros conservados por versión

Un proceso en seis pasos

Elabore el inventario. Enumere los productos que fabrica y el software que compra. Para lo que compila, conserve una SBOM por versión. No se puede evaluar lo que no se ve.
Ordene según lo que importa. Una biblioteca en su servicio de pagos no es lo mismo que una en una herramienta interna. Valore los productos por exposición, datos e impacto en el negocio.
Evalúe los riesgos. Examine las vulnerabilidades, la salud del proyecto, las licencias y cómo gestiona la seguridad cada proveedor. Hágalo a fondo para el nivel superior y de forma ligera para todo lo demás.
Trátelos. Para cada riesgo, decida si corrige, sustituye, añade un control o acepta. Un riesgo aceptado necesita un responsable y una fecha de revisión.
Monitorice de forma continua. El riesgo cambia sin que usted cambie nada, por ejemplo cuando se publica un aviso o un responsable de mantenimiento se marcha. Las revisiones anuales no lo detectan.
Informe. Dé a la dirección una visión breve: principales riesgos, exposición a lo largo del tiempo y lo que se ha aceptado. Los clientes y los auditores pedirán el detalle.

Evaluar a los proveedores

Los cuestionarios por sí solos le dicen lo que un proveedor afirma. Pida cosas que muestren lo que hace:

Una SBOM del producto, con un formato declarado y una forma de obtener actualizaciones
Cómo gestiona las vulnerabilidades y con qué rapidez informa a sus clientes
Un contacto de seguridad y una política de divulgación
Cómo compila sus versiones y si puede demostrar de dónde procede una versión
Durante cuánto tiempo recibe correcciones de seguridad una versión
Certificaciones e informes de auditoría que cubran el producto que está comprando

Incluya estas expectativas en los contratos. Es mucho más fácil exigir una SBOM o un plazo de notificación al firmar que después de un incidente.

Marcos que seguir

NIST SP 800-161 es la principal referencia para la gestión de riesgos de ciberseguridad en la cadena de suministro, o C-SCRM. Se aplica en todos los niveles de una organización e integra el riesgo de la cadena de suministro en la gestión de riesgos más amplia.
El NIST SSDF abarca las prácticas de desarrollo seguro, lo que lo convierte en una buena base para lo que pide a sus proveedores y a usted mismo.
SLSA le ofrece un lenguaje común sobre la fiabilidad de un build.
ISO/IEC 27001:2022 incluye controles para la seguridad de la cadena de suministro de TIC (anexo A 5.21) y las vulnerabilidades técnicas (8.8). No exige una SBOM, pero las SBOM son una buena evidencia para esos controles.
NIS2 cita la seguridad de la cadena de suministro como medida obligatoria para las entidades incluidas en su ámbito, en el artículo 21(2)(d).

Cómo medirla

Elija unas pocas medidas que lleven a tomar decisiones:

Porcentaje de productos con una SBOM de la versión actual
Tiempo para responder a «¿nos afecta?» ante una nueva vulnerabilidad crítica
Ventana de exposición: cuánto tiempo estuvo en producción una versión vulnerable
Porcentaje de proveedores de primer nivel evaluados en el último año
Número de riesgos aceptados que han superado su fecha de revisión

Dónde ayuda CRACI

CRACI aporta a un programa de riesgos los datos que suelen faltarle sobre el software que usted compila. Registra lo que descargó cada build de GitHub Actions, incluidas las licencias declaradas, en SBOM que puede conservar por versión y compartir en CycloneDX o SPDX. Monitoriza lo distribuido, muestra qué builds contenían un paquete vulnerable para que pueda ver el periodo en que estuvo afectado, y puede aplicar la política de licencias y bloquear builds con controles de política. Consulte seguridad de la cadena de suministro de software con CRACI y cómo se comparan las herramientas.

La evaluación de proveedores y su registro de riesgos siguen en manos de sus herramientas de gobernanza y de su equipo.

Gestión de riesgos de la cadena de suministro de software: preguntas frecuentes

¿Qué es la gestión de riesgos de la cadena de suministro de software?

Es la forma en que una organización identifica, evalúa y reduce el riesgo del software que no ha escrito, incluidos paquetes de código abierto, productos comerciales, proveedores de SaaS y herramientas de build.

¿Qué es C-SCRM?

C-SCRM son las siglas de cybersecurity supply chain risk management, gestión de riesgos de ciberseguridad en la cadena de suministro, el término que utiliza NIST. NIST SP 800-161 es su principal guía, y explica cómo encontrar, evaluar y reducir los riesgos cibernéticos a lo largo de la cadena de suministro en todos los niveles de una organización.

¿Cuáles son los mayores riesgos de la cadena de suministro de software?

Los componentes de código abierto vulnerables y maliciosos, los sistemas de build y las herramientas de CI comprometidos, los proyectos abandonados, los problemas de licencias y los proveedores que sufren una brecha.

¿En qué se diferencia de la gestión de riesgos de terceros?

La gestión de riesgos de terceros suele examinar a los proveedores como empresas. La gestión de riesgos de la cadena de suministro de software baja hasta los componentes y los procesos de build, incluidos los proyectos de código abierto sin ningún proveedor detrás.

¿Quién es responsable?

Lo habitual es que la dirección de seguridad o de riesgos defina el programa, que la seguridad de producto se ocupe de lo que la empresa desarrolla y que compras o la gestión de proveedores se ocupe de lo que adquiere. Los equipos de ingeniería corrigen lo que se encuentra.