ISO 26262 × ISO/SAE 21434 × CRA
Die meisten Ratschläge zu diesem Thema lauten, Safety und Security sollten zusammenarbeiten. Das stimmt – und ist nicht das Problem. Das Problem ist, dass beide Unterschiedliches wollen und jemand entscheiden muss, wenn sie sich widersprechen.
Safety will Vorhersagbarkeit, Verfügbarkeit und Prüfbarkeit. Security will minimale Rechte, Undurchsichtigkeit und dichte Schnittstellen. Beide haben recht. In den meisten Organisationen wird der Konflikt spät, informell und von demjenigen entschieden, der am lautesten eskaliert – und die Entscheidung landet nirgendwo, wo ein Auditor sie finden könnte.
Im Entwurf
Wo beide gegeneinander ziehen
Der Diagnosezugang, den ein Safety-Ingenieur braucht, ist eine Angriffsfläche. Secure Boot kostet Latenz, die vom Fault Tolerant Time Interval abgeht. Kryptographie im Signalpfad bringt Jitter in etwas, das als deterministisch spezifiziert war. Ein Watchdog, der bei Anomalien zurücksetzt, ist für die eine Disziplin Verfügbarkeit und für die andere ein Denial-of-Service-Vektor.
Nichts davon ist ein Missverständnis zwischen Abteilungen, und keine Prozessangleichung löst es auf. Es sind Engineering-Abwägungen mit realen Kosten auf beiden Seiten – billig zu klären zum Zeitpunkt der Architektur und ruinös nach der Integration. Unsere Aufgabe ist es, sie sichtbar zu machen, solange sie billig sind, beide Seiten zu beziffern und dafür zu sorgen, dass Entscheidung und Begründung an einem dauerhaften Ort landen.
Gemeinsame Analyse
Über einen Angreifer kann man nicht mitteln
Der ASIL ergibt sich aus Severity, Exposure und Controllability und unterstellt Fehler, die sich statistisch verhalten. Attack Feasibility unterstellt einen intelligenten Gegner, der den ungünstigsten Fall wählt und sich an jede Gegenmaßnahme anpasst. Die beiden Zahlen liegen nicht auf derselben Skala – und ein gemeinsames Risikoregister, das so tut, sieht nach guter Integration aus und verdeckt dabei genau die Punkte, die eine menschliche Entscheidung bräuchten.
Was funktioniert: die Analysen gemeinsam am selben Item durchführen, mit beiden Disziplinen im Raum, und die beiden Skalen dabei getrennt halten. Etablierte Methoden wie SAHARA verbinden die automotive HARA mit STRIDE genau zu diesem Zweck. Wir moderieren die Sitzung, halten beide Seiten dazu an, ehrlich zu sagen, was ihre Zahlen bedeuten, und erzeugen ein Ergebnis, in dem sich ein Safety-Assessor und ein Cybersecurity-Auditor jeweils wiederfinden.
Gemeinsame HARA und TARA
Moderierte Sitzungen an einer Item-Definition – mit einem Gefährdungsbild und einem Bedrohungsbild, die aufeinander verweisen, statt sich ein halbes Jahr später zu widersprechen.
Ein Verantwortlicher für die Schnittstelle
Wer entscheidet, wenn eine Security-Maßnahme eine Safety-Eigenschaft verschlechtert. Namentlich benannt, mit Eskalationspfad – vor dem ersten Konflikt, nicht mittendrin.
Zwei Cases, eine Argumentation
Ein Safety Case und ein Cybersecurity Case, die dieselben Annahmen teilen, statt sie unterschiedlich zu formulieren – denn den Widerspruch dazwischen findet ein Reviewer zuerst.
Der Teil, für den niemand plant
Safety friert zum SOP ein. Security nie.
Ein Safety Case wird zum Start of Production geschlossen. Die Argumentation steht, ist unterschrieben, und die Menschen, die sie gebaut haben, gehen ins nächste Programm. Security schließt nie: R155 erwartet Monitoring über die Fahrzeuglebensdauer, R156 macht Updates zur Routine, und der Cyber Resilience Act legt Meldepflichten obendrauf.
Open Source macht daraus ein terminiertes Ereignis statt einer theoretischen Spannung. Eine sicherheitsrelevante Funktion sitzt auf einem Stack mit Komponenten, die Sie nicht geschrieben haben und nicht kontrollieren – jede mit einem eigenen Strom von Schwachstellen, der nach eigenem Zeitplan eintrifft. Im sechsten Jahr landet ein CVE in einer Bibliothek unterhalb einer Sicherheitsfunktion, veröffentlicht von jemandem, der Ihre Item-Definition nie gesehen hat.
Dann kollidieren die Uhren. Der CRA gibt Ihnen vierundzwanzig Stunden für eine Frühwarnung bei einer aktiv ausgenutzten Schwachstelle und zweiundsiebzig Stunden für die Meldung. Eine Safety-Impact-Analyse läuft nicht auf einer 24-Stunden-Uhr. Ein Confirmation Review auch nicht. Also muss jemand unter regulatorischer Frist beurteilen, ob ein Patch sicher ist – gegen eine Argumentation, die Jahre zuvor von Menschen geschrieben wurde, die nicht mehr da sind.
Und es gibt eine Voraussetzung, die fast niemand geschaffen hat: Sie können die Safety-Auswirkung einer Schwachstelle nicht beurteilen, wenn Sie nicht sagen können, was im Build war. Damit wird die SBOM-Praxis zu einem Safety-Thema und nicht zu einer Lizenz-Fleißaufgabe – und deshalb behandeln wir Open-Source-Compliance als Teil dieser Arbeit und nicht als getrennte Disziplin.
Die Arbeit besteht darin, den Entscheidungspfad zu entwerfen, bevor die Uhr läuft: Was löst eine Safety-Impact-Analyse aus, wer darf sie beurteilen, welche Nachweise aus dem ursprünglichen Programm müssen dafür überhaupt noch vorhanden sein, und welche Teile des Safety Case wurden so geschrieben, dass sie eine Änderung überstehen – und welche nicht. Das ist unspektakulär, im Voraus billig, und es entscheidet darüber, ob eine Veröffentlichung eine schlechte Woche oder ein Rückruf wird.
Jede Seite für sich: Funktionale Sicherheit → · Automotive Cybersecurity →