CI/CD para software médico certificado: cómo construir pipel - Blog

Introducción

La creencia de que el desarrollo de software médico certificado es incompatible con metodologías ágiles y pipelines CI/CD sigue arraigada en parte de la industria. Sin embargo, la norma IEC 62304:2006+Amd1:2015 reconoce explícitamente los procesos de integración y despliegue continuo como método válido para el desarrollo de software de dispositivos médicos. No solo no los prohíbe: su estructura de procesos de verificación, validación y trazabilidad encaja de forma natural con las prácticas de automatización moderna.

Este artículo detalla cómo diseñar pipelines CI/CD que integren compliance gates automáticos, generación de SBOM (Software Bill of Materials), trazabilidad de requisitos y escaneo de vulnerabilidades, todo ello conforme a IEC 62304 y alineado con las exigencias regulatorias actuales en Europa y Estados Unidos. Se dirige a equipos de desarrollo, DevOps y quality assurance que trabajan en software médico certificado y buscan automatizar su camino hacia el cumplimiento normativo sin sacrificar velocidad de entrega.

Abordaremos la clasificación de seguridad del software (Clases A, B y C), cómo cada clase impacta la rigurosidad del pipeline, las herramientas disponibles desde plataformas open source hasta soluciones ALM especializadas, y las obligaciones emergentes en torno al SBOM que ya son vinculantes para la FDA y están referenciadas en el Cyber Resilience Act europeo.

IEC 62304 y CI/CD: compatibilidad normativa

Qué exige realmente IEC 62304

IEC 62304:2006+Amendment 1:2015 es la norma internacional que define los requisitos del ciclo de vida del software para dispositivos médicos. Su alcance cubre la planificación, el análisis de requisitos, el diseño arquitectónico, la implementación, la verificación, la validación, la liberación, el mantenimiento y la retirada del software. Lo que la norma no hace es prescribir un modelo de desarrollo específico: no exige waterfall, no prohíbe sprints, y no impone una cadencia de release concreta.

La Amendment 1 de 2015 introdujo un cambio fundamental al permitir la clasificación de seguridad del software independiente del dispositivo médico completo. Esto significa que un módulo de software que no contribuye a una situación peligrosa puede clasificarse como Clase A aunque el dispositivo en su conjunto sea Clase III bajo MDR. Esta granularidad es la que permite aplicar un nivel de rigurosidad proporcional al riesgo real.

Las tres clases de seguridad del software

La clasificación de seguridad del software bajo IEC 62304 determina directamente la profundidad de los procesos requeridos:

Clase A (sin contribución a situación peligrosa): Requisitos mínimos. Se requiere planificación del desarrollo, análisis de requisitos y verificación del sistema software. No se exige documentación detallada del diseño arquitectónico ni pruebas unitarias obligatorias.
Clase B (contribución a situación peligrosa no grave): Nivel intermedio. Se añade la necesidad de diseño arquitectónico documentado, verificación de la arquitectura, y pruebas de integración.
Clase C (contribución a situación peligrosa grave, incluyendo muerte): Máxima rigurosidad. Se exige diseño detallado a nivel de unidad de software, revisión de código, pruebas unitarias exhaustivas, análisis de cobertura, y verificación completa en todos los niveles.

Esta clasificación tiene un impacto directo en el diseño del pipeline CI/CD: un pipeline para software Clase C necesitará significativamente más gates, análisis y evidencias que uno para Clase A.

Dónde encaja CI/CD en IEC 62304

Los procesos de CI/CD mapean directamente sobre los requisitos de IEC 62304 de la siguiente manera:

Proceso IEC 62304	Equivalente CI/CD
5.5 Software integration and integration testing	Pipeline de integración continua con tests automatizados
5.6 Software system testing	Suite de tests de sistema ejecutada en cada build
5.7 Software release	Pipeline de despliegue con gates de aprobación
6.1 Software maintenance plan	Pipeline de mantenimiento con regression testing
8.1 Software configuration management	Git + versionado semántico + tags inmutables
9.8 Traceability	Matrices de trazabilidad generadas automáticamente

La clave es que cada ejecución del pipeline genera evidencia auditable: logs de compilación, resultados de tests, informes de análisis estático, firmas de aprobación y checksums de artefactos. Esta evidencia, almacenada y vinculada a cada commit y release, satisface los requisitos de documentación de IEC 62304 de forma más robusta y reproducible que los procesos manuales tradicionales.

Diseño del pipeline: compliance gates automáticos

Arquitectura general del pipeline

Un pipeline CI/CD conforme a IEC 62304 para software médico certificado se estructura típicamente en las siguientes etapas:

Commit stage: Análisis estático de código (SAST), verificación de estilo y formato, comprobación de licencias de dependencias.
Build stage: Compilación del artefacto, generación del SBOM, firma criptográfica del build.
Unit test stage: Ejecución de pruebas unitarias con medición de cobertura. Para Clase C, se requiere un umbral de cobertura definido y documentado.
Integration test stage: Tests de integración entre componentes del sistema. Obligatorio para Clases B y C.
System test stage: Pruebas de sistema end-to-end contra los requisitos documentados.
Security scan stage: Escaneo DAST, análisis de vulnerabilidades de dependencias, verificación contra bases de datos CVE.
Compliance gate: Verificación automática de que todos los requisitos tienen tests asociados (trazabilidad), que la documentación está completa, y que no hay issues críticos abiertos.
Release stage: Generación del paquete de release, documentación de release notes, aprobación manual (para Clase B y C) y despliegue.

Compliance gates: el corazón del pipeline regulado

Los compliance gates son puntos de control automatizados que actúan como puertas de paso obligatorias. Si un gate no se supera, el pipeline se detiene y el artefacto no avanza a la siguiente fase. A diferencia de los quality gates convencionales, los compliance gates están vinculados a requisitos normativos específicos:

Gate de trazabilidad: Verifica que cada requisito del software tiene al menos un test asociado y que cada test referencia un requisito. Para Clase C, verifica también la trazabilidad bidireccional entre requisitos, diseño detallado, código fuente y tests.
Gate de cobertura: Comprueba que el porcentaje de cobertura de tests cumple el umbral definido en el plan de desarrollo del software. Los umbrales varían según la clase: un software Clase C puede requerir cobertura de sentencias, ramas y condiciones; un Clase A puede no requerir medición formal.
Gate de vulnerabilidades: Bloquea el pipeline si se detectan vulnerabilidades de severidad crítica o alta en las dependencias del proyecto, verificando contra la National Vulnerability Database (NVD) y bases de datos adicionales.
Gate de SBOM: Valida que el SBOM generado está completo, en formato estándar (SPDX o CycloneDX) y no contiene componentes con licencias incompatibles.
Gate de análisis estático: Verifica que el informe SAST no contiene findings de severidad alta no resueltos. Para Clase C, se revisan también findings de severidad media.

SBOM: de la recomendación a la obligación

El contexto regulatorio del SBOM

El Software Bill of Materials (SBOM) ha pasado de ser una buena práctica a convertirse en un requisito regulatorio explícito en múltiples jurisdicciones. La FDA exige SBOM desde octubre de 2023 para las solicitudes de premarket de dispositivos médicos con componentes de software, como parte de su guía Cybersecurity in Medical Devices (actualizada en junio de 2025). En Europa, el Cyber Resilience Act referencia el SBOM como mecanismo para garantizar la transparencia de componentes en productos con elementos digitales, incluyendo dispositivos médicos.

El marco de referencia para los elementos mínimos del SBOM es el documento NTIA 2021: Minimum Elements for a Software Bill of Materials, que define los campos obligatorios: proveedor del componente, nombre del componente, versión, identificadores únicos, relación de dependencia y marca temporal. Adicionalmente, el documento IMDRF N73: Principles and Practices for SBOM for Medical Device Cybersecurity establece guías específicas para el contexto de dispositivos médicos.

Generación automática de SBOM en el pipeline

La generación del SBOM debe ser un paso automático del pipeline, no un proceso manual posterior. Las herramientas principales para esta automatización son:

Syft (open source, de Anchore): Genera SBOMs a partir de imágenes de contenedores Docker, sistemas de archivos o directorios de código fuente. Soporta los formatos SPDX y CycloneDX.
Grype (open source, de Anchore): Complemento de Syft que escanea el SBOM generado contra bases de datos de vulnerabilidades conocidas, proporcionando un informe de vulnerabilidades asociado a cada componente.
OWASP Dependency-Track: Plataforma de análisis de composición de software (SCA) que ingiere SBOMs, monitoriza vulnerabilidades de forma continua y proporciona dashboards de riesgo.

Los formatos estándar para SBOM son:

SPDX (Software Package Data Exchange): Estándar ISO/IEC 5962:2021, mantenido por la Linux Foundation. Formato preferido por la FDA.
CycloneDX: Estándar OWASP, con soporte nativo para metadatos de vulnerabilidades y análisis de licencias. Ampliamente adoptado en entornos DevSecOps.

Un paso típico de generación de SBOM en un pipeline GitLab CI sería:

generate-sbom:
  stage: build
  image: anchore/syft:latest
  script:
    - syft dir:. -o spdx-json=sbom-spdx.json
    - syft dir:. -o cyclonedx-json=sbom-cdx.json
    - grype sbom:sbom-spdx.json --fail-on critical
  artifacts:
    paths:
      - sbom-spdx.json
      - sbom-cdx.json
    expire_in: 5 years

Nótese el parámetro expire_in: 5 years: la normativa exige conservar la documentación de release durante un periodo prolongado, y el SBOM es un artefacto de release.

Comparativa de herramientas CI/CD para software médico certificado

GitLab CI/CD

GitLab CI ofrece el ecosistema más completo para software médico certificado dentro de una plataforma unificada. Sus capacidades integradas de SAST, DAST y dependency scanning eliminan la necesidad de integrar herramientas externas para los escaneos de seguridad básicos. El modelo de pipelines como código (fichero .gitlab-ci.yml versionado en el repositorio) garantiza la trazabilidad de la configuración del pipeline.

Ventajas para IEC 62304: generación automática de informes de seguridad, registry de contenedores integrado para artefactos de build, entornos protegidos con aprobaciones manuales para releases, y audit log completo de todas las acciones en el proyecto.

Jenkins

Jenkins, con su ecosistema de plugins virtualmente ilimitado y su modelo de Jenkinsfile declarativo, ofrece la máxima flexibilidad para pipelines complejos con requisitos regulatorios específicos. Es la opción preferida por equipos que necesitan control total sobre cada aspecto del pipeline y que ya disponen de infraestructura on-premise para entornos validados.

Ventajas para IEC 62304: control total sobre el entorno de ejecución (crítico para builds reproducibles y validadas), integración con cualquier herramienta de terceros, y madurez probada en entornos regulados de industrias como aeronáutica y automoción.

Azure DevOps Pipelines

Azure DevOps es la opción natural para equipos que trabajan con el ecosistema Microsoft. Sus pipelines YAML, combinados con Azure Boards para la gestión de requisitos y Azure Test Plans para la ejecución de tests, proporcionan una plataforma ALM integrada que facilita la trazabilidad end-to-end exigida por IEC 62304.

Ventajas para IEC 62304: integración nativa con Azure Boards permite vincular requisitos, work items, commits y test cases en una cadena de trazabilidad completa. Entornos con aprobaciones y checks configurables como compliance gates.

GitHub Actions + Ketryx

Ketryx merece una mención especial como plataforma ALM especializada en software médico certificado. A diferencia de las herramientas genéricas de CI/CD, Ketryx fue diseñada específicamente para automatizar la documentación IEC 62304 desde Jira y GitHub. Su propuesta de valor es transformar los artefactos que los equipos de desarrollo ya generan (issues de Jira, pull requests de GitHub, resultados de tests de GitHub Actions) en documentación regulatoria formal: planes de desarrollo, especificaciones de requisitos, informes de verificación y registros de cambios.

El whitepaper de Ketryx (Automated Compliance for Medical Device Software) detalla cómo su plataforma mapea automáticamente los artefactos de desarrollo sobre las cláusulas de IEC 62304, generando alertas cuando falta evidencia para un requisito normativo específico. Esto reduce drásticamente el esfuerzo manual de preparación de documentación para auditorías y revisiones de diseño.

Otras herramientas relevantes

SonarQube / CodeClimate: Para análisis estático de código (code quality y code smells). SonarQube ofrece quality gates configurables que pueden actuar como compliance gates en el pipeline.
Tuleap (open source): Plataforma ALM de código abierto con capacidades de gestión de requisitos, trazabilidad y CI/CD. Alternativa viable para organizaciones que requieren despliegue on-premise y control total sobre sus datos.
Parasoft: Suite de testing orientada a compliance que incluye análisis estático con reglas específicas para estándares de software médico, generación de informes de cumplimiento y trazabilidad de tests a requisitos.

Seguridad del software: impacto de la clasificación en el pipeline

La clasificación de seguridad del software bajo IEC 62304 determina la configuración del pipeline de forma directa. A continuación se detalla cómo cada clase impacta las etapas del pipeline.

Pipeline para Clase A

El pipeline para software Clase A es el más ligero. Los requisitos mínimos son:

Análisis estático básico (linting, formateo).
Compilación y generación de artefactos.
Tests de sistema (verificación contra requisitos de software).
Generación de SBOM.
Documentación mínima de release.

No se exigen pruebas unitarias formales, diseño arquitectónico documentado ni análisis de cobertura. Sin embargo, es una buena práctica incluirlos aunque no sean normativamente obligatorios.

Pipeline para Clase B

Clase B añade requisitos significativos:

Diseño arquitectónico documentado y verificado (puede ser un fichero de arquitectura versionado en el repositorio, validado mediante revisión de código).
Tests de integración obligatorios.
Análisis estático SAST con gate de severidad.
Escaneo de vulnerabilidades de dependencias.
Gate de trazabilidad: requisitos vinculados a tests de integración y sistema.

Pipeline para Clase C

Clase C exige el máximo nivel de rigurosidad:

Diseño detallado a nivel de unidad de software, documentado y verificado.
Revisión de código obligatoria (peer review) antes de merge, con evidencia registrada.
Tests unitarios con análisis de cobertura (sentencias, ramas, condiciones según lo definido en el plan de verificación).
Tests de integración y sistema exhaustivos.
SAST y DAST completos con gates estrictos.
Trazabilidad bidireccional completa: requisitos \<-> diseño \<-> código \<-> tests.
Aprobación manual obligatoria en el compliance gate antes del release.
Documentación completa de risk management vinculada a cada cambio.

Ejemplo de configuración de stages por clase

# Ejemplo conceptual - estructura de stages por clase IEC 62304
stages:
  # Clase A, B y C
  - lint
  - build
  - sbom-generation
  - system-tests

  # Clase B y C
  - sast-scan
  - dependency-scan
  - integration-tests
  - architecture-verification

  # Solo Clase C
  - unit-tests-with-coverage
  - dast-scan
  - detailed-design-verification
  - full-traceability-check
  - manual-approval

  # Todas las clases
  - release

Contenedores y reproducibilidad: Docker y Kubernetes en entornos regulados

La contenedorización con Docker aporta un valor fundamental en entornos regulados: la reproducibilidad del build. Un Dockerfile versionado en el repositorio garantiza que el entorno de compilación es idéntico en cada ejecución del pipeline, eliminando el clásico problema de "funciona en mi máquina". Esta reproducibilidad es un requisito implícito de IEC 62304 para la gestión de configuración del software (cláusula 8).

Kubernetes entra en juego para la orquestación de los entornos de pruebas y, en algunos casos, para el despliegue del propio software médico (especialmente en soluciones SaaS/cloud). En estos escenarios, la configuración de Kubernetes (manifiestos, Helm charts) debe tratarse como software del dispositivo médico y someterse a los mismos controles de versionado, revisión y validación que el código fuente.

Consideraciones para el mercado europeo: MDR y Cyber Resilience Act

Los equipos que desarrollan software médico certificado para el mercado europeo deben tener en cuenta que IEC 62304 no opera en aislamiento. El Reglamento de Dispositivos Médicos (MDR 2017/745) exige la aplicación de IEC 62304 como norma armonizada, y el Cyber Resilience Act introduce obligaciones adicionales de ciberseguridad del producto que impactan directamente en el pipeline:

Obligación de gestión de vulnerabilidades durante todo el ciclo de vida del producto.
Notificación de vulnerabilidades activamente explotadas a ENISA en 24 horas.
Provisión de actualizaciones de seguridad gratuitas durante la vida útil esperada del producto.
Documentación técnica que incluya evaluación de riesgos de ciberseguridad.

Estas obligaciones refuerzan la necesidad de pipelines CI/CD con monitorización continua de vulnerabilidades, capacidad de despliegue rápido de parches y generación de SBOM actualizado en cada release.

Conclusión

Construir pipelines CI/CD conformes a IEC 62304 para software médico certificado no solo es posible: es la forma más eficiente y robusta de cumplir con los requisitos normativos. La automatización de compliance gates, la generación de SBOM, la trazabilidad de requisitos y el escaneo de vulnerabilidades transforman procesos que tradicionalmente eran manuales, lentos y propensos a errores en flujos reproducibles, auditables y rápidos.

La clasificación de seguridad del software (Clases A, B, C) proporciona la granularidad necesaria para ajustar la rigurosidad del pipeline al riesgo real, evitando la sobre-ingeniería en componentes de bajo riesgo sin comprometer la seguridad en los de riesgo alto. Herramientas como GitLab CI, Jenkins, Azure DevOps y Ketryx ofrecen capacidades complementarias que los equipos pueden combinar según su contexto tecnológico y regulatorio.

El SBOM, ya obligatorio para la FDA y referenciado en el Cyber Resilience Act europeo, es un ejemplo perfecto de cómo la automatización CI/CD convierte una obligación regulatoria en un paso más del pipeline, ejecutado en segundos y almacenado como artefacto inmutable junto a cada release.

Desde Informática Médica ayudamos a equipos de desarrollo de software médico a diseñar e implementar pipelines CI/CD que cumplen con IEC 62304, MDR y las exigencias emergentes del Cyber Resilience Act, sin sacrificar la agilidad que el mercado exige. Si tu equipo está buscando automatizar su camino hacia el cumplimiento normativo, hablemos.

Referencias

IEC 62304:2006+Amendment 1:2015. Medical device software -- Software life cycle processes. International Electrotechnical Commission.
IMDRF N73. Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity. International Medical Device Regulators Forum, 2023.
FDA. Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. U.S. Food and Drug Administration, junio 2025.
Johner Institute. IEC 62304 Compliance Guide. Disponible en: blog.johner-institute.com
Ketryx. Automated Compliance for Medical Device Software. Ketryx whitepaper, 2024.
NTIA. The Minimum Elements for a Software Bill of Materials (SBOM). National Telecommunications and Information Administration, 2021.
Reglamento (UE) 2017/745 del Parlamento Europeo y del Consejo, sobre los productos sanitarios (MDR).
Cyber Resilience Act. Reglamento (UE) relativo a requisitos horizontales de ciberseguridad para productos con elementos digitales. Parlamento Europeo, 2024.
OWASP. CycloneDX Specification. Disponible en: cyclonedx.org
Linux Foundation. SPDX Specification (ISO/IEC 5962:2021). Disponible en: spdx.dev