Automobilsysteme sind per se sogenannte sicherheitskritische Systeme. Hierbei ist Safety die innere Sicherheit, also die Eigenschaft, dass das Fahrzeug dem Benutzer und der Umwelt nicht schadet. Security auf der anderen Seite beschreibt die Eigenschaft, dass der Nutzer und die Umwelt dem Fahrzeug nicht schaden. Während Safety in Fahrzeugen eine lange Tradition hat, ist Security ein relativ neues Thema. Durch den steigenden Software- und Vernetzungsgrad sind eine Diebstahlwarnanlage und Wegfahrsperre nicht mehr ausreichend. Außerdem bedingen der begrenzte Platz und die Kostenanforderungen ein möglichst schlankes Design. 

Moderne Fahrzeuge benötigen daher Security-by-design, ohne dabei Safety auszuhebeln. Das bedeutet, dass Security bereits zu Beginn des Entwicklungsprozesses bedacht und integriert werden muss. Typischerweise werden für Safety und Security eigene Entwicklungsprozesse mit entsprechenden Schnittstellen zum funktionalen Entwicklungsprozess definiert. Dieser Entwicklungsprozess unterliegt Einflüssen durch verschiedene Standards und Richtlinien. Beispiele hierfür sind im Bereich Safety die ISO 26262 als abgeleiteter Standard von der IEC 61508, der Mutternorm für Safety sowie das Produkthaftungsgesetz. Von Seiten der Unternehmen gibt es häufig ebenfalls Richtlinien welche bspw. Codierungsrichtlinien oder Richtlinien für das Testen von Softwaresystemen betreffen. Aufgrund der langen Tradition von Safety in Fahrzeugen sind hier die Entwicklungsprozesse schon gut definiert und an den normativen Einflüssen ausgerichtet. 

Auf Seiten Security ist dies anders. Die erste Referenz für die Integration von Security in Fahrzeuge war SAE J3061 "Cyber Security Guidebook for Cyber-Physical Vehicle Systems" als Richtlinie welche lediglich Confidentiality (Vertraulichkeit) berücksichtigte. Die übergeordneten Standards ISO/SAE 21434 "Road Vehicles – Cyber Security Engineering" und UNECE No. R155 "Proposal for a new UN Regulation on uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system" wurden erst 2021 veröffentlicht. Für die langen Entwicklungszeiten in der Automobilindustrie war das zu knapp. Daher mussten aktuell in der Entwicklung befindliche Fahrzeuge bereits mit Hilfe der Entwurfsstände der Normen entwickelt werden. Das bedeutet, dass sich hier die Frage stellte, wie Security und die normativen Bedingungen in den bestehenden Entwicklungsprozess integriert werden kann bzw. ein Security-Entwicklungsprozess mit passenden Schnittstellen definiert werden kann.

Das Ergebnis ist ein im groben 4-stufiger Entwicklungsprozess. Beginnend mit der Prozessplanung, also der Adaption an das nächste Fahrzeugprojekt. Daraufhin folgen die Risikoanalyse und Risikobehandlung, sowie die Validierung und Verifikation. Die Risikoanalyse stützt sich hierbei auf 2 Schritte: der Vorevaluation der Relevanz der Fahrzeugfunktionen und der Analyse der Security-Risiken der relevanten Funktionen. Hierbei gibt es bei der detaillierten Risikoanalyse viele Ansätze, welche auf unterschiedlichen, mehr oder weniger sinnvollen Abstraktionslevel agieren. Die Risikobehandlung ist meist weniger stringent, sondern erfolgt auf Basis der Erfahrungen der Ingenieure. Im letzten Schritt erfolgen die Validierung und Verifikation des fertigen Systems. Hierbei werden häufig Funktions- und Penetrationstests verwendet. Wie bei allen Ansätzen zum Testen von Software gibt es hier Grenzen. So kann nur die Existenz von Fehlern oder Sicherheitslücken, nicht aber die Abwesenheit gezeigt werden. In sicherheitskritischen Systemen ist dieses Vorgehen fraglich. Zahlreiche Beispiele aus der (Trivial-)Literatur zeigen, dass es hier durchaus noch Handlungsbedarf gibt.