# Lista de comprobación de cumplimiento mínimo viable (MVC) (A1.1)

Una base de prácticas en una sola página que la mayoría de las pymes pueden aplicar para integrar componentes de código abierto de forma alineada con el CRA. Pensada para un tiempo y unos recursos limitados; refuérzala de forma proporcionada en función del riesgo.

## A. Roles y responsables — ¿Quién hace qué?

Designar un responsable para:

- [ ] La selección y aprobación de dependencias
- [ ] La vigilancia de vulnerabilidades
- [ ] Las actualizaciones de seguridad / la aplicación de parches
- [ ] La documentación de las versiones (qué ha cambiado, qué se ha actualizado)

> Asignar responsables claros evita que las responsabilidades de seguridad queden implícitas o sin asignar.

## B. Visibilidad de los componentes — Saber qué se utiliza

- [ ] Mantener un registro sencillo de componentes FOSS que incluya:
  - Nombre del componente + versión
  - Dónde se utiliza (módulo / área del producto)
  - Criticidad (baja / media / alta)
  - Exposición (interna / limitada / pública)
  - Responsable de actualizaciones
- [ ] Generar un SBOM (al menos para las versiones principales) o mantener una lista de dependencias equivalente

> La visibilidad es la base de una gestión basada en el riesgo.

## C. Diligencia debida básica — Antes de la integración

Para cada componente importante, confirmar que:

- [ ] Se mantiene activamente (actividad reciente / indicios de nuevas versiones)
- [ ] Se han revisado las vulnerabilidades conocidas
- [ ] Se ha comprobado la compatibilidad de la licencia
- [ ] Existe un contacto de seguridad o una vía de divulgación (cuando proceda)

## D. Gestión de vulnerabilidades — Qué hacer cuando aparece un problema

Disponer de un proceso interno básico que responda a estas preguntas:

- [ ] ¿Cómo recibimos las alertas de vulnerabilidades?
- [ ] ¿Quién realiza el triaje?
- [ ] ¿Cómo decidimos la urgencia?
- [ ] ¿Cómo aplicamos los parches y publicamos las versiones?
- [ ] ¿Cómo comunicamos los cambios (notas de la versión)?

## E. Actualizaciones y ciclo de vida — Mantener la seguridad a lo largo del tiempo

Definir una política de actualización sencilla:

- [ ] ¿Con qué frecuencia revisamos las actualizaciones? (p. ej., mensualmente + parches urgentes lo antes posible)
- [ ] ¿Cómo gestionamos los componentes al final de su vida útil?
- [ ] ¿Quién aprueba las actualizaciones de dependencias?

Registrar como mínimo:

- [ ] Fecha de la última revisión de dependencias
- [ ] Fecha de la última actualización de seguridad / publicación de parches

## F. Evidencias — Poder demostrar lo que se ha hecho

Conservar evidencias ligeras que puedan presentarse si es necesario:

- [ ] Registro de componentes + SBOM
- [ ] Política de actualización (basta con 1 página)
- [ ] Notas sobre la gestión de vulnerabilidades (proceso + al menos un ejemplo de entrada en el registro)
- [ ] Notas de la versión que mencionen las actualizaciones de dependencias / de seguridad

> **Principio MVC** — Empieza poco a poco, sé constante y amplía los controles en función del riesgo.

---

_Basado en el entregable D2.3 de OCCTET – Documento de buenas prácticas de adopción del CRA (v1.0, marzo de 2026), con licencia CC BY 4.0._

<https://occtet.eu/es/best-practices/checklists-and-templates/>