Saltar al Contenido Principal

Buenas prácticas de adopción del CRA

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.

En esta página

Kit práctico de implementación para pymes

Plantillas reutilizables y orientaciones prácticas para ayudar a las pymes a aplicar un enfoque proporcionado y orientado al ciclo de vida en la integración de componentes FOSS en el marco del CRA. Las herramientas son deliberadamente ligeras y se adaptan a la criticidad del producto, a su exposición y a los recursos disponibles.

Marca las listas de comprobación en línea (tu progreso se guarda en este navegador), imprímelas o descarga las plantillas en la herramienta que ya utilizas: una hoja de cálculo, una wiki o un repositorio Git.

Descargar todas las plantillas (.md)

A1.1 Lista de comprobación

Lista de comprobación de cumplimiento mínimo viable (MVC)

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.

Descargar .md

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

  • Designar un responsable para:

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

B. Visibilidad de los componentes Saber qué se utiliza

    • 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

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:

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

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

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

  • Definir una política de actualización sencilla:
  • Registrar como mínimo:

F. Evidencias Poder demostrar lo que se ha hecho

  • Conservar evidencias ligeras que puedan presentarse si es necesario:

Principio MVC

Empieza poco a poco, sé constante y amplía los controles en función del riesgo.

§5.4.5 Lista de comprobación

Lista rápida de diligencia debida

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.

Descargar .md

Visibilidad básica

Conocimiento de las vulnerabilidades

Transparencia de la cadena de suministro

Ciclo de vida

¿El componente gestiona funciones sensibles o está expuesto a internet? Usa la matriz de decisión para saber qué nivel de diligencia debida necesita.

Abrir la matriz de decisión

A1.2 Plantilla

Registro de componentes FOSS

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.

Descargar .csv Descargar .md

Ejemplo (fila completada)

Nombre del componenteVersiónUtilizado enCriticidadExposiciónLicenciaActividad de los mantenedoresÚltima revisión de vulnerabilidadesResponsable de actualizacionesNotas
ExampleAuthLib2.4.1Módulo de autenticaciónAltaPúblicaMITActiva (versiones mensuales)12 feb. 2026CTOSensible 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

A1.3 Plantilla

Ficha de componente de código abierto

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.

Descargar .md

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

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

A1.4 Guía operativa

Miniguía de gestión de vulnerabilidades

Un flujo de gestión de vulnerabilidades estructurado pero ligero, a la medida de una pyme, desde la primera alerta hasta el cierre.

Descargar .md

Recepción Cómo recibimos las alertas

  • Fuentes vigiladas:
  • Responsable de las alertas
  • Contacto suplente

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

Corrección Corregir y verificar

  • Medida adoptada:
  • Responsable
  • Fecha objetivo
  • Validación realizada p. ej., pruebas / regresión / verificación del despliegue

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

Cierre y lecciones aprendidas

  • Fecha de cierre
  • Qué funcionó / qué mejorar la próxima vez 1–2 puntos

A1.5 Política

Política de actualización de dependencias

Una política breve que define cómo se revisan, actualizan y retiran las dependencias de terceros. Basta con una página.

Descargar .md

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

A1.6 Lista de comprobación

Lista de comprobación del SBOM para pymes

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.

Descargar .md

Qué recoger Mínimo

Cuándo generar o actualizar el SBOM

  • Mínimo:
  • Recomendado:
  • Actualizar siempre cuando:

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

La cadena de herramientas OCCTET analiza tu código fuente y genera los SBOM automáticamente, lo que te ayuda a pasar del nivel 1 al nivel 3.

Descubrir la cadena de herramientas OCCTET

Volver arriba