Trop peu d'ingénieurs sécurité : automatisation, IA et SOP propre
Trop peu de spécialistes pour tester chaque ECU à chaque release. L'automatisation pilotée par l'IA permet à une petite équipe d'atteindre un SOP propre.
Tom Zaubermann · Publié le · 8 min de lecture
Il n’y a pas assez de monde pour faire ce travail. C’est le fait dérangeant qui se cache derrière la cybersécurité automobile, et il s’aggrave au lieu de s’améliorer.
Le calcul ne tient pas
Les études sur les effectifs menées par l’ISC2 chiffrent le déficit mondial en cybersécurité en millions, environ 4.8 million selon leur estimation 2026, le secteur devant croître d’environ 87% pour répondre à la demande. Près de 90% des équipes de sécurité déclarent un manque de compétences.
Resserrons maintenant sur l’automobile. Tester un ECU, ce n’est pas de la sécurité informatique générale. Cela demande des personnes qui connaissent CAN et CAN FD, UDS et DoIP, SecurityAccess, les sessions de diagnostic et les contraintes temps réel d’une cible embarquée, et qui savent relier tout cela à ISO/SAE 21434. C’est un sous-ensemble minuscule et surchargé d’un domaine déjà en pénurie. Pendant ce temps, le marché de la cybersécurité automobile croît vite, d’environ quatre milliards de dollars en 2026 vers douze milliards et au-delà au début des années 2030. La demande grimpe une falaise alors que le vivier de personnes capables de réellement tester un calculateur bouge à peine.
Comptez ensuite le travail. Un programme véhicule moderne compte des dizaines d’ECU. Chacun connaît de nombreuses releases avant la production, et d’autres après. Si le test de sécurité approfondi dépend de la réservation d’un des rares spécialistes pour chaque release de chaque ECU, la file d’attente est plus longue que le programme. Quelque chose cède, et c’est en général le test.
Le SOP est un mur que l’on ne heurte qu’une fois
Le démarrage de production ne bouge pas. Quand un véhicule atteint le SOP, le coût d’un défaut de sécurité change complètement : ce qui n’était qu’un commentaire de revue de code avant le lancement de la ligne devient, après, une campagne terrain ou un rappel. Et sous UN R155 et ISO/SAE 21434, vous ne pouvez pas simplement livrer en espérant. Vous devez démontrer que les mesures d’atténuation ont été testées et que les problèmes connus ont été traités.
La vraie cible est donc précise : atteindre le SOP sans aucune cible facile connue. Pas un ECU parfait, que personne ne peut promettre, mais un ECU où les constats évidents, à fort impact et de la première heure ont disparu et sont documentés. Services de diagnostic accessibles sans authentification. SecurityAccess faible ou par défaut. XCP ou CCP exposés. Identifiants modifiables qui devraient être verrouillés. Ils sont fréquents, ils sont dévastateurs, et ils sont totalement évitables, à condition que quelqu’un les teste à chaque release.
C’est cette dernière condition qui pose tout le problème. Un seul pentest pré-SOP est un instantané du logiciel que vous aviez cette semaine-là. L’ECU ne cesse de changer. Une fonction ajoutée deux sprints plus tard rouvre discrètement un service, et personne ne reteste jusqu’au prochain audit, moment où c’est déjà dans la voiture.
Vous ne pouvez pas recruter pour vous en sortir. Vous pouvez démultiplier
L’instinct est de recruter davantage de spécialistes. C’est le bon instinct et il ne suffit pas, parce que les gens ne sont pas là pour être recrutés, et que même une équipe doublée ne peut pas retester manuellement chaque release de chaque ECU.
C’est là que l’IA et l’automatisation changent l’économie unitaire, et il vaut la peine d’être précis sur la manière. L’IA ne comblera pas le manque de compétences à elle seule, et quiconque vous dit qu’elle remplace vos ingénieurs sécurité vous vend quelque chose. Ce qu’elle fait bien, c’est faire monter en puissance l’équipe que vous avez déjà : encoder ce qu’un bon testeur fait à la main dans des moteurs qui tournent sans lui, pour que les rares humains soient consacrés au travail que seuls des humains peuvent faire.
Concrètement, le savoir-faire pour énumérer une pile UDS, sonder SecurityAccess, fuzzer une interface en toute sécurité ou parcourir une passerelle DoIP est stable et répétable. Il n’exige pas la présence d’un spécialiste à chaque fois. Il exige un spécialiste une fois, pour construire le test, puis une machine pour l’exécuter à chaque release, indéfiniment. Le spécialiste est alors libre pour le chemin d’attaque inédit, la TARA, la chose que l’automatisation ne peut pas imaginer.
À quoi cela ressemble dans un vrai programme
C’est exactement pour cela qu’AutoST est conçu. Ses moteurs portent le savoir-faire de test : énumération UDS, analyse SecurityAccess (0x27), fuzzing UDS et CAN, DoIP et SOME/IP, IVI Android. Vous reliez l’ECU à un banc une fois, et à partir de là AutoST s’exécute depuis l’API et dans la CI.
Le test passe ainsi de « un spécialiste, si l’un est disponible, avant l’audit » à « automatiquement, à chaque release majeure ». Chaque build de chaque ECU reçoit la même passe de sécurité de référence. La cible facile est attrapée à l’instant où elle est introduite, et non découverte dans la voiture. À l’arrivée au SOP, vous disposez d’une piste datée montrant que chaque release a été testée et que les problèmes connus ont été clos, ce qui est précisément ce qu’un évaluateur ISO/SAE 21434 veut voir.
Et les quelques ingénieurs sécurité que vous avez cessent de dépenser leurs heures rares à retrouver le même SecurityAccess faible sur le quarantième ECU. Ils les consacrent aux attaques qui exigent réellement un humain.
La version honnête
L’automatisation ne rend pas les ingénieurs sécurité inutiles. Elle fait compter ceux que vous avez. AutoST prend en charge l’étendue et la régression pour qu’une petite équipe puisse couvrir tout un programme véhicule et atteindre le SOP sans aucune cible facile connue. La profondeur, la créativité, la TARA et l’audit ont encore besoin de personnes, et Zyberum les apporte aussi, en tant qu’équipe ayant mené des programmes Tier 1, Tier 2 et OEM à travers exactement cela. Des références sont disponibles sur demande.
Si votre programme compte plus d’ECU que d’ingénieurs sécurité, ce qui est le cas de presque tous, c’est précisément cet écart qu’AutoST a été conçu pour combler. Réservez une démo et nous vous montrerons à quoi ressemble vraiment le test de chaque release.
FAQ
Questions fréquentes
L'IA va-t-elle remplacer les ingénieurs en sécurité automobile ?
Non. L'IA et l'automatisation prennent en charge les tests larges et répétables : les schémas d'attaque connus, la régression, les cibles faciles. Les spécialistes restent indispensables pour les chemins d'attaque inédits, la TARA et le travail créatif. L'intérêt d'un outil comme AutoST est de démultiplier les quelques experts que vous avez, pas de les remplacer.
Pourquoi tester un ECU à chaque release majeure et pas seulement une fois ?
Parce que l'ECU change à chaque release, et qu'un seul pentest pré-SOP ne vous renseigne que sur le logiciel que vous aviez cette semaine-là. Des régressions de sécurité se glissent avec les nouvelles fonctions. Tester chaque release majeure est le seul moyen d'atteindre le démarrage de production sans aucun problème connu.
Qu'est-ce qu'une 'cible facile' dans la sécurité des ECU ?
Les constats qu'un testeur compétent obtient dès la première heure : services de diagnostic accessibles sans authentification, SecurityAccess faible ou par défaut, interfaces de calibration exposées, identifiants modifiables. Ils sont fréquents, à fort impact, et exactement le genre de chose que l'automatisation peut détecter à chaque build pour que les humains n'aient jamais à le faire.