Cybersécurité automobile
UN R155, ISO/SAE 21434 et l'Automotive Threat Matrix de l'Auto-ISAC — comment le comportement des attaquants sur le véhicule est décrit, évalué dans la TARA et démontré en pentest.
De la première ligne de code à l’exploitation sur le terrain : Secure Coding, cycle de développement sécurisé (SSDLC), sécurité des pipelines et de la supply chain, sécurité des produits par type – CRA, IEC 62443, UN R155/R156 avec ISO/SAE 21434, MDR/IVDR.
Le développement sécurisé de logiciels et de produits (Secure Software Development) consiste à appliquer des exigences de sécurité démontrables sur tout le cycle de vie d’un produit – de la conception au code, au build et à la release, jusqu’au traitement des vulnérabilités sur le terrain. Le cadre dépend du type de produit : le matériel et les logiciels comportant des éléments numériques relèvent du Cyber Resilience Act (CRA), composants industriels compris ; pour ceux-ci, l’IEC 62443 fait figure d’état de l’art, et le règlement Machines s’y ajoute pour les machines dès le 20 janvier 2027. L’homologation de type des véhicules exige UN R155 et R156, généralement mis en œuvre via ISO/SAE 21434. Les dispositifs médicaux relèvent du MDR et de l’IVDR (règlements sur les dispositifs médicaux et de diagnostic in vitro), avec l’IEC 81001-5-1 comme référence. Véhicules homologués et dispositifs médicaux sont exclus du CRA : leur propre droit sectoriel s’applique.
Chaque thème mène à une page de savoir dédiée avec des approfondissements, des guides pratiques et les prestations correspondantes.
UN R155, ISO/SAE 21434 et l'Automotive Threat Matrix de l'Auto-ISAC — comment le comportement des attaquants sur le véhicule est décrit, évalué dans la TARA et démontré en pentest.
Secure Coding, mise en place du SSDLC et montée en compétence des développeurs — la sécurité comme partie intégrante du métier, pas comme correction a posteriori.
Durcir les chaînes de build, maîtriser les dépendances, signer les artefacts — de SBOM et SLSA jusqu’à la sécurité de pipeline assistée par IA.
C’est le type de produit qui détermine les exigences de cybersécurité applicables. Les quatre types de produits en un coup d’œil – avec leur champ d’application, les normes de référence et les échéances ; là où un droit sectoriel propre s’applique, le CRA s’efface.
Des obligations européennes transversales pour les fabricants de matériel et de logiciels connectés – de la planification et du développement jusqu’au traitement des vulnérabilités sur tout le cycle de vie.
Série de normes internationales pour des processus de développement, des composants et des systèmes sécurisés en automatisation industrielle – facultative, mais reconnue comme état de l’art et socle des futures normes harmonisées du CRA.
La cybersécurité conditionne l’homologation de type : les constructeurs ont besoin d’un système de management de la cybersécurité (CSMS) certifié et d’une gestion encadrée des mises à jour logicielles.
La sécurité informatique fait partie des exigences générales en matière de sécurité et de performances du MDR et de l’IVDR – à démontrer avant la mise sur le marché, puis à maintenir par la surveillance après commercialisation et la maintenance sur le terrain.
Où en êtes-vous ? Des auto-évaluations OWASP (SAMM, ISVS, SCVS) et VamiAppSec — notre plateforme propulsée par LLM pour un SDLC sécurisé et la conformité sécurité produit, avec VamiDAST entièrement intégré pour le DAST à IA.
Les scanners à base de règles trouvent de façon fiable les erreurs de syntaxe. L'autorisation cassée, la logique métier et les permissions supposées à tort n'ont, elles, aucune signature. Nous mettons règles, raisonnement IA et validation d'exploitabilité dans un ordre exploitable par vos équipes.
Prestation de conseil — les pages de connaissance ci-dessus restent en accès libre.
Des pages de connaissances approfondies sur les sujets qui soulèvent actuellement le plus de questions — avec des sources vérifiées et des mesures concrètes.
Comment hôpitaux, cabinets et laboratoires exploitent l’IA en sécurité : obligations des déployeurs selon l’AI Act, lien avec le MDR, responsabilité partagée avec le fournisseur, modèle de menaces pour l’IA médicale, évaluation des risques et preuves solides.
Accéder à la page de connaissancesComment fabricants et hôpitaux sécurisent les dispositifs médicaux connectés sur le terrain : inventaire et SBOM, triage clinique, correctifs maîtrisés, signalements de vulnérabilités organisés et circuits de notification coordonnés.
Accéder à la page de connaissancesComment les fabricants peuvent concevoir l’accès aux données des appareils exigé par la loi sans compromettre la sécurité des patients, les données de santé ni les secrets d’affaires – avec modèle de menaces, test d’intrusion et système de management intégré.
Accéder à la page de connaissancesLes modèles d’IA suggèrent des paquets qui n’existent pas — et des attaquants peuvent enregistrer précisément ces noms. Les agents de codage dotés d’un accès au terminal installent ce qu’ils jugent bon. Ce dossier relie typosquatting et slopsquatting dans npm et PyPI à un modèle de sécurité pour les agents de codage et leur harness : chaîne d’attaque, cinq couches de protection, obligations au titre du CRA, de NIS2 et de DORA, autoévaluation et livre blanc CISO (en allemand).
Accéder à la page de connaissancesComment la matrice de l'Auto-ISAC décrit le comportement des attaquants sur le véhicule – et comment elle donne un langage commun à la TARA selon l'ISO/SAE 21434, à la démonstration de conformité selon l'UN R155, aux catalogues de tests de l'OWASP et au Vehicle SOC.
Accéder à la page de connaissancesComment prévenir systématiquement les vulnérabilités : la cartographie actuelle issue du CWE Top 25 et de l'OWASP Top 10:2025, l'ASVS 5.0 comme référentiel d'exigences et les pratiques qui font la différence dans le quotidien du développement.
Accéder à la page de connaissancesL'analyse statique du code est le point de contrôle le plus référencé du cycle de développement sécurisé – et l'outil au plus grand potentiel de frustration. Ce que le SAST accomplit techniquement, où ses limites sont prouvées, quelles normes l'exigent et ce que l'IA est en train d'y changer.
Accéder à la page de connaissancesLes modèles de langage trient les findings, raisonnent sémantiquement au-delà des frontières de fonctions et trouvent de vrais zero-days. Ce qui en est prouvé, quels outils existent en 2026 et où se situent les nouvelles limites et risques — avec des sources plutôt que du marketing.
Accéder à la page de connaissancesComment intégrer systématiquement la sécurité dans chaque phase du développement logiciel – avec le NIST SSDF comme catalogue de pratiques, OWASP SAMM comme modèle de maturité et des security gates depuis les exigences jusqu'à l'exploitation.
Accéder à la page de connaissancesTop 10, ASVS, Cheat Sheet Series, Developer Guide, WSTG, SAMM et des outils comme Dependency-Track et ZAP : ce que chaque projet apporte – et comment ces briques s'articulent au quotidien du développement pour former un processus de bout en bout.
Accéder à la page de connaissancesComment identifier les risques de sécurité dès la phase de conception grâce au cadre des quatre questions, à STRIDE, à PASTA et aux arbres d'attaque – et ancrer durablement le threat modeling dans le SDLC et les équipes agiles.
Accéder à la page de connaissancesComment ancrer durablement les compétences en sécurité au sein de vos équipes de développement – de la sélection des bons champions au budget temps et à la communauté, jusqu'à la mesure du succès selon le guide OWASP et SAMM.
Accéder à la page de connaissancesComment générer, distribuer et exploiter des nomenclatures logicielles (SBOM) conformément aux standards – du choix du format à la corrélation continue des vulnérabilités, en passant par l'intégration au build.
Accéder à la page de connaissancesPourquoi les pipelines de build et de déploiement comptent parmi les systèmes les plus critiques de votre SI – et comment les sécuriser de manière structurée en s'appuyant sur les OWASP Top 10 CI/CD Security Risks et SLSA.
Accéder à la page de connaissancesPourquoi la sécurité des produits connectés exige des normes, des processus et des structures organisationnelles qui lui sont propres – de l'ISO/SAE 21434 au PSIRT, en passant par l'IEC 62443 et l'EN 18031.
Accéder à la page de connaissancesChaque livre blanc dispose de sa propre page avec les détails et un formulaire de téléchargement direct.
EU CRAEU Cyber Resilience Act — Guide pratique pour les produits numériquesVers la page Whitepaper
CI/CD SecurityCI/CD Pipeline Security : comment les attaquants prennent le contrôle de votre pipeline — et comment le reprendreVers la page Whitepaper
DevSecOpsOWASP Top 10 CI/CD Security Risks — guide pratique avec crosswalk de conformitéVers la page Whitepaper
Secure CodingSecure Coding à l'ère de l'IA : le CWE Top 25 (2025) et le Secure-by-DesignVers la page Whitepaper
Sécurité IA & CI/CDLa sécurité assistée par IA dans le pipeline CI/CDVers la page Whitepaper
Cybersécurité automobileAutomotive Threat Matrix — ATT&CK pour les véhiculesVers la page Whitepaper
Chaîne d’approvisionnement / agents IASlopsquatting & Coding-Agenten für CISOs — sécuriser la chaîne d’approvisionnement logicielle IAVers la page Whitepaper Quel cadre s’applique à quel produit – et où le Cyber Resilience Act ne s’applique-t-il pas ? Des réponses concises aux questions que posent souvent les fabricants et les responsables des affaires réglementaires.
Non. Les produits relevant du MDR ou de l’IVDR sont exclus du Cyber Resilience Act. Leur cybersécurité est encadrée par ces deux règlements sur les dispositifs médicaux ; le guide MDCG 2019-16 Rev. 1 et la norme IEC 81001-5-1, toujours non harmonisée, servent de référence. Les logiciels et équipements sans destination médicale – l’informatique hospitalière générale, par exemple – peuvent en revanche tout à fait relever du CRA.
Pas aux voitures, bus, camions et remorques homologués : ils relèvent de l’homologation de type de l’UE, qui encadre la cybersécurité par l’UN R155 et les mises à jour logicielles par l’UN R156. L’exclusion couvre en général aussi les systèmes et composants homologués pour ces véhicules. Depuis 2025, un acte délégué exclut en outre deux-roues, trois-roues et quads ; pour les nouveaux types de cette catégorie, l’UN R155 s’applique à partir du 11 décembre 2027. Produits de seconde monte, équipements de recharge ou applications hors homologation peuvent en revanche relever du CRA. Les cycles à pédales de la catégorie L1e restent également soumis au CRA.
Non, l’IEC 62443 est une série de normes internationales, pas une loi. Elle fait toutefois figure d’état de l’art pour les composants industriels et est en cours d’adaptation au CRA – notamment par des amendements d’EN IEC 62443-4-1 et -4-2 et par des profils propres à certains produits. La présomption de satisfaire aux exigences légales (présomption de conformité) ne naît qu’une fois une version harmonisée citée au Journal officiel de l’UE ; en octobre 2026, ce n’est pas le cas.
Depuis le 11 septembre 2026, les fabricants doivent notifier les vulnérabilités activement exploitées et les incidents graves au CSIRT national compétent via la plateforme centrale de l’ENISA (Single Reporting Platform). Les délais : alerte précoce sous 24 heures, notification sous 72 heures, rapport final au plus tard 14 jours après la mise à disposition d’un correctif – pour les incidents, dans le mois qui suit la notification. L’obligation vaut aussi pour les produits mis sur le marché avant cette date.
L’UN R155 est un règlement d’homologation de type contraignant : sans système de management de la cybersécurité (CSMS) certifié, un type de véhicule n’est pas homologué. L’ISO/SAE 21434 est, elle, la norme d’ingénierie avec laquelle constructeurs et équipementiers mettent en œuvre les processus exigés, comme l’analyse des menaces et l’évaluation des risques (Threat Analysis and Risk Assessment, TARA). Elle n’est pas imposée par la loi, mais constitue la voie de preuve habituelle ; les lacunes, comme le catalogue de menaces de la R155, sont couvertes séparément.
Pas encore. La demande de normalisation de la Commission porte sur 41 normes horizontales et spécifiques aux produits. Selon un projet de modification, non adopté en octobre 2026, les premières normes horizontales devraient être disponibles fin octobre 2026 et les normes spécifiques fin décembre 2026. Tant qu’aucune version n’est citée au Journal officiel, il n’y a pas de présomption de conformité : les fabricants justifient eux-mêmes le respect des exigences, et les produits importants de classe I doivent alors passer par un organisme notifié.
Lors du premier entretien, nous évaluons la maturité de votre SSDLC — et identifions les mesures qui offrent le plus grand levier dans le pipeline, le code et l’homologation produit.