Spätestens mit der Ausgabe der neuen Edition 2 der ISO 26262 wird es eine Verbindung der Safety und Security geben. Die neue Norm verlangt laut FDIS, dass im Safety Case ebenso ein Statement zur Security des Systems, der Komponente oder des Items gegeben wird. Damit wird eine unheilvolle Verbindung geschaffen: die Safety nimmt über die Zeit in den meisten Fällen zu, da für bestehende Systeme dann in seltenen Fällen sogar eine Proven-in-use Argumentation verwendet werden kann. Ein unverändertes System würde somit mit der Zeit quasi immer safer. Mit der Security verhält es sich genau anders herum: je länger ein (unverändertes) System verwendet wird, desto länger haben Cracker die Möglichkeit, die Schwachstellen des Systems mit immer neuer Technologie auszuloten. Ein Beispiel bietet der Meltdown-Fall, in dem eine Jahrzehnte-alte Architektur plötzlich anfällig wurde.

Die Frage, was in einem solchen Fall aus dem Safety Case nach ISO26262 Ed.2 des Systems ist, ob er unwirksam wird und somit zu Rückrufen bzw. Nachbesserungen führen wird, ist noch nicht geklärt.

Ob die Safety immer beeinträchtigt ist, auch wenn die Security des Systems beeinträchtigt wurde, diese Frage muss sicherlich im Einzelfall gelöst werden.

Generell sollten beide Anforderungssätze (Safety wie Security) bereits in der Architektur eines Systems abgeleitet und angewendet werden. Während häufig die Security die Abschottung nach außen bedeutet, kümmert sich die Safety um die Absicherung innerhalb der Systemgrenzen im Inneren. Somit kann es immer wieder zu Konflikten zwischen der Safety und der Security kommen.

Auf Datenebene versucht die Safety bspw. durch CRC durch geeignete Polynome einen maximale „Hamming“- Distanz zwischen zwei eindeutig zu unterscheidenden Werten herzustellen; dies reduziert den Datenraum und macht es Crackern einfacher, insbesondere wenn die Systematik verstanden wird.

Abseits des Detaillierungsgrades des Designs und der Implementierung sollte am generellen Ansatz geprüft werden, inwiefern entsprechende Anforderungen sich wiedersprechen. Dabei können grundsätzliche Fragen weiterhelfen:

• Muss das System dauerhaft für (Funk)datenverbindungen offen sein? Welche Safety- und Security relevante Umfänge müssen enthalten sein?
• Muss die Safety Funktion mit höchster Integritätseinstufung Schnittstellen nach außen besitzen? Oder kann sie ohne große Funktionsverluste als geschlossenes System konzipiert werden?