# Listas de comprobación y plantillas El kit práctico de implementación para pymes: listas de comprobación y plantillas ligeras para marcar en línea, imprimir o descargar en las herramientas que ya utilizas. --- ## 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. --- ## Lista rápida de diligencia debida (§5.4.5) Doce preguntas que conviene plantearse antes de integrar un componente FOSS. No sustituye a una evaluación de riesgos estructurada, pero ofrece un punto de partida accesible y proporcionado para pymes con recursos limitados. ### Visibilidad básica - [ ] ¿El proyecto se mantiene activamente? - [ ] ¿El historial de versiones es transparente? - [ ] ¿Hay un contacto de seguridad disponible públicamente? ### Conocimiento de las vulnerabilidades - [ ] ¿Se documentan las vulnerabilidades? - [ ] ¿Las correcciones se publican de forma estructurada? - [ ] ¿Hay indicios de capacidad de respuesta? ### Transparencia de la cadena de suministro - [ ] ¿El componente está incluido en el SBOM? - [ ] ¿Las dependencias son visibles? - [ ] ¿El versionado es coherente? ### Ciclo de vida - [ ] ¿Hay indicios de un mantenimiento continuo? - [ ] ¿Las actualizaciones se comunican con claridad? - [ ] ¿Está definido el estado de fin de vida? --- ## Registro de componentes FOSS (A1.2) Un registro sencillo de los componentes de código abierto integrados en tu producto. Facilita la trazabilidad, la diligencia debida y la vigilancia a lo largo del ciclo de vida, y puede mantenerse en una hoja de cálculo, SharePoint, Git o cualquier herramienta interna. | Nombre del componente | Versión | Utilizado en | Criticidad | Exposición | Licencia | Actividad de los mantenedores | Última revisión de vulnerabilidades | Responsable de actualizaciones | Notas | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | ExampleAuthLib | 2.4.1 | Módulo de autenticación | Alta | Pública | MIT | Activa (versiones mensuales) | 12 feb. 2026 | CTO | Sensible para la seguridad. CVE-2025-XXXX corregida en la v2.4.1. Vigilancia continua activada. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - **Criticidad:** Baja / Media / Alta - **Exposición:** Interna / Limitada / Pública --- ## Ficha de componente de código abierto (A1.3) Para componentes de criticidad media o alta, o para cualquier componente expuesto públicamente. Complementa el registro de componentes documentando por qué se seleccionó el componente y qué vigilancia se ha establecido. ### Componente - **Nombre del componente**: - **Versión / rango utilizado**: - **Repositorio / enlace de referencia** (opcional): - **Utilizado en** (módulo / funcionalidad): - **Criticidad funcional** (Baja / Media / Alta): - **Exposición** (Interna / Limitada / Pública): - **Licencia**: ### Motivos de la selección — ¿Por qué este componente? - **¿Por qué se eligió?** (p. ej., adecuación funcional, estabilidad, rendimiento, ecosistema) - **Alternativas consideradas** (si las hay): ### Diligencia debida básica realizada - [ ] Actividad de los mantenedores revisada - [ ] Historial de vulnerabilidades revisado - [ ] Contacto de seguridad / método de divulgación disponible (si procede) - [ ] Compatibilidad de la licencia confirmada - [ ] Incluido en el SBOM ### Riesgos conocidos / notas - **Limitaciones / problemas conocidos**: - **Problemas relacionados con la profundidad de las dependencias** (si procede): ### Vigilancia y responsables - **Responsable de actualizaciones / persona a cargo**: - **Fuente(s) de vigilancia de vulnerabilidades** (p. ej., avisos de seguridad, fuentes de CVE, alertas del repositorio): - **Frecuencia de revisión** (p. ej., mensual + alertas urgentes según sea necesario): - **Fecha de la última revisión**: - **Fecha de la próxima revisión prevista**: --- ## Miniguía de gestión de vulnerabilidades (A1.4) Un flujo de gestión de vulnerabilidades estructurado pero ligero, a la medida de una pyme, desde la primera alerta hasta el cierre. ### 1. Recepción — Cómo recibimos las alertas Fuentes vigiladas: - [ ] Avisos de seguridad de los proyectos - [ ] Bases de datos de CVE - [ ] Herramienta de escaneo de dependencias - [ ] Notificaciones de clientes - [ ] Pruebas internas - **Responsable de las alertas**: - **Contacto suplente**: ### 2. Triaje — Determinar la gravedad y la urgencia Para cada vulnerabilidad, registrar: - **Componente y versión(es) afectados**: - **¿Se utiliza en nuestro producto?** (Sí / No) - **Contexto de exposición** (Interna / Limitada / Pública): - **Criticidad funcional** (Baja / Media / Alta): - **Indicadores de explotabilidad** (si se conocen): - **Prioridad de respuesta propuesta** (Baja / Media / Alta): Regla de decisión (sencilla): - Criticidad alta + exposición pública → tratar como urgente - Riesgo medio → corrección planificada - Riesgo bajo → seguimiento y corrección en el próximo ciclo previsto ### 3. Corrección — Corregir y verificar Medida adoptada: - [ ] Actualización a una versión corregida - [ ] Aplicación de un parche - [ ] Mitigación / cambio de configuración - [ ] Solución provisional - **Responsable**: - **Fecha objetivo**: - **Validación realizada** (p. ej., pruebas / regresión / verificación del despliegue): ### 4. Publicación y comunicación - **Notas de la versión actualizadas** (Sí / No): - **SBOM actualizado** (Sí / No): - **¿Es necesaria una comunicación a los clientes / interna?** (Sí / No) - **En caso afirmativo: canal y responsable del mensaje**: ### 5. Cierre y lecciones aprendidas - **Fecha de cierre**: - **Qué funcionó / qué mejorar la próxima vez** (1–2 puntos): --- ## Política de actualización de dependencias (A1.5) Una política breve que define cómo se revisan, actualizan y retiran las dependencias de terceros. Basta con una página. ### Alcance Se aplica a las dependencias de terceros, incluidos los componentes FOSS. ### Principio Las dependencias se mantienen con un enfoque basado en el riesgo y orientado al ciclo de vida. Las actualizaciones son proporcionales a la criticidad, la exposición y el impacto. ### Frecuencia de actualización - **Revisión periódica de las dependencias** (p. ej., mensual / trimestral): Las actualizaciones de seguridad se aplican según la clasificación del riesgo: - **Riesgo alto:** lo antes posible - **Riesgo medio:** corrección planificada en el próximo ciclo de publicación - **Riesgo bajo:** seguimiento y resolución durante el mantenimiento habitual ### Responsables de las decisiones - **Responsable de aprobar las actualizaciones de dependencias**: - **Responsable de aprobar las correcciones de seguridad urgentes**: ### Dependencias en fin de vida Si una dependencia deja de tener soporte o llega al fin de su vida útil, procedemos a: - Registrar el riesgo - Evaluar alternativas - Planificar la migración o controles compensatorios - Documentar la decisión y el calendario --- ## Lista de comprobación del SBOM para pymes (A1.6) Qué recoger en una lista de materiales de software (SBOM) y cuándo hacerlo. Un SBOM favorece la transparencia y la trazabilidad de los productos que utilizan componentes FOSS, y las prácticas relacionadas con el SBOM pueden adoptarse de forma progresiva. ### Qué recoger — Mínimo - [ ] Nombre del producto + versión (identificador de la versión) - [ ] Nombre del componente + versión - [ ] Dependencias directas y transitivas (según disponibilidad) - [ ] Información sobre licencias (cuando sea posible) - [ ] Identificadores únicos (cuando estén disponibles, p. ej., package URL / hashes) ### Cuándo generar o actualizar el SBOM Mínimo: - [ ] En las versiones principales (p. ej., versión 1.0, 1.1, 2.0) Recomendado: - [ ] En cada versión que modifique las dependencias Actualizar siempre cuando: - [ ] Un parche de seguridad requiere actualizar una dependencia - [ ] Un componente crítico o muy expuesto cambia de versión - [ ] Se aplica una corrección de vulnerabilidad ### Niveles de madurez del SBOM #### Nivel 1 — Básico - Lista estructurada de dependencias - Actualización en las versiones principales - Vinculado a la documentación de la versión #### Nivel 2 — Estructurado - Generación automatizada del SBOM (cuando sea posible) - Dependencias directas + transitivas - Registro de licencias - SBOM almacenado junto con los artefactos de la versión #### Nivel 3 — Avanzado - Generación del SBOM integrada en CI/CD - Vigilancia continua de las dependencias - Verificación de hashes - Seguimiento del historial de versiones del SBOM - Análisis rápido del impacto de las CVE --- _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._