Reservar cita

Desarrollo seguro de software y de productos

Desde la primera línea de código hasta el uso en campo: Secure Coding, proceso de desarrollo seguro (SSDLC), seguridad del pipeline y de la cadena de suministro y seguridad de producto por tipo – CRA, IEC 62443, UN R155/R156 con ISO/SAE 21434, MDR/IVDR.

Actualizado: octubre de 2026 · Valeri Milke, Lead Auditor ISO 27001 e ISO 42001

El desarrollo seguro de software y de productos (Secure Software Development) consiste en aplicar de forma demostrable los requisitos de seguridad en todo el ciclo de vida de un producto: del diseño, el código, el build y el release a la gestión de vulnerabilidades en campo. La normativa aplicable depende del tipo de producto. El hardware y el software con elementos digitales, incluidos los componentes industriales, están sujetos al Cyber Resilience Act (CRA); para estos últimos, la serie IEC 62443 es el estado de la técnica y, en las máquinas, desde el 20 de enero de 2027 rige además el Reglamento de Máquinas. Los vehículos necesitan UN R155 y R156 para la homologación de tipo, normalmente con ISO/SAE 21434. Los productos sanitarios se rigen por el Reglamento de Productos Sanitarios (MDR) y el IVDR, con IEC 81001-5-1 como referencia; al igual que los vehículos homologados, quedan excluidos del CRA por contar con normativa sectorial propia.

Temas y páginas de conocimiento

Cada tema conduce a una página de conocimiento propia con contenidos en profundidad, guías prácticas y los servicios correspondientes.

Seguridad de producto según el tipo de producto

Qué requisitos de ciberseguridad se aplican depende del tipo de producto. Los cuatro tipos de un vistazo, con su ámbito de aplicación, las normas determinantes y las fechas clave; allí donde rige una normativa sectorial propia, el CRA cede el paso.

CRA – Productos con elementos digitales

Obligaciones de la UE para todos los sectores dirigidas a fabricantes de hardware y software conectados: desde la planificación y el desarrollo hasta la gestión de vulnerabilidades durante todo el ciclo de vida.

Productos
Hardware y software con elementos digitales: desde dispositivos de hogar inteligente, routers y sistemas operativos hasta apps
Normativa y normas
Cyber Resilience Act; normas armonizadas (EN 40000, ETSI EN 304) en elaboración, ninguna aún en el DOUE; plataforma de notificación de ENISA
Fechas clave
En vigor 10/12/2024 · Normas sobre organismos notificados 11/06/2026 · Notificación 11/09/2026 · Plena aplicación 11/12/2027

IEC 62443 – Industria y OT

Serie internacional de normas para procesos de desarrollo, componentes y sistemas seguros de automatización industrial: voluntaria, pero reconocida como estado de la técnica y base de las futuras normas armonizadas del CRA.

Productos
Componentes y sistemas de automatización industrial (OT), controladores y máquinas, para fabricantes, integradores y operadores
Normativa y normas
IEC 62443-4-1 (desarrollo), -4-2 (componentes), -3-3 (sistemas), -2-1 (operadores); CRA; Reglamento de Máquinas
Fechas clave
Reglamento de Máquinas desde el 20/01/2027 · Adaptación de EN IEC 62443-4-1/-4-2 al CRA en curso

Vehículos – UN R155/R156 e ISO/SAE 21434

La ciberseguridad es requisito para la homologación de tipo: los fabricantes de vehículos necesitan un sistema de gestión de la ciberseguridad (CSMS) certificado y una gestión ordenada de las actualizaciones de software.

Productos
Turismos, autobuses y camiones (M, N), remolques (O) en actualizaciones; nuevos tipos de dos/tres ruedas y cuatriciclos (L) desde 11/12/2027
Normativa y normas
UN R155 (CSMS), UN R156 (actualizaciones de software), ISO/SAE 21434 como estándar de ingeniería; excluidos del CRA
Fechas clave
R155: tipos nuevos desde 06/07/2022, toda nueva matriculación desde 07/07/2024 (gran serie) · R156: tipos existentes desde 07/07/2026

Productos sanitarios – MDR e IVDR

La seguridad informática forma parte de los requisitos generales de seguridad y funcionamiento del MDR y el IVDR: debe demostrarse antes de la introducción en el mercado y mantenerse con el seguimiento poscomercialización y el mantenimiento en campo.

Productos
Productos sanitarios y productos para diagnóstico in vitro, incluido el software como producto sanitario; excluidos del CRA
Normativa y normas
MDR/IVDR, MDCG 2019-16 Rev. 1, IEC 81001-5-1 (referencia reconocida, no armonizada), Reglamento de IA para productos con IA, Data Act para productos conectados
Fechas clave
MDR desde 26/05/2021 · IVDR desde 26/05/2022 · Obligaciones de alto riesgo del Reglamento de IA para productos con IA desde 02/08/2028
Consultoría · AI Code Security

Cuando las reglas ya no bastan: seguridad del código en la era de la IA

Los escáneres basados en reglas encuentran de forma fiable los fallos de sintaxis. La autorización rota, la lógica de negocio y los permisos asumidos por error no tienen ninguna firma. Ordenamos reglas, razonamiento de IA y validación de explotabilidad de forma operable para su equipo.

  • Arquitectura de escaneo capas 1–3
  • Implantar y calibrar AI SAST
  • Validación de explotabilidad
  • Responsabilidad y remediación
  • Evidencias para CRA y NIS2
Ver AI Code Security

Servicio de consultoría — las páginas de conocimiento de arriba siguen siendo de acceso libre.

Deep Dives

Páginas de conocimiento en profundidad sobre los temas que actualmente generan más preguntas — con fuentes verificadas y medidas concretas.

Gestión de riesgos de IA en sanidad

Cómo hospitales, consultas y laboratorios operan la IA con seguridad: obligaciones del AI Act junto con el MDR, responsabilidad compartida con el proveedor, un modelo de amenazas para la IA médica, evaluación de riesgos y evidencias sólidas.

Ir a la página de conocimiento

Mantenimiento de productos sanitarios

Cómo fabricantes y hospitales mantienen seguros en campo los productos sanitarios conectados: con inventario y SBOM, triaje con criterio clínico, parches como cambio controlado, divulgación ordenada de vulnerabilidades y vías de notificación coordinadas.

Ir a la página de conocimiento

Data Act y productos sanitarios

Cómo diseñan los fabricantes el acceso a los datos de sus equipos que exige la ley sin poner en riesgo la seguridad del paciente, los datos de salud ni los secretos comerciales: con modelo de amenazas, prueba de penetración y sistema de gestión integrado.

Ir a la página de conocimiento

Slopsquatting y agentes de código

Los modelos de IA sugieren paquetes que no existen, y los atacantes pueden registrar precisamente esos nombres. Los agentes de código con acceso al terminal instalan lo que consideran correcto. Este análisis en profundidad conecta el typosquatting y el slopsquatting en npm y PyPI con un modelo de seguridad para agentes de código y su harness: cadena de ataque, cinco capas de protección, obligaciones según el CRA, NIS2 y DORA, autoevaluación y whitepaper para CISO (en alemán).

Ir a la página de conocimiento

Automotive Threat Matrix

Cómo la matriz del Auto-ISAC describe el comportamiento de los atacantes en el vehículo, y cómo dota de un lenguaje común al TARA según ISO/SAE 21434, a las evidencias exigidas por UN R155, a los catálogos de pruebas de OWASP y al Vehicle SOC.

Ir a la página de conocimiento

Secure Coding

Cómo evitar vulnerabilidades de forma sistemática: el mapa actual formado por el CWE Top 25 y el OWASP Top 10:2025, el ASVS 5.0 como marco de requisitos y las prácticas que marcan la diferencia en el día a día del desarrollo.

Ir a la página de conocimiento
FAQ

Preguntas frecuentes sobre seguridad de producto por tipo de producto

¿Qué normativa se aplica a cada producto y dónde no rige el Cyber Resilience Act? Respuestas breves a las preguntas que suelen plantear los fabricantes y los responsables de asuntos regulatorios.

¿Se aplica el Cyber Resilience Act a los productos sanitarios?

No. Los productos sujetos al MDR o al IVDR están excluidos del Cyber Resilience Act. Su ciberseguridad la regulan los dos reglamentos de productos sanitarios; como referencia sirven la guía MDCG 2019-16 Rev. 1 y la norma IEC 81001-5-1, que por ahora no está armonizada. En cambio, el software y los equipos sin finalidad médica prevista —por ejemplo, la TI hospitalaria general— sí pueden estar sujetos al CRA.

¿Se aplica el CRA a los automóviles y a los componentes de vehículos?

No a los turismos, autobuses, camiones y remolques homologados: dependen de la homologación de tipo de la UE, que regula la ciberseguridad mediante UN R155 y las actualizaciones de software mediante UN R156. La exclusión suele abarcar también los sistemas y componentes homologados para esos vehículos. Desde 2025, un acto delegado excluye además los vehículos de dos y tres ruedas y los cuatriciclos; a los nuevos tipos de esta categoría se les aplica UN R155 desde el 11 de diciembre de 2027. Los productos de posventa, los equipos de recarga o las apps fuera de la homologación de tipo sí pueden estar sujetos al CRA. Las bicicletas con pedales de la categoría L1e siguen sujetas también al CRA.

¿Es obligatoria la IEC 62443?

No. La IEC 62443 es una serie de normas internacionales, no una ley. Sin embargo, se considera el estado de la técnica para los componentes industriales y se está adaptando al CRA, entre otras cosas mediante ajustes de EN IEC 62443-4-1 y -4-2 y perfiles específicos de producto. La presunción de que se cumplen los requisitos legales (presunción de conformidad) solo surge cuando una versión armonizada se cita en el Diario Oficial de la UE; a octubre de 2026, no es el caso.

¿Desde cuándo rige la obligación de notificación del CRA y dónde se notifica?

Desde el 11 de septiembre de 2026, los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves al CSIRT nacional competente a través de la plataforma única de notificación de ENISA (Single Reporting Platform). Los plazos: alerta temprana en 24 horas, notificación en 72 horas e informe final a más tardar 14 días después de disponer de una corrección; en el caso de incidentes, en el plazo de un mes desde la notificación. La obligación afecta también a los productos introducidos en el mercado antes de esa fecha.

¿Qué diferencia hay entre UN R155 e ISO/SAE 21434?

UN R155 es un reglamento de homologación de tipo vinculante: sin un sistema de gestión de la ciberseguridad (CSMS) certificado, un tipo de vehículo no obtiene la homologación. ISO/SAE 21434, en cambio, es el estándar de ingeniería con el que fabricantes y proveedores implantan los procesos exigidos, como el análisis de amenazas y evaluación de riesgos (Threat Analysis and Risk Assessment, TARA). La norma no es obligatoria por ley, pero es la vía habitual para demostrar el cumplimiento; las lagunas, como el catálogo de amenazas de R155, los fabricantes las cubren por separado.

¿Existen ya normas armonizadas para el CRA?

Todavía no. El mandato de normalización de la Comisión abarca 41 normas horizontales y específicas de producto. Según un proyecto de modificación que, a octubre de 2026, no se ha adoptado, las primeras normas horizontales deberían estar listas a finales de octubre de 2026 y las específicas de producto a finales de diciembre de 2026. Mientras no se cite ninguna versión en el Diario Oficial, no hay presunción de conformidad: los fabricantes justifican por sí mismos el cumplimiento de los requisitos, y los productos importantes de la clase I necesitan entonces un organismo notificado.

Haga de la seguridad parte de su desarrollo

En la primera consulta evaluamos su nivel de madurez SSDLC — y le mostramos qué medidas en el pipeline, el código y la homologación del producto tienen el mayor efecto palanca.