Score
0 / 60 pts
CRA-03 — Ley Europea de Ciberresiliencia

Agua arriba

312 dependencias. 23 de ellas gestionadas por una sola persona. Un nuevo proveedor sin SBOM. ¿Sabe qué contiene su producto?

NIVEL DE AMENAZA: VERDE

Usted es el responsable de cumplimiento normativo de la cadena de suministro en Kastos IoT, un puesto que no existía hace seis meses. Su mandato: crear un proceso de trazabilidad de componentes que cumpla con los requisitos de diligencia debida de la CRA a la hora de integrar componentes de terceros. La reconstrucción de la SBOM del Módulo 1 reveló siete discrepancias. La auditoría más exhaustiva de Tomasz encontró 312 dependencias transitivas en el firmware del K400. Hoy comienza la evaluación completa de riesgos de la cadena de suministro, y también está evaluando a un nuevo proveedor de hardware en Shenzhen cuyo componente tiene un firmware que nunca ha visto.

  • Kastos IoT — 340 employees, €62M revenue, HQ Rotterdam
  • Firmware del K400: 312 dependencias transitivas (47 de primer nivel, 265 transitivas)
  • 23 dependencias mantenidas por un único desarrollador en Bielorrusia
  • Biblioteca de pila BLE de importancia crítica: proyecto de código abierto con tres participantes, sin actualizaciones desde hace 14 meses
  • Nueva evaluación de un proveedor de hardware: Shenzhen MicroCore — módulo de procesador integrado para la próxima generación del K400
  • Periodo de financiación de la CRA: 7 años (comprometido en el Módulo 3)
Resumen de la misión

Cómo funciona

Este es un escenario del tipo «elige tu propia aventura». Tomará decisiones reales a las que se enfrenta un director de cumplimiento de la cadena de suministro a la hora de analizar las dependencias, evaluar a los proveedores y gestionar las obligaciones relacionadas con el código abierto; y sus elecciones determinarán su calificación operativa final.

Mapeo del Árbol de Dependencias

Clasifica los componentes del árbol de dependencias del K400 por categoría de riesgo.

Tres Decisiones

Cada decisión se puntúa. Tus elecciones determinan una puntuación operativa basada en porcentajes. Las decisiones erróneas tienen consecuencias en cadena.

Investigación de Proveedores

Elige qué documentos de los proveedores quieres examinar. Tienes cuatro plazas: elígelas con cuidado.

Matriz de Riesgos

Sitúe los escenarios de la cadena de suministro en una matriz de probabilidad × impacto para elaborar el registro de riesgos.

--:--:-- VERDE CRA-03: Aguas arriba
Reunión informativa para el personal

Tu equipo

Trabajará con estas tres personas a lo largo de todo el escenario. Cada una de ellas aborda la cadena de suministro desde una perspectiva diferente; su tarea consiste en encontrar la decisión que concilie el riesgo, el coste y las obligaciones legales.

Tomasz Kowalski
Tomasz Kowalski
Lead Firmware Engineer
Estoy haciendo un seguimiento de todas las dependencias de un árbol de firmware con 312 bibliotecas. No me entusiasma nada todo este papeleo.
Sophie Laurent
Sophie Laurent
Director de Asuntos Jurídicos y Regulatorios
Te ayuda a cumplir con la normativa de Kastos. Te indicará exactamente qué artículo acabas de infringir.
Chen Wei
Chen Wei
Technical Director, Shenzhen MicroCore
Tu proveedor más complejo. Excelente desde el punto de vista técnico. Se enfrenta por primera vez a los requisitos de cumplimiento de la UE.
--:--:-- ÁMBAR CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación

La auditoría de dependencias

Lunes, 09:00 CET

Tomasz le guía a través del árbol de dependencias del K400. El nivel superior parece claro: 47 dependencias, todas ellas documentadas en la SBOM. Sin embargo, la capa transitiva —las dependencias de las dependencias— nos cuenta una historia diferente.

De un total de 312 dependencias: 289 se mantienen activamente con actualizaciones periódicas y un responsable conocido. 23 las mantiene un único desarrollador —la misma persona— que colabora en varios proyectos de código abierto relacionados con la UE. Y destaca una biblioteca fundamental: la pila de comunicación BLE que gestiona todo el aprovisionamiento de Bluetooth es mantenida por un proyecto de voluntarios formado por tres personas que no ha registrado ninguna actualización en 14 meses. Su última nota de lanzamiento dice: «Modo de mantenimiento. Solo parches de seguridad. Sin nuevas funciones».

K400 FIRMWARE v4.0  (312 dependencies)
│
├─ TOP-LEVEL                                      47
│  │
│  ├─ ● BLE communication stack                 [CRITICAL]
│  │    3-person project · 14 months silent · “maintenance mode”
│  │
│  ├─ ● 23 utility libraries                   [CONCENTRATION]
│  │    single maintainer (Belarus) · non-critical path
│  │
│  ├─ ✓ OpenSSL 3.1.4                          healthy
│  ├─ ✓ mbedTLS 3.5.0                          healthy
│  └─ ✓ 21 other top-level libraries            healthy
│
└─ TRANSITIVE                                    265
   │
   ├─ ✓ Actively maintained                     264
   └─ ● Known single-maintainer (via 23 libs)   23 nested

Una vulnerabilidad crítica a la espera de materializarse. Un riesgo de concentración en 23 bibliotecas si uno de los mantenedores abandona el proyecto. La CRA lo denomina due diligence exposure — y se trata de código abierto totalmente legal.

Tomasz Kowalski
Tomasz Kowalski — Ingeniero jefe de firmware
En 2023 elegí la pila BLE porque era la mejor opción disponible. Contaba con una buena documentación, una API clara y una comunidad activa. Desde entonces, dos de los tres mantenedores han abandonado el proyecto. La persona que queda publicó un parche de seguridad hace ocho meses y, desde entonces, no ha habido ninguna novedad.
OF
OPS FEED — Resumen de la situación
[09:12] CADENA DE SUMINISTRO — Auditoría de dependencias: 312 en total. 289 con mantenimiento activo. 23 con un único mantenedor. 1 biblioteca crítica en modo de mantenimiento (pila BLE, última actualización hace 14 meses).
--:--:-- ÁMBAR CRA-03: Aguas arriba
Resumen de la situación
Actividad

Representación gráfica del árbol de dependencias

Ronda de práctica — no puntuable. Tu puntuación se basa en las tres decisiones.

Lunes, 10:30 CET

Antes de elaborar un plan de corrección, es necesario visualizar el panorama de dependencias del K400. Clasifique cada componente según su categoría de riesgo. Identifique: qué componentes suponen un riesgo por tener un único responsable del mantenimiento, cuáles generan un riesgo de concentración y cuáles tienen un origen desconocido.

--:--:-- ROJO CRA-03: Aguas arriba
Resumen de la situación
Se requiere una decisión

La biblioteca abandonada

La pila BLE es fundamental para el funcionamiento del K400 y, en la práctica, no recibe mantenimiento. Una vulnerabilidad podría dejar a 2.800 paneles instalados sin un parche de seguridad. ¿Cómo se aborda esta situación?

--:--:-- VERDE CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación
Outcome: Positive

Bifurcar y mantener

Kastos crea una bifurcación de la pila BLE y contrata a un especialista en protocolos BLE para llevar a cabo una auditoría completa del código. La auditoría dura cuatro semanas y revela que el código está bien estructurado, pero presenta tres áreas en las que la validación de entradas es insuficiente; aunque actualmente no son explotables, podrían tener vulnerabilidades si se expusieran a paquetes BLE manipulados. Su equipo corrige estos problemas de forma proactiva.

Kastos mantiene ahora su propia rama de la pila BLE. El coste es considerable —120 000 € al año—, pero se obtiene un control total sobre el estado de seguridad de un componente crítico durante el periodo de soporte de siete años. La rama interna está documentada en la SBOM, donde figura Kastos como el actual responsable del mantenimiento.

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
Esto es exactamente lo que se entiende por «diligencia debida» en el artículo 13, apartado 5. Hemos identificado un riesgo en nuestra cadena de suministro y hemos adoptado medidas proporcionadas para gestionarlo. El organismo notificado verá que el fabricante controla sus dependencias críticas.
Regulatory Reference
Artículo 13, apartado 5, de la CRA — Diligencia debida en relación con los componentes
Al integrar componentes de terceros, los fabricantes deben actuar con la diligencia debida para garantizar que dichos componentes no pongan en peligro la ciberseguridad del producto. La diligencia debida incluye: verificar que los componentes se mantengan actualizados, que se solucionen las vulnerabilidades y que se conozca el estado de seguridad del componente. Cuando el responsable del mantenimiento del componente original deja de estar activo, el fabricante debe buscar una alternativa o asumir la responsabilidad del mantenimiento. «Era de código abierto y no lo comprobamos» no constituye una justificación válida en materia de diligencia debida.
Sophie Laurent
Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios
«Esto es exactamente lo que se entiende por «diligencia debida» en el artículo 13, apartado 5. Hemos identificado un riesgo en nuestra cadena de suministro y hemos tomado medidas proporcionadas para gestionarlo. El organismo notificado verá que el fabricante controla sus dependencias críticas».
--:--:-- ÁMBAR CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación
Outcome: Neutral

Migración prevista

Usted identifica dos alternativas comerciales de BLE: una de una empresa sueca (licencia de 45 000 € al año, garantía de asistencia técnica de 10 años) y otra de una empresa estadounidense (30 000 € al año, renovable cada 5 años). Tomasz calcula que la migración llevará entre 12 y 18 meses, ya que la pila de BLE está profundamente integrada en el flujo de trabajo de aprovisionamiento.

Mientras tanto, debe registrar el riesgo en el registro de riesgos de la cadena de suministro y establecer un sistema de seguimiento: alertas automáticas para cualquier CVE que afecte a la biblioteca BLE actual, comprobaciones semanales de la actividad en el repositorio de origen y un plan de respuesta en caso de que se revele una vulnerabilidad crítica antes de que finalice la migración.

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
El plan es defendible. Sin embargo, es necesario documentar claramente la aceptación del riesgo: si surge una vulnerabilidad durante el periodo de migración, debemos demostrar que contábamos con un plan de contingencia, y no solo con un calendario.
Sophie Laurent
Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios
«El plan es defendible. Pero hay que dejar bien claro que se asumen los riesgos: si surge alguna vulnerabilidad durante el periodo de migración, tenemos que demostrar que contábamos con un plan de contingencia, no solo con un calendario».
--:--:-- ROJO CRA-03: Fase inicial
Resumen de la situación
Actualización de la situación
Outcome: Negative

Esperar y ver qué pasa

Cuatro meses después, un investigador de seguridad da a conocer una vulnerabilidad crítica en la pila BLE: un desbordamiento de búfer en el protocolo de emparejamiento que permite la ejecución remota de código dentro del alcance de Bluetooth. El único mantenedor que queda en el proyecto original publica lo siguiente: «Soy consciente de este problema. Por el momento no dispongo de tiempo para desarrollar una solución. Se aceptan solicitudes de incorporación de cambios».

Kastos carece de conocimientos internos sobre BLE. La vulnerabilidad afecta a los 2.800 paneles K400 instalados. La CRA exige actualizaciones de seguridad «sin demora», pero Kastos no puede desarrollar un parche para un código fuente que desconoce. Contratación de emergencia de un proveedor externo: 80.000 € por una auditoría urgente y un parche. Plazo de entrega estimado: de 6 a 8 semanas.

Jan: «Sabíamos hace cuatro meses que esta biblioteca no recibía mantenimiento. Decidimos esperar. Eso no es un fallo de la cadena de suministro, sino un error de decisión».

Regulatory Reference
La diligencia debida es proactiva, no reactiva
El requisito de diligencia debida de la CRA es una obligación con visión de futuro. Los fabricantes deben evaluar la seguridad y la viabilidad del mantenimiento de los componentes en el momento de su integración y de forma continua. Saber que un componente crítico no recibe mantenimiento y optar por esperar a que aparezca una vulnerabilidad no constituye diligencia debida: es una aceptación del riesgo sin medidas de mitigación. Las autoridades de vigilancia del mercado preguntarán: «Ustedes sabían que la biblioteca no recibía mantenimiento. ¿Qué hicieron al respecto?».
--:--:-- ÁMBAR CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación

El proveedor de Shenzhen

Miércoles, 10:00 CET

Se une a una videollamada con Chen Wei, director técnico de Shenzhen MicroCore Electronics. El módulo de procesador integrado MC-7200 es técnicamente excelente: menor consumo energético, mayor velocidad de procesamiento y un 30 % más económico que la alternativa de la UE. El equipo de hardware de Kastos lo quiere para la próxima generación del K400.

Le pide a Chen Wei la lista de materiales de software (SBOM) del componente. Se produce una pausa.

El MC-7200 incluye su propio firmware RTOS con funciones de red integradas, Bluetooth y bibliotecas de seguridad. A MicroCore nunca se le ha solicitado una lista de materiales de software (SBOM). Disponen de una lista de materiales de hardware —todos los componentes físicos están documentados—. ¿Pero el firmware? «Nuestro equipo de ingeniería puede facilitar una lista de las principales bibliotecas», explica Chen Wei. «Pero el árbol completo de dependencias... eso no es algo que hayamos preparado».

Chen Wei
CHEN WEI — Director técnico, Shenzhen MicroCore Electronics
Entiendo su necesidad. No hemos recibido esta solicitud de otros clientes. Nuestro firmware utiliza bibliotecas estándar: FreeRTOS, lwIP y mbedTLS. Puedo facilitarle los números de versión. El árbol completo de dependencias llevará algún tiempo.
Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
Si integramos el MC-7200 en el K400, su firmware pasa a formar parte de nuestro producto. Nuestra SBOM debe incluir sus dependencias. Nuestra evaluación de la conformidad debe abarcar su seguridad. Si MicroCore no puede indicarnos qué contiene su firmware, no podremos cumplir con la diligencia debida prevista en el artículo 13, apartado 5.
--:--:-- ÁMBAR CRA-03: Aguas arriba
Resumen de la situación
Actividad

Diligencia debida de proveedores — Revisión de documentos

Ronda de práctica — no puntuable. Tu puntuación se basa en las tres decisiones.

Miércoles, 14:00 CET

Chen Wei ha enviado el paquete de documentación del MC-7200. La información se encuentra oculta en las fichas: elija qué aspectos desea investigar. Cada investigación requiere tiempo. Dispone de cuatro plazas de investigación antes de que finalice el plazo para la evaluación del proveedor. Lo que no abra, no lo sabrá; y lo que no sepa, no podrá evaluarlo.

Investigations remaining: 4 of 4
--:--:-- ÁMBAR CRA-03: Fase inicial
Resumen de la situación
Se requiere una decisión

Diligencia debida de proveedores

El MC-7200 es técnicamente superior y un 30 % más barato. Sin embargo, MicroCore no puede facilitar en estos momentos una lista de materiales de software (SBOM) para el firmware del componente. ¿Cómo procede?

--:--:-- VERDE CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación
Outcome: Positive

Desarrollo de proveedores

Redacta un anexo con los requisitos de ciberseguridad para los proveedores: una lista completa de componentes de software (SBOM) en formato CycloneDX, una política de divulgación de vulnerabilidades publicada, el compromiso de realizar actualizaciones de seguridad durante todo el ciclo de vida del componente y una revisión de seguridad anual. Concede a MicroCore un plazo de 90 días y propone una sesión de trabajo conjunta sobre herramientas de generación de SBOM.

Chen Wei se muestra receptivo: «Vendemos a empresas del sector de la automoción en Alemania. Nos solicitan trazabilidad del hardware. Esto es el equivalente en software; lo entiendo». Su equipo utiliza una herramienta de código abierto para la gestión de la lista de materiales de software (SBOM) y elabora un borrador en un plazo de seis semanas. Este revela 87 dependencias en el firmware del MC-7200, incluidas dos bibliotecas con vulnerabilidades CVE conocidas de las que MicroCore no tenía constancia.

La colaboración se consolida. MicroCore corrige las vulnerabilidades (CVE) antes de que el componente salga al mercado. El contrato de Kastos es el primero en incluir requisitos de ciberseguridad alineados con el CRA, pero MicroCore espera que le sigan más clientes de la UE. Usted ha contribuido a crear una cadena de suministro más segura, no solo a evaluarla.

Chen Wei
Chen Wei — Technical Director, Shenzhen MicroCore
«Vendemos a empresas del sector del automóvil en Alemania. Nos piden trazabilidad del hardware. Esto es el equivalente en software; lo entiendo».
--:--:-- ÁMBAR CRA-03: Fase inicial
Resumen de la situación
Actualización de la situación
Outcome: Neutral

Evaluación independiente

El equipo de seguridad de Kastos lleva a cabo un análisis binario del firmware del MC-7200. Extraen 71 de las 87 dependencias estimadas; 16 de ellas están ofuscadas o compiladas de tal forma que se resisten al análisis. La SBOM parcial se incluye en el expediente técnico con la siguiente nota: «Firmware del componente analizado mediante descomposición binaria. No se han podido identificar 16 dependencias. Se está en contacto con el proveedor».

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
Esto es mejor que nada, pero una autoridad de vigilancia del mercado podría preguntarse por qué hemos integrado un componente con 16 dependencias no identificadas. El argumento de la diligencia debida pierde fuerza cuando no podemos describir con exactitud lo que estamos vendiendo.

El organismo notificado acepta la SBOM parcial con condiciones: Kastos deberá obtener la lista completa de dependencias de MicroCore en un plazo de seis meses o demostrar una garantía equivalente mediante pruebas continuas.

Sophie Laurent
Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios
«Esto es mejor que nada, pero una autoridad de vigilancia del mercado podría preguntarnos por qué hemos integrado un componente con 16 dependencias no identificadas. El argumento de la diligencia debida pierde fuerza cuando no podemos describir con exactitud lo que estamos vendiendo».
--:--:-- ÁMBAR CRA-03: Fase inicial
Resumen de la situación
Actualización de la situación
Outcome: Neutral

Alternativa de la UE

Kastos selecciona al proveedor de la UE. El componente cumple con la normativa CRA: se proporciona una lista completa de materiales (SBOM), se ha publicado una política de divulgación de vulnerabilidades y se ha asumido un compromiso de actualizaciones de seguridad durante siete años, en consonancia con el propio periodo de asistencia de Kastos. La integración se lleva a cabo sin problemas.

El impacto en los costes: 14 € más por unidad que el MC-7200; sobre una estimación de 50 000 unidades en tres años, esto supone 700 000 € en costes adicionales de componentes. Jan se pregunta: «¿Realmente vale la pena gastar 700 000 € en cumplir con la normativa CRA cuando podríamos haber formado al proveedor más económico?».

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
Es una decisión empresarial válida, pero no es la única vía para cumplir con la normativa. Podríamos haber exigido a MicroCore que cumpliera con nuestras normas: la CRA no exige que el abastecimiento proceda de la UE, sino que exige la diligencia debida. Optamos por la vía más rápida para cumplir con la normativa, no por la más rentable.
Sophie Laurent
Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios
«Es una decisión empresarial válida, pero no es la única vía para cumplir con la normativa. Podríamos haber exigido a MicroCore que cumpliera nuestras normas; la CRA no exige que el abastecimiento proceda de la UE, sino que exige la debida diligencia. Elegimos la vía más rápida para cumplir con la normativa, no la más rentable».
--:--:-- ÁMBAR CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación

La cuestión del código abierto

Viernes, 09:00 CET

Sophie convoca una reunión para tratar el tema de los límites de responsabilidad en materia de código abierto. El firmware del K400 integra 189 bibliotecas de código abierto, lo que supone más del 60 % del árbol de dependencias. La CRA exime a los «administradores de software de código abierto» de las obligaciones que incumben al fabricante. Sin embargo, Kastos es el fabricante. La pregunta es: ¿cuáles son las obligaciones de Kastos con respecto a los componentes de código abierto que integra?

El artículo 18 es claro: los administradores de software de código abierto tienen una obligación «limitada» de facilitar la gestión de vulnerabilidades, pero no son responsables de la ciberseguridad del producto. Sin embargo, el artículo 13, apartado 5, es igualmente claro: los fabricantes deben actuar con la diligencia debida al integrar componentes de terceros. La obligación no desaparece por el hecho de que el componente sea gratuito.

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
Permítanme ser preciso. El Artículo 18 protege al voluntario que se encarga del mantenimiento de la biblioteca BLE. No nos protege a nosotros. Nosotros decidimos integrarla. Nosotros comercializamos el producto. En virtud del CRA, la obligación en materia de ciberseguridad recae en la entidad que comercializa el producto en el mercado de la UE. Esa entidad es Kastos.
Tomasz Kowalski
Tomasz Kowalski — Ingeniero jefe de firmware
Entonces, si se detecta una vulnerabilidad en una biblioteca de código abierto que utilizamos, ¿somos responsables de corregirla, aunque no la hayamos creado nosotros?
Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
Somos responsables de garantizar la seguridad del producto. La forma de lograrlo —mediante parches, sustituciones o medidas de mitigación— es una decisión que compete a nuestro equipo de ingeniería. Pero la responsabilidad recae sobre nosotros. El mantenedor del proyecto original no tiene la obligación de solucionarlo por nosotros.
--:--:-- ÁMBAR CRA-03: Fase inicial
Resumen de la situación
Se requiere una decisión

Obligaciones del software de código abierto

Kastos integra 189 bibliotecas de código abierto. En virtud de la CRA, el fabricante es responsable de la ciberseguridad de todo el producto, incluidos los componentes de código abierto. ¿Cómo debería gestionar Kastos sus obligaciones en materia de código abierto de aquí en adelante?

--:--:-- VERDE CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación
Outcome: Positive

Gobernanza del software libre

Kastos pone en marcha el Programa de Seguridad de Código Abierto (OSSP). Se clasifican las 189 bibliotecas en tres niveles: Nivel 1 (12 bibliotecas críticas para la seguridad —criptografía, redes, BLE—), Nivel 2 (34 bibliotecas importantes —gestión de datos, implementación de protocolos—) y Nivel 3 (143 bibliotecas de utilidades —registro, pruebas, formato—).

Para el Nivel 1: auditorías de seguridad anuales, aportaciones de parches en las fases iniciales del desarrollo y preparación para la creación de bifurcaciones internas. Para el Nivel 2: supervisión automatizada, revisión trimestral y planes de contingencia. Para el Nivel 3: supervisión automatizada de CVE y ciclo de parches estándar.

Durante el primer año, el OSSP detecta cuatro vulnerabilidades en bibliotecas de nivel 1 antes de que se hagan públicas, gracias a las auditorías financiadas. Se envían dos parches a los desarrolladores originales, que son aceptados por los responsables del mantenimiento. Se menciona a Kastos en los avisos de seguridad. El programa tiene un coste de 60 000 € al año y evita unos costes estimados de más de 200 000 € en respuestas de emergencia.

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
Sophie presenta el OSSP al organismo notificado: «Este es nuestro marco de diligencia debida para los componentes de código abierto». El evaluador: «Es la primera vez que veo a un fabricante documentar esto de forma tan sistemática. Enhorabuena».
Sophie Laurent
Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios
«Este es nuestro marco de diligencia debida para los componentes de código abierto». El evaluador del organismo notificado: «Es la primera vez que veo a un fabricante documentar esto de forma tan sistemática. Bien hecho».
--:--:-- ÁMBAR CRA-03: Aguas arriba
Resumen de la situación
Actualización de la situación
Outcome: Neutral

Supervisión automatizada

Usted implementa un sistema de supervisión automatizada de vulnerabilidades en las 189 bibliotecas mediante una herramienta de análisis de seguridad de código abierto integrada en el proceso de CI/CD. Cada compilación comprueba la presencia de CVE conocidos. Las alertas se activan a los pocos minutos de la publicación de un nuevo CVE.

El sistema funciona: en los primeros seis meses, detecta siete vulnerabilidades CVE que afectan a las dependencias de Kastos. Seis de ellas son de gravedad baja y se corrigen en el ciclo de lanzamiento habitual. Una es de gravedad alta y se encuentra en una biblioteca de redes; su equipo la corrige en un plazo de 72 horas.

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
La supervisión es reactiva. Nos enteramos de las vulnerabilidades al mismo tiempo que el resto del mundo: tras su divulgación. Las empresas que financian auditorías en las fases iniciales las detectan antes de que se hagan públicas. Somos más rápidos que la mayoría, pero no vamos por delante de los acontecimientos. El enfoque cumple con la normativa, pero no es ejemplar.
Sophie Laurent
Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios
«La supervisión es reactiva. Nos enteramos de las vulnerabilidades al mismo tiempo que el resto del mundo, es decir, después de que se hayan hecho públicas. El enfoque cumple con la normativa, pero no es ejemplar».
--:--:-- ÁMBAR CRA-03: Fase inicial
Resumen de la situación
Actualización de la situación
Outcome: Negative

Reemplazar todo

Tomasz calcula el esfuerzo que supondrá la migración: 12 bibliotecas de código abierto fundamentales necesitan sustitutos comerciales. Tres de ellas no tienen equivalente comercial: la pila BLE, un gestor de protocolos personalizado y una capa de abstracción de hardware diseñada específicamente para el chipset del K400. En el caso de estas tres, la única opción es el mantenimiento interno o una reestructuración completa de la arquitectura.

Coste estimado: 400 000 € en derechos de licencia al año, 250 000 € en ingeniería de migración y 18 meses de interrupciones. La hoja de ruta de la versión 5.0 se encuentra, en la práctica, paralizada mientras el equipo reescribe las interfaces.

Jan: «Estamos invirtiendo 650 000 euros el primer año para sustituir código que ya funciona. La CRA no nos exige que evitemos el código abierto, sino que lo gestionemos. Se trata de una reacción exagerada que frena nuestra velocidad de desarrollo».

Sophie Laurent
SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios
La CRA reconoce explícitamente el código abierto como parte del ecosistema. La obligación es actuar con la diligencia debida, no eliminarlo. Hemos ido más allá de la proporcionalidad.
Regulatory Reference
Considerandos 18 a 20 de la CRA: integración de software de código abierto y comercial
La CRA reconoce que el software de código abierto es una parte integral del ecosistema de productos digitales. No penaliza ni desalienta el uso del código abierto, sino que exige a los fabricantes que integran código abierto en productos comerciales que actúen con la diligencia debida. La obligación consiste en evaluar, supervisar y gestionar la seguridad de todos los componentes, independientemente de su modelo de licencia. No es necesario sustituir todo el código abierto por alternativas comerciales, y ello podría no ser proporcionado, ya que elimina un riesgo (la viabilidad del mantenedor) al tiempo que genera otros (dependencia de un único proveedor, menor flexibilidad y mayor coste sin que ello implique necesariamente una mayor seguridad).
Sophie Laurent
Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios
«La CRA reconoce explícitamente el código abierto como parte del ecosistema. La obligación es actuar con la debida diligencia, no eliminarlo. Hemos ido más allá de la proporcionalidad».
--:--:-- VERDE CRA-03: Aguas arriba
Resumen de la situación
Actividad

Registro de riesgos de la cadena de suministro

Ronda de práctica — no puntuable. Tu puntuación se basa en las tres decisiones.

Fin de la segunda semana

Está elaborando el registro de riesgos de la cadena de suministro de Kastos. Sitúe cada uno de estos seis escenarios de la cadena de suministro en la matriz de probabilidad × impacto. La posición determina la calificación del riesgo y marca la prioridad de mitigación.

--:--:-- VERDE CRA-03: Aguas arriba
Resumen de la situación
Prueba de conocimientos

Antes de ver sus resultados, responda a cuatro preguntas sobre la CRA. Seleccione una respuesta por pregunta.