Saltar al Contenido Principal

Buenas prácticas de adopción del CRA

Guía de cumplimiento del CRA para pymes

Un camino práctico y proporcionado para las pymes que integran componentes FOSS: quién debe centrarse en qué, cómo evaluar el riesgo, qué nivel de diligencia debida aplicar y cómo mantenerla en el tiempo.

En esta página

Perfiles de pyme: en qué centrarse

Las pymes abordan la adopción del CRA desde funciones y niveles de madurez técnica distintos. Los siguientes perfiles ilustran responsabilidades habituales y lo que cada función debería priorizar al utilizar e integrar componentes FOSS.

Perfil A

Responsable no técnico

CEO / COO / Responsable de operaciones

Objetivo: asegurarse de que la empresa puede demostrar un enfoque de cumplimiento razonable y repetible sin necesidad de entrar en detalles técnicos.

  • Garantizar que los roles estén asignados (quién se encarga de las actualizaciones, quién vigila las vulnerabilidades, quién aprueba las dependencias).
  • Garantizar que existan evidencias básicas (disponibilidad del SBOM, contacto de seguridad, política de actualización, canal de notificación de vulnerabilidades).
  • Aprobar el tiempo y el presupuesto para las actividades de «cumplimiento mínimo viable».
  • Exigir una documentación sencilla: qué utilizamos, por qué lo utilizamos y cómo lo mantenemos actualizado.

Perfil B

Responsable técnico

CTO / Desarrollador principal / Responsable de DevOps

Objetivo: implantar controles prácticos que reduzcan el riesgo y puedan mantenerse en el tiempo.

  • Integrar la seguridad en el ciclo de vida (revisión, pruebas, publicaciones seguras, actualizaciones).
  • Establecer la visibilidad de las dependencias (SBOM, escaneo de dependencias, seguimiento de las dependencias transitivas).
  • Implantar la gestión de vulnerabilidades (recepción, triaje, proceso de parcheo, notas de la versión).
  • Garantizar la trazabilidad (disciplina de versionado, registro de cambios, ramas protegidas, controles de acceso).

Perfil C

Product owner / coordinador de cumplimiento

Responsable de producto / QA / Referente de seguridad

Objetivo: conectar las decisiones de producto, las expectativas de los clientes y las evidencias de cumplimiento.

  • Aclarar el alcance del producto y su uso previsto (dónde se utiliza FOSS, dónde existe exposición).
  • Aplicar una visión basada en el riesgo: qué componentes son críticos y cuáles de bajo riesgo.
  • Mantener paquetes de evidencias ligeros (decisiones sobre riesgos, registro de componentes, historial de actualizaciones).
  • Coordinar a los equipos para que la vigilancia y las actualizaciones no queden en tierra de nadie.

Estos perfiles no son excluyentes. En muchas pymes, una misma persona puede asumir varias funciones. Lo esencial es que la responsabilidad y la rendición de cuentas estén asignadas de forma explícita.

Del consumo ad hoc a la gobernanza estructurada

El CRA marca una transformación más amplia: el cumplimiento ya no se limita al diseño interno del producto, sino que se extiende a toda la cadena de suministro de software. Para las pymes, esto supone pasar de un consumo ad hoc del código abierto a una gobernanza del ecosistema estructurada y basada en el riesgo.

Consumo ad hoc

Fragmentado y manual

Gobernanza estructurada

Basada en el riesgo y escalable

Los administradores de código abierto (Open Source Stewards) se convierten en actores clave de esta arquitectura de gobernanza, y el uso de componentes que no cuentan con un administrador será objeto de un escrutinio intenso para valorar adecuadamente los riesgos asociados. En lugar de auditar uno por uno todos los proyectos de origen, las pymes pueden:

  • Aprovechar los procesos alineados con los administradores de código abierto
  • Apoyarse en marcos de seguridad estructurados
  • Documentar esta colaboración como parte de la diligencia debida
  • Demostrar una gestión proporcionada y basada en el riesgo

Este enfoque se ajusta a la intención del CRA: mejorar la ciberseguridad sin imponer una carga desproporcionada.

Diligencia debida para los componentes de código abierto

Integrar componentes FOSS en productos con elementos digitales introduce una responsabilidad compartida a lo largo de la cadena de suministro de software. En el marco basado en el riesgo del CRA, se espera que los fabricantes, incluidas las pymes, apliquen una diligencia debida adecuada y proporcionada al seleccionar, integrar y mantener componentes de software de terceros.

La diligencia debida no pretende desalentar el uso de software de código abierto. Al contrario, el FOSS sigue siendo un pilar fundamental de la innovación y la competitividad. Sin embargo, debe integrarse de forma responsable. La diligencia debida garantiza que:

Entiendes lo que estás integrando

Conoces el nivel de riesgo que introduce

Puedes justificar tu decisión de integrarlo

Eres capaz de vigilarlo y mantenerlo a lo largo del tiempo

La diligencia debida no es una comprobación puntual antes de la publicación. Es una actividad orientada al ciclo de vida que continúa durante toda la vida útil prevista del producto, en consonancia con los requisitos del CRA en materia de desarrollo seguro y gestión de vulnerabilidades.

Evaluación de los componentes FOSS basada en el riesgo

Antes de integrar un componente FOSS, las pymes deberían evaluar tres dimensiones clave. Las preguntas están pensadas para que las entiendan tanto los responsables técnicos como los no técnicos.

Criticidad funcional

Pregúntate:

  • ¿Este componente gestiona la autenticación, el cifrado, el control de acceso o las actualizaciones?
  • ¿Es fundamental para la funcionalidad principal del producto?
  • Si este componente falla, ¿dejaría de funcionar nuestro producto?
  • ¿Podría comprometer la confidencialidad, la integridad o la disponibilidad de los datos?

Cuanto más crítica sea la función, más cuidadosa debe ser la evaluación. Una biblioteca de registro no es lo mismo que un módulo de autenticación.

Nivel de exposición

Pregúntate:

  • ¿Este componente es accesible desde internet?
  • ¿Procesa datos de entrada de usuarios externos?
  • ¿Está expuesto a través de API?
  • ¿O es totalmente interno y está aislado?

Una mayor exposición amplía la superficie de ataque. Un componente utilitario interno puede requerir una revisión más ligera que un componente de un servicio expuesto públicamente.

Impacto de un fallo

Pregúntate:

  • ¿Su explotación podría provocar violaciones de datos personales?
  • ¿Una interrupción del servicio afectaría a los clientes?
  • ¿Activaría obligaciones de notificación reglamentarias?
  • ¿Podría dañar nuestra reputación?

El impacto determina cuánto esfuerzo está justificado dedicar a la gestión del riesgo.

Estos factores se combinan

  • Un componente moderadamente crítico expuesto públicamente puede requerir controles reforzados.
  • Un componente muy crítico utilizado solo internamente puede justificar una revisión estructurada, pero proporcionada.

El objetivo es la proporcionalidad, no un control uniforme.

Niveles proporcionados de diligencia debida

En coherencia con el principio de proporcionalidad del CRA, las prácticas de diligencia debida pueden estructurarse en niveles de madurez crecientes.

Nivel 1

Diligencia debida básica

Adecuada para componentes de criticidad baja y exposición limitada.

Las medidas incluyen:

  • Verificación de la actividad del proyecto y de su mantenimiento reciente
  • Revisión de las vulnerabilidades divulgadas públicamente
  • Verificación de la compatibilidad de la licencia
  • Inclusión del componente en la lista de materiales de software (SBOM)

El objetivo es la transparencia y la trazabilidad. Para muchas pymes, se trata de un punto de partida realista y alcanzable, acorde con unas expectativas de cumplimiento proporcionadas.

Nivel 2

Diligencia debida estructurada

Adecuada para componentes de criticidad o exposición moderadas.

Las medidas adicionales pueden incluir:

  • Revisión de la transparencia de la gobernanza y de la estructura de mantenedores
  • Evaluación de las prácticas de notificación y respuesta ante vulnerabilidades
  • Evaluación de la disciplina de publicación y de la claridad del versionado
  • Herramientas automatizadas de escaneo de dependencias

La diligencia debida estructurada aporta previsibilidad. Reduce la dependencia de decisiones ad hoc y respalda evaluaciones internas de riesgos documentadas.

Nivel 3

Diligencia debida reforzada

Adecuada para componentes muy críticos o expuestos públicamente.

Las medidas reforzadas pueden incluir:

  • Vigilancia continua de las vulnerabilidades
  • Revisión de las prácticas de divulgación coordinada
  • Evaluación del compromiso de mantenimiento a largo plazo
  • Consideración de las atestaciones de seguridad voluntarias del artículo 25
  • Colaboración con los mantenedores cuando proceda

Especialmente pertinente para componentes que:

  • Tratan datos sensibles
  • Están expuestos públicamente
  • Sustentan funcionalidades esenciales del producto
  • Operan en entornos regulados o de alto impacto

La diligencia debida reforzada consolida la resiliencia en el conjunto de la cadena de suministro de software.

¿No sabes qué nivel aplicar? La matriz de decisión combina la criticidad y la exposición para recomendarte uno. En las listas de comprobación y plantillas encontrarás plantillas para los niveles 1 a 3.

Usar la matriz de decisión

Vigilancia continua y responsabilidad durante el ciclo de vida

La diligencia debida no termina en el momento de la integración. Pueden descubrirse vulnerabilidades años después. Los mantenedores pueden cambiar. Las publicaciones pueden espaciarse. La responsabilidad durante el ciclo de vida exige estar continuamente al tanto de la evolución de las vulnerabilidades y del estado de mantenimiento de los proyectos.

Las pymes deberían

  • Vigilar las divulgaciones de vulnerabilidades que afecten a las dependencias incluidas
  • Hacer un seguimiento de las nuevas versiones y actualizaciones de seguridad
  • Mantener actualizados los registros del SBOM
  • Reevaluar el riesgo cuando cambien la exposición o la arquitectura

Reevaluar sobre todo cuando

  • Se introducen nuevas funcionalidades en el producto
  • Aumenta la exposición pública
  • Cambian los requisitos reglamentarios
  • Disminuye la actividad de mantenimiento en el proyecto de origen

Este enfoque continuo se ajusta directamente a las obligaciones de seguridad del CRA a lo largo del ciclo de vida.

Uso de las atestaciones de seguridad

Cuando estén disponibles, las atestaciones de seguridad voluntarias en virtud del artículo 25 pueden respaldar una diligencia debida estructurada. Las atestaciones pueden:

  • Proporcionar información normalizada y comparable sobre las prácticas de gobernanza y de seguridad
  • Reducir las solicitudes de cumplimiento repetitivas dirigidas a los mantenedores
  • Facilitar su integración en los procesos internos de evaluación de riesgos

La responsabilidad del integrador se mantiene

Apoyarse en atestaciones no elimina la responsabilidad del integrador. Las pymes deben evaluar la pertinencia de la información atestada en relación con su propio contexto de integración, su nivel de exposición y la arquitectura de su producto. Las atestaciones refuerzan la transparencia, pero no sustituyen a la evaluación de riesgos en contexto.

Errores habituales y señales de alerta

Errores habituales al integrar FOSS

Las pymes se encuentran con frecuencia con problemas recurrentes:

  • Suponer que una adopción generalizada implica automáticamente seguridad
  • No identificar las dependencias indirectas (transitivas)
  • Realizar una validación puntual sin vigilancia posterior
  • Confiar en los parches del proyecto de origen sin comprobar que las actualizaciones se aplican
  • Integrar componentes sin documentar los motivos de su selección

Reconocer estos patrones permite a las pymes pasar de una integración reactiva a una gestión estructurada del riesgo.

Señales de alerta a las que prestar atención

Indicadores que pueden apuntar a un riesgo elevado:

  • Ningún canal visible para notificar problemas de seguridad
  • Largos periodos sin actualizaciones ni mantenimiento
  • Vulnerabilidades críticas sin resolver y sin comunicación al respecto
  • Versionado o documentación de las versiones incoherentes
  • Falta de claridad sobre la responsabilidad de los mantenedores
  • Grandes árboles de dependencias con poca transparencia

Una señal de alerta no descalifica automáticamente un componente. Sin embargo, la presencia de varios indicadores puede justificar una diligencia debida reforzada o replantearse la estrategia de integración.

Lista rápida de diligencia debida

Doce preguntas sencillas sobre visibilidad básica, conocimiento de las vulnerabilidades, transparencia de la cadena de suministro y ciclo de vida. Un punto de partida accesible y proporcionado para pymes con recursos limitados.

Abrir la lista de comprobación

El camino de las pymes hacia una adopción de FOSS alineada con el CRA

El CRA se basa en el riesgo y está orientado al ciclo de vida. Las pymes pueden adoptar un enfoque práctico siguiendo un camino sencillo que se adapta a la criticidad del producto y a los recursos disponibles.

  1. Empezar Asignar responsables y lograr una visibilidad básica

    • Asignar la responsabilidad de: la selección de dependencias, las actualizaciones de seguridad, la vigilancia de vulnerabilidades y la documentación.
    • Crear un inventario mínimo de los principales componentes FOSS utilizados en el producto.

  2. Definir el alcance Dónde importa el FOSS en tu producto

    • Identificar qué partes del producto están expuestas a internet, tratan datos o son sensibles desde el punto de vista de la seguridad.
    • Aclarar qué componentes son críticos para la funcionalidad del producto.

  3. Evaluar el riesgo Pensar de forma proporcionada

    • Evaluar cada componente según: criticidad, exposición e impacto.
    • Decidir qué nivel de diligencia debida es razonable (básica / estructurada / reforzada).

  4. Aplicar controles proporcionados Hacer lo que corresponde

    • Para los componentes de bajo riesgo: comprobaciones básicas + SBOM + vigilancia.
    • Para los componentes de mayor riesgo: comprobaciones estructuradas de la gobernanza, mayor disciplina de publicación y más vigilancia.

  5. Vigilar De forma continua, no puntual

    • Hacer un seguimiento de las vulnerabilidades y de las actualizaciones de los proyectos de origen.
    • Mantener el SBOM actualizado en cada versión (o al menos en las versiones principales).
    • Asegurarse de que las actualizaciones se aplican a tiempo.

  6. Reevaluar Cuando las cosas cambian

    • El producto pasa a estar más expuesto (nuevas integraciones, exposición a internet).
    • Cambian funcionalidades críticas.
    • Disminuye el mantenimiento del proyecto de origen.
    • Aparecen nuevas vulnerabilidades que afectan a dependencias clave.

Este camino está pensado para ayudar a las pymes a demostrar un enfoque estructurado y defendible, incluso con recursos limitados.

Matriz de decisión de diligencia debida para componentes FOSS

Para favorecer una toma de decisiones coherente y proporcionada, la matriz combina dos dimensiones, la criticidad funcional y el nivel de exposición, y recomienda el nivel de diligencia debida (L1 / L2 / L3) definido más arriba.

Criticidad funcional Nivel de exposición InternaUso aisladoLimitadaAcceso controladoPúblicaExpuesta a internet
BajaL1 BásicaL1 BásicaL2 Estructurada
MediaL1 BásicaL2 EstructuradaL3 Reforzada
AltaL2 EstructuradaL3 ReforzadaL3 Reforzada

Cómo utilizar esta matriz

  1. Determina la criticidad funcional del componente:
    • ¿Sustenta funcionalidades principales?
    • ¿Gestiona la autenticación, el cifrado o las actualizaciones?
    • ¿Un fallo afectaría significativamente al producto?
  2. Determina el nivel de exposición:
    • ¿Es solo interno?
    • ¿Es accesible a través de API autenticadas?
    • ¿Está expuesto públicamente?
  3. Localiza la intersección en la matriz para identificar el nivel de diligencia debida recomendado.

Consideraciones importantes

  • Esta matriz ofrece una orientación, no una clasificación rígida.
  • Si el impacto de un fallo es excepcionalmente alto (por ejemplo, seguridad de las personas o entorno regulado), las pymes pueden optar por aplicar un nivel de diligencia debida superior.
  • La matriz favorece la proporcionalidad y evita tanto el exceso de ingeniería como la infravaloración del riesgo.

Volver arriba