Ciberseguridad del automóvil
UN R155, ISO/SAE 21434 y la Automotive Threat Matrix del Auto-ISAC — cómo se describe el comportamiento de los atacantes en el vehículo, cómo se evalúa en el TARA y cómo se demuestra en el pentest.
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.
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.
Cada tema conduce a una página de conocimiento propia con contenidos en profundidad, guías prácticas y los servicios correspondientes.
UN R155, ISO/SAE 21434 y la Automotive Threat Matrix del Auto-ISAC — cómo se describe el comportamiento de los atacantes en el vehículo, cómo se evalúa en el TARA y cómo se demuestra en el pentest.
Secure Coding, implantación del SSDLC y capacitación de desarrolladores — la seguridad como parte del oficio, no como corrección posterior.
Endurecer las cadenas de build, dominar las dependencias, firmar los artefactos — de SBOM y SLSA a la seguridad de pipeline impulsada por IA.
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.
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.
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.
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.
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.
¿En qué punto está? Autoevaluaciones según OWASP (SAMM, ISVS, SCVS) y VamiAppSec, nuestra plataforma con LLM para un SDLC seguro y cumplimiento de seguridad de producto, con VamiDAST totalmente integrado para DAST con 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.
Servicio de consultoría — las páginas de conocimiento de arriba siguen siendo de acceso libre.
Páginas de conocimiento en profundidad sobre los temas que actualmente generan más preguntas — con fuentes verificadas y medidas concretas.
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 conocimientoCó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 conocimientoCó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 conocimientoLos 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 conocimientoCó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 conocimientoCó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 conocimientoEl análisis estático de código es el punto de control con más referencias cruzadas del ciclo de desarrollo seguro – y a la vez la herramienta con mayor potencial de frustración. Qué aporta técnicamente el SAST, dónde están probados sus límites, qué estándares lo exigen y qué está cambiando la IA ahora mismo.
Ir a la página de conocimientoLos modelos de lenguaje trían hallazgos, razonan semánticamente más allá de los límites de las funciones y encuentran zero-days reales. Qué está probado, qué herramientas existen en 2026 y dónde están los nuevos límites y riesgos — con fuentes en lugar de marketing.
Ir a la página de conocimientoCómo integrar la seguridad de forma sistemática en cada fase del desarrollo de software – con el NIST SSDF como catálogo de prácticas, OWASP SAMM como modelo de madurez y security gates desde los requisitos hasta la operación.
Ir a la página de conocimientoTop 10, ASVS, Cheat Sheet Series, Developer Guide, WSTG, SAMM y herramientas como Dependency-Track y ZAP: qué aporta cada proyecto y cómo estas piezas se combinan en el día a día del desarrollo para formar un proceso continuo.
Ir a la página de conocimientoCómo identificar los riesgos de seguridad ya en la fase de diseño con el marco de las cuatro preguntas, STRIDE, PASTA y árboles de ataque, y cómo anclar el threat modeling de forma permanente en el SDLC y en los equipos ágiles.
Ir a la página de conocimientoCómo anclar de forma duradera el conocimiento en seguridad en sus equipos de desarrollo: desde la selección de los champions adecuados, pasando por el presupuesto de tiempo y la comunidad, hasta la medición del éxito según la guía OWASP y SAMM.
Ir a la página de conocimientoCómo generar, distribuir y explotar operativamente listas de materiales de software (SBOM) conforme a los estándares: desde la elección del formato y la integración en el build hasta la correlación continua de vulnerabilidades.
Ir a la página de conocimientoPor qué los pipelines de build y despliegue se cuentan entre los sistemas más críticos de su TI, y cómo protegerlos de forma estructurada siguiendo los OWASP Top 10 CI/CD Security Risks y SLSA.
Ir a la página de conocimientoPor qué la seguridad de los productos conectados exige normas, procesos y estructuras organizativas propias: desde ISO/SAE 21434 hasta el PSIRT, pasando por IEC 62443 y EN 18031.
Ir a la página de conocimientoCada whitepaper cuenta con una página propia con detalles y un formulario de descarga directo.
EU CRAEU Cyber Resilience Act — Guía práctica para productos digitalesIr a la página del whitepaper
CI/CD SecurityCI/CD Pipeline Security: cómo los atacantes se apoderan de su pipeline — y cómo recuperarlaIr a la página del whitepaper
DevSecOpsOWASP Top 10 CI/CD Security Risks — Guía práctica con crosswalk de cumplimientoIr a la página del whitepaper
Secure CodingSecure Coding en la era de la IA: el CWE Top 25 (2025) y Secure-by-DesignIr a la página del whitepaper
Seguridad IA y CI/CDSeguridad impulsada por IA en el pipeline CI/CDIr a la página del whitepaper
Automotive CybersecurityAutomotive Threat Matrix — ATT&CK para vehículosIr a la página del whitepaper
Cadena de suministro / agentes de IASlopsquatting & Coding-Agenten für CISOs — proteger la cadena de suministro de software con IAIr a la página del whitepaper ¿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.
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.
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.
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 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.
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.
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.
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.