Ein Fundament für Safety und Security: das Steuergerät einmal bauen.

1. Drei Normen, ein Produkt

Betreten Sie die meisten Tier-1-Programme, und Sie finden drei Teams, die glauben, drei Projekte zu betreiben. Das Safety-Team verantwortet ISO 26262. Das Security-Team verantwortet ISO/SAE 21434. Das Prozessteam verantwortet Automotive SPICE. Jedes hat seinen eigenen Plan, seine eigene Ordnerstruktur, seinen eigenen Reviewer und häufig seine eigene Kopie der Anforderungen. Wir haben aufgehört, die Kick-offs zu zählen, bei denen diese drei Gruppen einander zum ersten Mal vorgestellt wurden – am selben Steuergerät, mehrere Sprints später.

Das ist ein Kategorienfehler. Es gibt nicht drei Projekte. Es gibt ein elektronisches Steuergerät, einmal entworfen, einmal codiert, einmal integriert und einmal ausgeliefert. ISO 26262 ist eine Sichtweise, die auf dieses eine Produkt blickt und fragt: „Wie versagt es, und ist das verbleibende Risiko tolerierbar?“ ISO/SAE 21434 ist eine Sichtweise, die auf dasselbe Produkt blickt und fragt: „Wer greift es an, und ist das verbleibende Risiko tolerierbar?“ Automotive SPICE ist gar keine dritte Sichtweise – es ist die Disziplin, die jene Artefakte hervorbringt, auf die beide Sichtweisen zeigen. Safety und Security sind Analysen; ASPICE ist die Substanz, die analysiert wird.

Bringt man diese Beziehung durcheinander, ist alles Nachgelagerte auf Sand gebaut. Sie können eine wunderschöne Gefährdungsanalyse und Risikobewertung (HARA) schreiben – doch wenn sie sich auf eine Item-Definition und eine Architektur bezieht, die das Softwareteam nie tatsächlich gepflegt hat, ist sie ein Dokument über ein Steuergerät, das nicht existiert. Die These dieses Artikels ist unverblümt und nach unserer Erfahrung nicht verhandelbar: Sie können keine belastbare funktionale Sicherheit und keine belastbare Cybersecurity betreiben, ohne solide ASPICE-Arbeitsprodukte darunter. Nicht „es hilft“. Pflicht.

2. ASPICE-Arbeitsprodukte sind das Substrat

Streift man das Reifegrad-Theater ab, ist Automotive SPICE im Kern eine Spezifikation von Arbeitsprodukten und der Konsistenzbeziehungen zwischen ihnen. Genau diese Arbeitsprodukte sind das, was Safety und Security brauchen, um ihre Arbeit zu tun.

• SYS.2 / SWE.1 – Anforderungen. System- und Softwareanforderungen, strukturiert, atomar, verifizierbar, mit Status. Das ist der Korpus, auf den ein Sicherheitsziel oder ein Cybersecurity-Ziel heruntergebrochen wird. Ohne saubere Anforderungsbasis keine verteidigbare Ableitung von Safety- oder Security-Anforderungen.
• SYS.3 / SWE.2 – Architektur. Der System- und Software-Architekturentwurf – Komponenten, Schnittstellen, dynamisches Verhalten, Ressourcenbudgets. Eine HARA muss die Item-Grenze kennen; eine TARA muss die Angriffsfläche kennen. Beide lesen sie aus der Architektur ab.
• SWE.3 – Detailentwurf. Entwurf auf Unit-Ebene, der Aussagen zu Rückwirkungsfreiheit (Freedom from Interference) und Security-Partitionierung tatsächlich prüfbar macht, statt sie nur anzustreben.
• SWE.4–SWE.6 – Verifikation & Integration. Software-Unit-Verifikation, Softwareintegration und Integrationstest sowie Software-Qualifizierungstest. Hier hören Aussagen wie „der Sicherheitsmechanismus reagiert innerhalb des FTTI“ und „SecurityAccess weist einen ungültigen Schlüssel ab“ auf, Behauptungen zu sein, und werden zu Nachweisen.
• MAN.3, SUP.8, SUP.9, SUP.10 – das Bindegewebe. Projektmanagement, Konfigurationsmanagement, Problemlösungsmanagement und Änderungsmanagement, dazu die bidirektionale Nachverfolgbarkeit, die die Engineering-Prozesse einfordern. Das ist der Teil, den Teams überspringen, und der Teil, der entscheidet, ob Ihre Nachweise ein Assessment überstehen.

Beachten Sie: Keines der obigen Elemente ist ein Safety-Artefakt oder ein Security-Artefakt. Es sind Prozessartefakte. Und doch werden ein Funktionales Sicherheitskonzept (FSC), ein Technisches Sicherheitskonzept (TSC) und eine FMEDA allesamt aus diesen Arbeitsprodukten abgeleitet und auf sie zurückverfolgt – und ebenso die Cybersecurity-Ziele, die Cybersecurity-Anforderungen und die Verifikation, die sie schließt. Die ASPICE-Arbeitsprodukte sind der gemeinsame Boden. Alles andere steht auf ihnen.

3. Die verpflichtende Abhängigkeit, ganz konkret

Es ist leicht, zu „ASPICE ist das Fundament“ zu nicken und trotzdem Silos zu bauen. Machen wir die Abhängigkeit also greifbar.

Eine HARA (ISO 26262-3) kann ohne zwei Eingangsgrößen nicht beginnen: eine Item-Definition und mindestens eine grobe Architektur. Sie zählen Betriebssituationen und gefährliche Ereignisse auf, klassifizieren Schwere (Severity), Häufigkeit der Exposition (Exposure) und Beherrschbarkeit (Controllability), weisen ein ASIL zu und formulieren Sicherheitsziele, jedes mit einem sicheren Zustand und, sofern relevant, einem Fault Tolerant Time Interval (FTTI). Jeder einzelne dieser Schritte setzt voraus, dass Sie wissen, was das Item ist und was sich innerhalb seiner Grenze befindet. Dieses Wissen steckt in der ASPICE-Item-Definition und der SYS.3-Architektur. Wenn die Architektur auf dem Papier nicht die Architektur im Repository ist, sind Ihre S/E/C-Einstufungen als Analyse verkleidete Vermutungen.

Eine TARA (ISO/SAE 21434, Abschnitt 15) lebt noch offensichtlicher parasitär von der Architektur. Der allererste Schritt besteht darin, Assets und ihre Cybersecurity-Eigenschaften zu identifizieren – Sie können kein Asset identifizieren, das Sie nicht modelliert haben. Anschließend leiten Sie Bedrohungsszenarien ab, bewerten die Auswirkung über die Kategorien Safety, finanziell, operativ und Privatsphäre, schätzen die Angriffsdurchführbarkeit (Attack Feasibility) ein, bestimmen das Risiko und entscheiden über die Behandlung, die zu Cybersecurity-Zielen und -Anforderungen wird. Schadensszenarien werden gegen Assets definiert; Angriffspfade werden durch Schnittstellen und Vertrauensgrenzen verfolgt. Assets, Schnittstellen, Vertrauensgrenzen – all dies wird unmittelbar aus der SYS.3/SWE.2-Architektur und den Schnittstellenbeschreibungen abgelesen.

Die Schlussfolgerung ist unbequem, aber unausweichlich: Müll hinein, Dekoration hinaus. Ist die Architektur nicht real, vollständig und nachverfolgbar, sind sowohl die HARA als auch die TARA Theater. Wir sehen regelmäßig TARAs, deren Asset-Liste nicht zur Komponentenliste in der Architektur passt, und HARAs, deren Item-Grenze eine Schnittstelle ausschließt, die die Software offensichtlich nutzt. In rund 60–70 % der Erst-Assessments, die wir durchführen, ist die mit Abstand größte Ursache für schwache Safety- und schwache Security-Arbeitsprodukte derselbe Mangel – eine Anforderungs- und Architekturbasis, die von Anfang an nie solide war. Bessern Sie das Substrat aus, und beide Analysen verbessern sich auf einen Schlag. Das ist kein Zufall; das ist der ganze Punkt.

4. Wo Safety und Security Artefakte teilen – und wo sie legitim auseinanderlaufen

Weil beide Disziplinen dasselbe Substrat analysieren, teilen sie weit mehr, als die meisten Organisationen nutzen. Die gemeinsamen Artefakte sind kein nettes Extra; sie als gemeinsam zu behandeln ist genau das, was die Nachweise miteinander in Einklang bringt.

• Item- / Asset-Definition. Das, was Safety das „Item“ nennt und Security die Menge der „Assets“, sind zwei Sichten auf eine Grenze. Pflegen Sie eine Grenze, zwei Annotationen.
• Architektur (SYS.3 / SWE.2). Ein Architekturmodell trägt Safety-Attribute (ASIL-Zuweisung, Rückwirkungsfreiheit) und Security-Attribute (Vertrauensgrenzen, Krypto-Platzierung, HSM-Nutzung) als Eigenschaften an denselben Elementen.
• Verifikation & Integration (SWE.4–SWE.6). Sicherheitsmechanismen und Security-Maßnahmen werden beide über dieselbe Testinfrastruktur und dieselben Integrationsstufen verifiziert. Eine Fehlerinjektionskampagne und eine Penetrationstestkampagne laufen gegen denselben integrierten Build.
• Konfigurations- & Änderungsmanagement (SUP.8 / SUP.10). Eine Konfigurationsbasis, ein Änderungsprozess. Ein Änderungsdatensatz trägt sowohl eine Safety-Impact- als auch eine Security-Impact-Bewertung.
• Problemlösung (SUP.9). Eine Fehlerdatenbank, in der jeder Befund als safety-relevant, security-relevant, beides oder keines von beidem gekennzeichnet werden kann.

Sie laufen jedoch legitim auseinander – und so zu tun, als sei dem nicht so, ist ein eigener Fehlermodus. Die Unterschiede liegen in der Natur des Bedrohungsmodells, nicht im Substrat:

• Zufälliges/systematisches Versagen vs. intelligenter Angreifer. Safety argumentiert über Fehler, die mit einer Wahrscheinlichkeit auftreten; Security argumentiert über einen Angreifer, der gezielt den ungünstigsten Fall sucht. Einem motivierten Angreifer lässt sich keine Expositionswahrscheinlichkeit zuweisen.
• FTTI vs. Angriffsdurchführbarkeit. Safety begrenzt Zeit – das Fault Tolerant Time Interval. Security begrenzt Aufwand – Bewertungen der Angriffsdurchführbarkeit (etwa nach Attack-Potential, CVSS-basierten oder Attack-Vector-basierten Methoden gemäß ISO/SAE 21434 Anhang G). Andere Achsen, anders berechnet.
• Sicherer Zustand vs. sicherer (geschützter) Zustand. Ein sicherer Zustand (safe state) kann „Limp Home“ oder „kontrolliertes Abschalten“ sein; ein geschützter Zustand (secure state) kann „Nachricht verwerfen, protokollieren und fortfahren“ sein. Gelegentlich kollidieren diese – die sicherste Reaktion öffnet einen Angriff auf die Verfügbarkeit, oder die am besten geschützte Reaktion degradiert eine Sicherheitsfunktion – und genau diesen Konflikt aufzulösen ist die Co-Analyse, die Silos unmöglich machen.

5. Die Kosten der Silos

Baut man die drei isoliert, sind die Kosten vorhersehbar, denn wir haben sie bei Rettungseinsätzen mehr als einmal bezahlt.

Doppelte und widersprüchliche Anforderungen. Das Safety-Team schreibt eine Anforderung zur Nachrichtenintegrität für die Fehlererkennung; das Security-Team schreibt eine nahezu identische zur Authentizität; keines weiß vom anderen. Sechs Monate später berührt eine Änderung die eine und nicht die andere, und nun widerspricht sich Ihre eigene Anforderungsbasis selbst. Wir haben einzelne Steuergeräte gesehen, die 15–25 % redundante Anforderungen tragen, rein aus paralleler, unkoordinierter Erstellung.

Zwei Nachverfolgbarkeitsbäume, die nie zusammenpassen. Safety verfolgt Ziele → FSC → TSC → Anforderungen → Tests. Security verfolgt Ziele → Anforderungen → Maßnahmen → Tests. Hängen beide Bäume an getrennten Kopien der Architektur, lassen sie sich überhaupt nicht in Einklang bringen – und genau das finden die Prüfungen der bidirektionalen Nachverfolgbarkeit und der Konsistenz, die ein Assessor durchführt.

Stilles disziplinübergreifendes Brechen. Das ist das teure Phänomen. Eine Security-Maßnahme fügt im Kommunikationsstack einen Schritt zur Nachrichtenauthentifizierung hinzu; niemand prüft das Safety-Timing erneut, und die zusätzliche Latenz frisst nun das FTTI-Budget an. Oder eine Safety-Änderung verlagert eine Funktion auf einen anderen Core und verschiebt sie still über eine Vertrauensgrenze, die die TARA als intakt angenommen hatte. Bei getrennten Änderungsprozessen wird kein Team auch nur benachrichtigt.

Befunde zur Konsistenz. Assessoren und Auditoren prüfen nicht nur, ob jedes Artefakt existiert; sie prüfen, ob die Artefakte übereinstimmen. Inkonsistenz zwischen der Safety-Sicht, der Security-Sicht und den Engineering-Arbeitsprodukten gehört zu den häufigsten und schädlichsten Befunden, weil sie sich nicht schließen lässt, indem man ein weiteres Dokument schreibt – sie erfordert das erneute Herstellen der gemeinsamen Basis, die Sie von Anfang an hätten haben sollen. Nach unserer Erfahrung dominieren Befunde der Konsistenzklasse den Nacharbeitsaufwand bei Silo-Programmen weit mehr als jede einzelne fehlende Analyse.

6. Der integrierte Lebenszyklus – ein V-Modell, drei Sichtweisen

Die Alternative ist nicht heroisch. Sie besteht schlicht darin, das Steuergerät als ein einheitliches Ganzes zu bauen und jede Disziplin zu einer Sichtweise auf gemeinsame Artefakte werden zu lassen.

Es gibt ein V-Modell. Die Anforderungsermittlung erzeugt einen Anforderungssatz, in dem jede Anforderung als safety-relevant, security-relevant, beides oder keines gekennzeichnet sein kann. Die Architektur ist ein Modell, dessen Elemente ASIL-Zuweisungen und Vertrauensgrenzen-Annotationen nebeneinander tragen. Die Verifikation ist eine Kampagne, in der Fehlerinjektion (zum Nachweis der Sicherheitsmechanismen) und Penetrationstests (zum Nachweis der Security-Maßnahmen) gegen dieselben integrierten Builds laufen und eine Problemlösungsdatenbank speisen.

Auf diesem einen Rückgrat führen Sie die Co-Analyse durch. ISO/SAE 21434 nimmt das Zusammenspiel von Safety und Security ausdrücklich vorweg, und ISO 26262 erwartet, dass Sie es berücksichtigen. Der kanonische Fall ist ein Security-Angriff, der eine Safety-Gefährdung verursacht – gefälschte Sensordaten, die einen Aktor in einen unsicheren Zustand treiben, oder ein Denial-of-Service, das einer Sicherheitsfunktion ihre Eingaben entzieht. Diese Wechselwirkung können Sie nur sehen, wenn das Bedrohungsszenario aus der TARA und das gefährliche Ereignis aus der HARA dasselbe Architekturelement betrachten. In einer Co-Analyse gehen wir jeden Angriffspfad durch und fragen: „Endet dieser in einem gefährlichen Ereignis?“ und jedes gefährliche Ereignis und fragen: „Kann ein Angreifer dies absichtlich auslösen?“ Dieses Gespräch ist über zwei voneinander getrennte Werkzeugketten hinweg strukturell unmöglich.

Und es gibt eine gemeinsame Änderungssteuerung. Ein einziger Änderungsantrag, einmal unter SUP.10 erhoben, trägt eine verpflichtende Safety-Impact- und Security-Impact-Bewertung, bevor er genehmigt werden kann. Wenn sich die Architektur bewegt, werden die Safety-Analyse, die Security-Analyse und die Prozessnachweise in derselben Transaktion zur erneuten Bewertung markiert – statt sechs Wochen später in einem Audit als veraltet entdeckt zu werden.

7. Wie wir das aufsetzen

Unsere Praxis fußt auf der Überzeugung aus Abschnitt 1: ein Produkt, ein Rückgrat, drei Sichtweisen. Wir betreiben kein Safety-Projekt, kein Security-Projekt und kein Prozessprojekt; wir betreiben ein Engineering-Programm, in dem die ASPICE-Arbeitsprodukte die einzige Quelle der Wahrheit sind und die Aktivitäten nach ISO 26262 und ISO/SAE 21434 disziplinierte Sichten darauf darstellen.

Konkret bedeutet das eine Anforderungs- und Architekturbasis unter ordnungsgemäßem Konfigurations- und Änderungsmanagement, bei der Safety- und Security-Attribute als gleichrangige Eigenschaften an den gemeinsamen Elementen getragen werden, statt in parallelen Dokumenten gepflegt zu werden. Es bedeutet Nachverfolgbarkeit, die für beide Disziplinen den Kreis vom Ziel bis zur Verifikation über dieselben Arbeitsprodukte schließt, sodass ein Assessor einem einzigen Faden folgen kann, statt zu versuchen, zwei in Einklang zu bringen. Und es bedeutet einen Änderungsprozess, bei dem eine einzelne Modifikation Safety-, Security- und Prozessnachweise gemeinsam aktualisiert, sodass die drei nie auseinanderdriften.

Wir führen das über unsere Arbeit im Software-Engineering zusammen – dort, wo das ASPICE-Rückgrat tatsächlich gebaut und gepflegt wird –, über unsere Praxis für funktionale Sicherheit für die ISO-26262-Sichtweise und über unsere Praxis für Cybersecurity für die ISO/SAE-21434-Sichtweise, einschließlich praxisnaher ECU-Penetrationstests, die Security-Maßnahmen gegen dieselben integrierten Builds verifizieren, die auch die Safety-Kampagne nutzt. Wo Teams diese Arbeitsweise verinnerlichen wollen, statt sie auszulagern, sorgt unser Angebot für Training und Consulting dafür, dass das Modell des „einen Fundaments“ zum Standard wird statt zur Ausnahme. Die wiederkehrende Lehre aus jedem Rettungseinsatz, den wir durchgeführt haben, ist dieselbe: Die Organisationen, die ASPICE als das Substrat behandeln, stecken ihren Aufwand in das Engineering des Produkts, und jene, die es als ein separat abzuhakendes Kästchen behandeln, stecken ihren Aufwand in das Inkonsistent-Halten von Nachweisen, die nie hätten auseinanderlaufen dürfen.

---

Möchten Sie einen 30-minütigen Walkthrough zu Ihrem Projekt?

Keine NDA nötig. Sagen Sie uns die Norm, das Item bzw. Asset, den Assessor und Ihre Deadline. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, abgebildet auf die obigen Punkte — Ihre, ob Sie uns beauftragen oder nicht.

Walkthrough buchen →

---

Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-06-05.