Correlens

Cas d'utilisation · Véhicules définis par logiciel

Lorsque le véhicule est logiciel, la sécurité est une discipline de version.

Un véhicule défini par logiciel dissocie le logiciel du matériel sur lequel il est déployé : les fonctions, auparavant réparties entre une centaine d’ECUs fixes, sont regroupées sur des contrôleurs zonaux et des calculateurs centraux ; les fonctionnalités arrivent par mises à jour à distance, et le véhicule évolue en permanence. Selon les estimations du secteur, un véhicule haut de gamme embarque déjà environ cent millions de lignes de code, et les projections tablent sur plusieurs fois ce volume. Chaque version modifie le profil de risque ; le travail de sécurité doit donc évoluer au même rythme.

Réserver une démonstration
Cas d'utilisation · Véhicules définis par logiciel

Ce qui a changé

La voiture est devenue un ordinateur avec une garantie.

Trois transformations définissent le véhicule défini par logiciel, et chacune redéfinit ce que signifie le sécuriser.

L'architecture consolidéeECUs distribué cède la place à des contrôleurs zonaux et à des ordinateurs centraux hautes performances derrière une abstraction matérielle et des interfaces orientées services. Moins de câblage, plus de logiciels et des risques concentrés sur le calcul partagé.
Le produit n'est jamais terminéFonctionnalités, correctifs et modèles économiques entiers sont déployés à distance tout au long d’une vie de véhicule pouvant atteindre vingt ans. L’inventaire logiciel qu’un régulateur examine aujourd’hui n’est pas celui qui circulera au trimestre suivant.
Deux mondes partagent le même siliciumLes fonctions certifiées en matière de sécurité et le code grand public à évolution rapide s'exécutent désormais côte à côte sur les mêmes ordinateurs, construits par des équipes avec des chaînes d'outils, des cadences et des définitions de tâches différentes.

Never finished, in practice

The update ships to the driveway, not the workshop.

An over-the-air release lands as one tap for the driver and a fleet-wide software change for you: new components, new versions, new exposure, all under type-approval obligations. The moment it is confirmed on that screen, your inventory has changed.

Driver confirming an over-the-air software update on the infotainment screen
One confirmation on the screen; one release across the fleet.

La partie difficile

L’enfer de l’intégration est un problème de sécurité.

Les défis recensés par le secteur du véhicule défini par logiciel sont précisément ceux qui déterminent si la sécurité parvient à suivre. Leur point commun : chacun modifie votre inventaire logiciel plus vite qu’une évaluation annuelle ne peut le constater.

Échelle Des centaines de sous-systèmes et de piles interdépendants ; les projections de l'industrie prévoient plusieurs centaines de millions de lignes de code par véhicule d'ici 2030.
Intégration Les logiciels de dizaines d’organisations n’ayant jamais partagé la même chaîne d’outils doivent converger vers une architecture unique, version après version.
Cycle de vie de OTA Chaque campagne de mise à jour est une version logicielle à l'échelle de la flotte : testée, sécurisée et prise en compte par variante, à l'échelle automobile.
Coexistence héritée Le calcul central nouveau et les ECUs de l'ère CAN qui ne peuvent pas être mis à jour par la transmission de l'air sont tous deux votre surface d'attaque.
Homologation continue La certification au début de la production échoue lorsque le logiciel continue de changer ; les preuves de R155, R156 et ISO/SAE 21434 doivent rester à jour avec la flotte.
Rythme de sécurité Une surface d’attaque croissante et une base de code changeante signifient que la surveillance des vulnérabilités doit s’exécuter à la vitesse de publication, et non à la vitesse d’audit.

Où Correlens s'inscrit

Un travail de sécurité qui évolue à la vitesse des mises à jour.

Une mise à jour est un événement à risqueChaque OTA modifie l'inventaire logiciel. Chaque version est comparée à la précédente, et ce qui a changé est réenrichi automatiquement : nouveaux composants, nouvelles versions, nouvelle exposition.
L'intégration, inventoriéeAdaptive AUTOSAR, Linux embarqué, Android Automotive et les piles RTOS de sûreté coexistent dans un même véhicule. Un inventaire unique rattache chaque composant au nœud et au programme sur lesquels il s’exécute réellement.
OTA avec un enregistrementUNECE R156 et ISO 24089 attendent que les mises à jour soient gérées et comptabilisées. Une différence de version à version est exactement le registre au niveau du composant que demande une revue de mise à jour.
Continuel, pas annuelLa surveillance et le triage avancent au rythme de votre pipeline, conformément aux activités continues prévues par la clause 8 d’ISO/SAE 21434 ; l’évaluation annuelle cesse ainsi d’être un travail d’archéologie.

La boucle de libération

De la construction à la flotte, avec les preuves jointes.

La plateforme se trouve à côté de votre pipeline de versions, et non à l'intérieur de votre base de code : chaque nomenclature logicielle qui quitte la construction est contrôlée, enrichie et comparée, et la file d'attente des résultats suit la version, pas le calendrier.

  • L'enfer de l'intégration, rendu lisible. Lorsqu'un fournisseur ajoute une nouvelle pile dans la version, la différence montre ce qui a réellement changé et ce qu'elle apporte.
  • Les régressions apparaissent immédiatement. Un composant déclassé ou réintroduit est une ligne de différence, ce qui n'est pas une surprise lors du prochain audit.
  • La file d'attente suit le déploiement. Les résultats sont attachés à la version qui les a introduits, avec un propriétaire et un état.
Version 24.31 vs 24.26données d’exemple
+38
added
-11
removed
57
changed
9
new findings
2
regressions
OTAota-agent 1.7 → 1.8 · Telematics4 NEW CVES
OTAnav-render 2.9 → 3.0 · IVI Head UnitCLEAN
OTAtls-lib 5.6.3 → 5.4.0 · GatewayDOWNGRADE
données d’exemple · release-to-release diff, enriched on import

Apportez un cycle de publication à la démo.

Réserver une démonstration