Die TARA ist (nicht) traceable? Eine kritische Bestandsaufnahme von der Item Definition bis zum ALM

Zunächst soll der Begriff der „Traceability“, der im Deutschen mit „Rückverfolgbarkeit“ und „Nachvollziehbarkeit“ übersetzt wird, konkretisiert werden. Dabei geht es im Wesentlichen darum, dass eine lückenlose Nachverfolgbarkeit gewährleistet ist. (Was in der vielschichtigen Automobilbranche seit Jahrzehnten eine immense Herausforderung für unzählige Bereiche darstellt.) Im Kontext der Cybersicherheitsanforderungen (dazu später mit Blick auf die Cyersecurity Claims und die Cybersecurity Goals noch eine Vertiefung) muss sichergestellt sein, dass jederzeit nachvollziehbar ist, wie diese aus Assets, Threats und Risiken abgeleitet wurden, und wie sie konkretisiert, implementiert, verifiziert/validiert und bei Bedarf gegebenenfalls angepasst wurden.

Was Traceability im Kontext TARA gemäß ISO/SAE 21434 wirklich bedeutet

Praktisch lässt sich diese durchgängige Kette entlang der TARA-Methodik stets überprüfen, in dem man sich zugehörige Fragen und viel mehr ihre Antworten darauf im jeweiligen Entwicklungskontext genau vor Augen führt. Das könnten unter anderem sein:

• Warum existiert diese Sicherheitsanforderung?
• Welches Risiko/Threat adressiert sie?
• Wo ist sie im System/Design umgesetzt?
• Wie wurde sie geprüft (Test, Review, Analyse)?
• Welche Änderungen betreffen sie potenziell (Impact Analysis)?

Wichtig ist: Traceability ist mehr als ein Netz aus Hyperlinks. Sie ist die Fähigkeit, jeden sicherheitsrelevanten Sachverhalt vorwärts und rückwärts zu verfolgen, versioniert zu belegen und bei Änderungen zuverlässig zu aktualisieren.

Aus Funktionen, Betriebszuständen und Schnittstellen der Item Definition (der Systembeschreibung) entstehen Assets; darauf aufbauend werden Threats und Angriffspfade modelliert, aus denen Risiken hervorgehen; diese Risiken treiben Cybersecurity Goals und Claims, die sich in Testfällen, respektive in überprüfbaren Anforderungen materialisieren; Anforderungen werden in Architekturentscheidungen umgesetzt und durch Tests mit belastbarer Evidenz belegt.

Erst wenn diese Kette semantisch sauber, zeitlich gültig und organisatorisch verankert ist, entfaltet TARA ihre Wirkung – und bleibt nicht bloß ein wohlgeordnetes Dokument.

Die drei Säulen der Traceability in der TARA: Zweck statt Häkchenlogik

An dieser Stelle sei in Kürze ein etwas genauerer Blick auf die drei ineinandergreifenden Prinzipien der Traceability eingeschoben, die zusammen die Wirkung der TARA absichern:

1. Coverage im Sinne einer lückenlosen Abbildung der Item Definition: Jede Funktion, jeder Betriebszustand und jede Schnittstelle muss in der Risiko-Analyse auftauchen. Nicht analysierte Elemente sind blinde Flecken, die später teuer werden – in Form von nachträglichen Maßnahmen, unklaren Verantwortlichkeiten und vermeidbaren Angriffsflächen. Coverage ist damit keine kosmetische Zahl, sondern die Verlässlichkeit, dass das Bild der Systemrealität vollständig ist.

2. Reverse Coverage – die Abdeckung „nach oben“. Dieses aus der funktionalen Sicherheit bekannte Prinzip besagt, dass nichts umgesetzt wird, wofür es keine Anforderung gibt. Übertragen auf Cybersecurity heißt das: Keine Sicherheitsziele (Cybersecurity Goals) und keine Maßnahmen (Controls) ohne nachvollziehbare Herleitung aus einem identifizierten Risiko oder einer konkreten Anforderung. Wer diese Disziplin lebt, verhindert „Security‑Theater“ – Maßnahmen, die gut aussehen, aber keinen belegbaren Beitrag zur Risikoreduktion leisten und die Komplexität des Systems unnötig erhöhen oder gar neue Angriffsvektoren darstellen. (Dies gilt natürlich auch andersherum, dass auch wiederum alle Risiken vollständig eine Zuordnung erhalten.)

3. Qualität der Impact‑Analyse: Änderungen in der Ausgangssituation – etwa eine neue Hardwarekomponente, ein geänderter Bus oder ein aktualisiertes Protokoll – müssen automatisiert sichtbar machen, welche Ziele, Anforderungen, Architekturanker und Testfälle dadurch vorläufig ungültig werden und gegebenenfalls angepasst werden müssen, weil sich die Risikobewertung verschiebt. Konsistente und durchgängige Traceability ermöglicht möglicht dann, vom geänderten Element entlang der gesamten Kette bis zur TARA zu propagieren und dabei ausschließlich die tatsächlich betroffenen Damage Scenarios und Attack Vectors gezielt zu aktualisieren. In modernen Entwicklungsumgebungen markieren sogenannte „suspect links“ genau diese Stellen: Artefakte, die nach einer Änderung erneut validiert werden müssen. Ohne diese disziplinierte Rückkopplung verliert die Organisation Tempo und Sicherheit zugleich, weil Entscheidungen auf veralteten Annahmen basieren.

Die Implementierungslücke der Traceability der TARA gemäß ISO/SAE 21434

Die ISO/SAE 21434 definiert präzise, was in der Erarbeitung der Cybersecurity in der Automobilentwicklung erforderlich wird. Was die Norm jedoch offen lässt: das „wie“. Also wie die konkrete Ausgestaltung der Datenflüsse zwischen den einzelnen Arbeitsergebnissen auszusehen hat.

Diese Lücke ist bewusst gewählt, da die Anforderung der Rückverfolgbarkeit (Traceability) bereits in Automotive SPICE verankert ist und normativ unterschiedliche Vorgehensweisen und Implementierungen zulassen soll.

Für Automobilhersteller und -zulieferer entstehen dadurch zentrale Umsetzungsfragen, wenn es um die gesamtheitliche Verzahnung der TARA-Methodik geht:

• Wie werden die Ergebnisse der Item Definition systematisch in die TARA überführt?
• Wie ist bei der Erarbeitung der TARA an sich ausreichend Nachvollziehbarkeit, Rückverfolgbarkeit und Transparenz gewährleistet?
• Wie gelangen TARA-Ergebnisse (Cybersecurity-Ziele und Maßnahmen) strukturiert in das ALM-Tool für Requirements Engineering und Testmanagement?
• Wie lassen sich Vollständigkeit, Konsistenz und Präzision der Daten über alle Ebenen hinweg sicherstellen – insbesondere bei Änderungen durch funktionale Updates oder neu identifizierte Angriffsvektoren?

In der Praxis arbeiten viele Entwicklungsteams in getrennten Informationssilos: Item Definition, TARA und Anforderungsmanagement existieren als separate, nicht integrierte Arbeitsergebnisse.

Diese Fragmentierung ist bei einfachen Systemen noch beherrschbar. Sobald jedoch die Systemkomplexität steigt oder substanzielle Änderungen auftreten, versagt die manuelle Synchronisation zwischen den Silos.

(Von der Problematik der TARA-Arbeit über die Organisationsgrenze hinaus noch ganz abgesehen, s. dazu der aktuelle Beitrag zur Vertikalen TARA-Integration.)

Es ist wichtig, sich Folgendes klar zu machen: Eine bruchstückhafte, inkonsistente und isolierte Arbeitsweise, bei der Informationen entlang der Kette verloren gehen, Zusammenhänge nicht konsistent fortgeschrieben werden und Widersprüche zwischen Artefakten entstehen, widerspricht dem Grundprinzip der ISO/SAE 21434 fundamental. Denn die TARA ist dort explizit als „living document“ konzipiert, das fortlaufend und dynamisch mit neuen Inputs/Outputs umgehen kann. Sie muss kontinuierlich den aktuellen Wissensstand über das System und seine Sicherheitsrisiken abbilden – einschließlich neu entdeckter Schwachstellen sowie funktionaler und architektonischer Systemänderungen.

Doch wie soll das in der Praxis funktionieren, wenn die Traceability nicht im dafür erforderlichen Maße gewährleistet ist?

Wo die Theorie auf die Praxis trifft: Typische Bruchstellen der Traceybility

Klar ist also, dass Traceability mit der TARA durchgängig gewährleistet werden muss, daher lohnt ein Blick in die praktischen Fallstricke und deren Konsequenzen dabei – über den gesamten Entwicklungszyklus hinweg.

In der täglichen Praxis beobachten wir immer wieder typische Schwachstellen:

• Ziele bleiben zu generisch und veralten: Cybersecurity-Ziele werden so allgemein formuliert, dass deren Erreichung kaum überprüfbar ist. Konkrete Prüfkriterien fehlen. Was häufig passiert: Die an die Ziele gebundenen Anforderungen werden zwar überprüft umgesetzt. Ob damit die Ziele aber effektiv auch erreicht wurden, bleibt jedoch unklar, wenn die Risikobewertung nicht um die Sicherheitsmaßnahmen aktualisiert wird.
• Maßnahmen ohne Anforderungen: Best-Practice-Kataloge und organisationsspezifische Auswahlmöglichkeiten liefern Sicherheitsmaßnahmen, die direkt in die Architektur wandern – ohne den Umweg über sauber formulierte und nachvollziehbare Anforderungen.
• Anforderungen und Testfälle ohne harte Verknüpfung: Verweise erfolgen per Freitext statt über eindeutige Identitäten. Dadurch ist weder Testabdeckung noch Wirksamkeit der Maßnahmen zuverlässig bewertbar.
• Änderungen brechen die Kette: Sobald Hardware, Schnittstellen oder Software-Stacks angepasst werden (Kundenanforderungen sollen sich ja hin und wieder Mal ändern, heißt es), erfolgt die Rückführung in die Risikoanalyse zu spät oder gar nicht. Die Organisation verliert den Überblick über ihre aktuelle Risikolage im Produkt.

Es lassen sich eine Reihe von Unwegsamkeiten beobachten, durch die die oben genannten grundlegenden Defizite entstehen. Sie erstrecken sich über mehrere Dimensionen und untergraben die Qualität der gesamten TARA sowie die effektive Cybersicherheit fundamental:

• Semantische Lücken: Verknüpfungen zwischen Arbeitsergebnissen sind nicht typisiert – ob ein Link „implementiert”, „mitigiert”, „verifiziert” oder nur „beeinflusst”, bleibt oft unklar und damit analytisch minderwertig.
• Zeitliche Inkonsistenzen: Versionen und Gültigkeitszeiträume werden selten sauber geführt. Evidenz aus dem letzten Release wird fälschlich als Nachweis für den aktuellen Stand interpretiert.
• Organisatorische Silos: TARA, Anforderungs-Management, Architektur, Test und PSIRT arbeiten in getrennten Tools. Manuelle Kopplungen altern schnell und erzeugen ungültige und fehlende Verknüpfungen.
• Informationsverlust in der Lieferkette: Ziele und Anforderungen werden als Dokumente weitergegeben statt als wiederverwendbare, eindeutig adressierbare Datenobjekte – der Kontext verwässert.
• Erhöhte und teilweise unnötige Aufwände: Eine mögliche Überimplementierung von Controls bindet int der Regel Ressourcen, die dann an anderer Stelle – beispielsweise im Testing – nicht mehr in ausreichendem Umfang zur Verfügung stehen.

Traceability in der TARA verbessern: Vorschlag für eine robuste Link-Strategie zwischen TARA und ALM

Die Integration von TARA-Ergebnissen in das ALM ist letztendlich entscheidend für durchgängige Traceability und effektives Cybersecurity-Development. Moderne ALM-Plattformen ermöglichen bereits die direkte Einbettung von TARA-Aktivitäten, wodurch Cybersecurity-Risiken direkt mit Anforderungen, Sicherheitszielen und Testfällen verbunden werden können. Dabei ist zu berücksichtigen:

Goals und Claims gezielt ins ALM überführen

Nicht nur die abgeleiteten Anforderungen, sondern auch Cybersecurity Goals und Claims sollten direkt im ALM-Tool abgebildet werden. Warum? Weil sie den Kontext liefern, der für Stakeholder-Requirements und Impact-Analysen unverzichtbar ist.

Dabei gilt es zu unterscheiden:

1. Goals und Claims mit Security Controls: Für diese müssen konkrete Anforderungen im ALM abgebildet werden, die sowohl die Security Controls als auch deren Wirksamkeit in Bezug auf die referenzierte Attacke beschreiben. Eine zugehörige bidirektionale Verlinkung zu Goals/Claims ist zwingend erforderlich – nur so können Änderungen in beide Richtungen propagiert werden. Gleichzeitig kann über eine zusätzliche Verlinkung zu Kundenanforderungen, dort wo es relevant ist, nachgedacht werden. Wichtige Prüffrage: Ist durch Einführung der Security Control das Risiko wirklich akzeptabel geworden, sodass aus dem Goal ein validierter Claim werden kann? Diese Frage sollte nicht erst im Penetration Test (o.Ä.) beantwortet werden. Eine Re-Evaluierung des Risikos inklusive der implementierten Security Control in der aktualisierten TARA sollte die Antwort bereits während der Entwicklung liefern.

2. Claims ohne Security Control: Ist keine Ableitung von Anforderungen notwendig? Dann wird das Risiko als akzeptabel bewertet, ohne dass zusätzliche Maßnahmen erforderlich sind. Aber: Bei Attacken, die als sehr schwierig durchführbar bewertet wurden, ist dennoch eine Validierung durch Penetration Test erforderlich. Auch hier sollte eine entsprechende Validierungsverknüpfung im ALM-Tool vorgesehen sein. Eine allgemeine Handlungsempfehlung wäre: Alle Claims, die Controls enthalten oder deren Angriffspfad als schwierig bewertet wurde, sollten systematisch durch Penetration Tests validiert werden – dies muss im ALM nachvollziehbar sein. (Gleichzeitig sollten auch Claims ohne zugeordnete Controls validiert werden – etwa durch belastbare Nachweise bei einer Risikoteilung mit dem Kunden oder durch eine formale Managementfreigabe bei der Akzeptanz von Risiken aufgrund technischer Rahmenbedingungen – weshalb letztendlich sämtliche Claims konsistent im AML erfasst werden sollten.)

3. Risiken mit sehr niedrigem Schaden: Risiken, die aufgrund ihres vernachlässigbaren Schadens als gering bewertet wurden, erfordern keine Verlinkung ins ALM-Tool. Diese Unterscheidung spart Aufwand und überfrachtet das System nicht unnötig.

Ein Blick auf Cybersicherheit in der Lifecycle-Perspektive: Vom Goal zum Claim

Am Ende des Entwicklungsprozesses sollten alle Goals zu verifizierten und validierten Claims geworden sein.

Systemseitig sollte gelten: Die Links zu den Anforderungen und Tests bleiben dabei erhalten – auch wenn sich der Status von „Cybersecurity Goal” zu „Cybersecurity Claim” geändert hat.

Diese Kontinuität ist entscheidend: Erst sie ermöglicht es, jederzeit nachzuvollziehen, welche Anforderungen und Tests welches Sicherheitsziel adressieren und vor allem ob dieses Ziel tatsächlich erreicht wurde.

Diese durchgängige Traceability zwischen Cybersecurity-Anforderungen, Risiken, Testfällen und Design-Artefakten ist darüber hinaus essenziell für Compliance und die vielbeschriebene Assessment-Readiness. (Gerade neuere Fahrzeug-Regulierungen werden hier vermehrt reingehen, s. auch der aktuelle Beitrag zur Korea Vehicle Security Regulierung)

Funktionierende Synchronisation: Der Schlüssel zur TARA als „Living Document“

Der Kern der Herausforderung liegt darin, dass eine TARA niemals „fertig” ist. Wenngleich Cybersecurity für viele OEMs und Zulieferer anfangs vor allem als ein „Entwicklungsthema“ angesehen wurde, hat man weitläufig unterschätzt, dass Security über den gesamten Fahrzeug-Lebenszyklus verlässlich nachgewiesen und betrieben werden muss.

Mit der technischen Weiterentwicklung (mehr Software, Vernetzung, Updates) und der zugehörigen Regulatorik wird ist heute klar, dass es sich eher um ein kontinuierliches Pflichtprogramm handelt. Ohne Projektabschluss, bis der Support für ein Fahrzeug ausgelaufen ist. In diesem Zusammenhang definiert die ISO/SAE 21434 die TARA eben explizit als „living document“ und stellt den lifecycle-orientierten Ansatz in den Vordergrund.

Ganz konkret geht es dabei eben um die Dynamik der Bedrohungslandschaft. Das Cybersecurity-Umfeld verändert sich kontinuierlich, neue Sicherheitslücken werden bekannt (CVEs) und Angriffsmethoden entwickeln sich weiter. Auch die Systemarchitektur wird durch Updates, Patches oder neue Features verändert. Komponenten werden ausgetauscht oder Lieferanten wechseln. Jede dieser Änderungen können bestehende Risikobewertungen obsolet machen.

Bei Architekturänderungen:

• Die TARA muss aktualisiert werden, um die neue Angriffsfläche zu reflektieren
• Asset-Definitionen können sich ändern
• Neue Schnittstellen oder Datenflüsse entstehen
• Bestehende Threat Scenarios müssen neu bewertet werden

Bei neuen Bedrohungen im Betrieb:

• Vulnerability Monitoring liefert kontinuierlich neue Informationen
• Exploit-Verfügbarkeit kann die Risikobewertung verändern
• Field Incidents zeigen reale Angriffsvektoren auf

Die kritische Synchronisationsschleife besteht folglich darin: Wenn sich eine Risikobewertung in der TARA ändert, muss dies über die Verlinkung im ALM unmittelbar sichtbar werden.

Konkret etwa so:

1. Automatische Markierung als „suspect“: Die betroffenen Angriffspfade und damit die betroffenen Goals und Claims sowie alle direkt oder indirekt verlinkten Anforderungen und Testfälle werden als „suspect” markiert. Dies signalisiert: Achtung, hier könnte Handlungsbedarf bestehen!

2. Strukturierte Review-Prozesse: Das Entwicklungs- und Testteam müssen systematisch prüfen:

• Ist die Anforderung noch notwendig und ausreichend?
• Muss die Anforderung angepasst werden (z.B. stärkere Verschlüsselung)?
• Muss der Testfall erweitert werden?
• Werden völlig neue Anforderungen oder Testfälle benötigt?
• Können Anforderungen entfallen, weil das Risiko neu bewertet wurde?

3. Bidirektionale Rückmeldung: Änderungen an Anforderungen oder Tests müssen zurück in die TARA fließen, um Claims zu aktualisieren

Die Gefahr der TARA als „one and done“ Snapshot

Ohne automatisierte oder zumindest prozessual stark verknüpfte Synchronisation sind TARA und ALM-Inhalt keine lebenden Dokumente, sondern Snapshots, die schnell veralten. Die Konsequenzen liegen auf der Hand:

• Inkonsistenz: TARA und Anforderungen driften auseinander
• Falsche Sicherheit: Veraltete Claims suggerieren Schutz, der nicht mehr gegeben ist
• Compliance-Risiko: Bei Audits oder im Schadensfall kann die Inkonsistenz nicht erklärt werden
• Verlust der Risikoübersicht: Die Organisation verliert die Fähigkeit, ihre tatsächliche Sicherheitslage zu rekonstruieren

Gleichzeitig versuchen wir auch stets einen Blick auf die Fragen der Cybersicherheit aus Geschäfts- und Finanzperspektive zu werfen. Allzu häufig führen fehlende Traceability und somit falsche Zusammenhänge zu Kosten und Aufwand rund um Cybersicherheit (und zugehörige Implementierungen), die faktisch vermeidbar gewesen wären.

Konkrete Handlungsempfehlungen für die Synchronisation TARA & ALM

Die nachfolgenden Punkte sind erste bewährte Stellhebel, um Aktualisierungen effizient auszulösen, konsistent nachzuverfolgen und auditfähig zu dokumentieren:

• Tool-Unterstützung: Investieren Sie in ALM-Tools mit nativer TARA-Integration oder entwickeln Sie Schnittstellen für automatisierte Synchronisation
• Suspect-Link-Management: Etablieren Sie klare Workflows, wie suspect-markierte Elemente zu behandeln sind (Verantwortlichkeiten, Fristen, Eskalation)
• Change-Trigger definieren: Legen Sie fest, welche Änderungstypen eine TARA-Aktualisierung auslösen (z.B. Architekturänderungen ab einem bestimmten Schweregrad, alle CVEs mit CVSS > 7.0, die auf das System anwendbar sind)
• Versionierung: Arbeiten Sie konsequent mit Versionen und Baselines – sowohl in der TARA als auch im ALM
• Regelmäßige Konsistenzprüfungen: Führen Sie quartalsweise automatisierte Checks durch, die nach verwaisten Links, nicht aufgelösten Suspects oder fehlenden Validierungen suchen

Kurzer Exkurs: Warum decken ASPICE- und ISO/SAE-21434-Assessments das noch nicht ab?

Man könnte sich fragen: Wenn Traceability, wie dargelegt, so wichtig ist, warum fallen Unternehmen bei ASPICE- oder ISO/SAE-21434-Audits hier nicht ständig durch?

Dies liegt in der gegenwärtigen Realität klassischer Assessments: Die Antwort liegt in der Tiefe und dem Fokus der Prüfung.

Assessoren prüfen häufig noch statisch und dokumentenbasiert:

• ✓ „Gibt es eine TARA?”
  – Ja, hier ist sie.
•  
• ✓ „Sind Cybersecurity Goals definiert?”
  – Ja, siehe Kapitel 5.
•  
• ✓ „Gibt es abgeleitete Anforderungen?”
  – Ja, im ALM-Tool dokumentiert.
•  
• ✓ „Sind die Goals in den Anforderungen referenziert?”
  – Ja, per Freitext oder ID.

Was jedoch oft fehlt: Die Prüfung der dynamischen Entwicklung und Konsistenz über Tool-Grenzen und Zeit hinweg. (Auch wenn gegebenenfalls einzelne, dediziert vorbereitete Beispiele zur Traceability eventuell noch erfragt werden.) So ist es in einem typischen einwöchigen Assessment in der Regel schwierig nachzuweisen, dass:

• Ein „Suspect Link” nach einer TARA-Änderung korrekt zu einer Änderungsanforderung im ALM geführt hat
• Diese Änderungsanforderung tatsächlich umgesetzt und getestet wurde
• Die Rückmeldung aus dem Test wieder in die TARA geflossen ist
• Der Claim nun validiert den aktualisierten Zustand reflektiert

Doch genau hier lauert das Risiko für die Produktzertifizierung und den Feldbetrieb.

Ein Mangel an Traceability ist ein Mangel an Prozessbeherrschung – und dieser wird in folgenden Situationen kritisch:

Fragen, die gestellt werden sollten (aber oft nicht werden):

„Ist durch Einführung einer Security Control das Risiko auch wirklich akzeptabel geworden?”

• Kann man also aus dem Goal einen validierten Claim machen?
• Wird diese Frage nicht systematisch beantwortet, erfährt man erst im Penetration Test oder – schlimmer – im Feld, ob die definierten Security Controls effektiv waren
• Best Practice: Re-Evaluierung des Risikos inklusive implementierter Security Control in der aktualisierten TARA – damit weiß man bereits während der Entwicklung, ob das Ziel erreicht wurde

„Sind alle Claims, die Controls enthalten, durch Penetration Tests validiert?”

• Ohne systematische Verlinkung zu Validierungsaktivitäten ist diese Frage nicht beantwortbar
• Claims ohne Validierung sind Behauptungen ohne Beweis

„Wenn sich neue Vulnerabilities ergeben – wie erkennen Sie die Auswirkungen auf bestehende Risiken?”

• Ohne Mapping von CVEs auf Assets und Anforderungen bleibt dies Handarbeit und Bauchgefühl
• Die TARA veraltet mit jedem Patch-Zyklus ein Stück mehr

„Wenn sich Risiken ändern und sich z.B. neue Goals ergeben – wie sehen Sie die Auswirkungen auf Anforderungen und Testfälle?”

• Ohne bidirektionale Links ist eine vollständige Impact-Analyse unmöglich
• Es entstehen Lücken: neue Risiken ohne Anforderungen, alte Anforderungen ohne aktuellen Risikobezug

Fazit: Traceability in der TARA ist kein Feature, sondern die Voraussetzung für wirksame Fahrzeug-Cybersecurity

Wer bis hierhin gelesen hat, wird vermutlich erkannt haben: Traceability in der Automotive Cybersecurity ist weit mehr als eine technische Spielerei für Prozess-, Workflow- oder Automatisierungs-Enthusiasten.

Sie ist die Voraussetzung dafür, dass Cybersecurity in der Realität eines vernetzten, software-definierten Fahrzeugs (das über Jahre hinweg Updates erhält, neue Bedrohungen abwehren muss und dabei regulatorischen Anforderungen genügen soll) überhaupt funktionieren kann.

Die harte Wahrheit ist: Ohne durchgängige, bidirektionale und semantisch saubere Verlinkung zwischen Item Definition, TARA, ALM-System und Vulnerability Monitoring entstehen nicht zwangsläufig sichere Systeme – eher die Illusion davon. Überspitzt gesagt:

• Dokumente, die im Audit gut aussehen, aber im Change-Prozess (der ja faktisch kommt!) zusammenbrechen.
• Unvalidierte Claims, die behaupten statt beweisen.
• Anforderungen, die im Vakuum entstehen und deren Zusammenhang zum aktuellen Risiko niemand mehr rekonstruieren kann.

Moderne Fahrzeuge sind längst Software-defined Platforms mit Over-the-Air-Updates, Cloud-Connectivity und einer Angriffsfläche, die sich in der Realität schneller verändert als jeder Release-Zyklus.

Statische Sicherheitsdokumentation kann diese Dynamik schlicht nicht abbilden.

Wer heute noch mit isolierten Excel-TARAs und manueller Synchronisation arbeitet, verliert nicht nur den Überblick über die tatsächliche Risikolage – er verliert auch die Fähigkeit, auf neue Bedrohungen oder Architekturänderungen schnell und zuverlässig zu reagieren.

Bereits heute müssen OEMs (und Supplier) nachweisen, dass ihre Cybersecurity-Prozesse nicht nur existieren, sondern tatsächlich wirken. Die Frage nach der durchgängigen Traceability wird dann nicht mehr mit einem Dokument zu beantworten sein. Dann zählt, ob ein Suspect Link nach einer CVE-Meldung tatsächlich zu einer Impact-Analyse geführt hat, ob betroffene Testfälle aktualisiert wurden und ob der aktualisierte Claim den neuen realen Systemzustand reflektiert.

Organisationen, die diese Aufgabenstellung jetzt ernst nehmen und agieren – mit integrierten Tool-Landschaften, in typisierte Links, in diszipliniertes Versionsmanagement und in automatisierte Konsistenzprüfungen – bauen mehr als nur Compliance auf. Sie erschaffen echte Handlungsfähigkeit:

• Die Fähigkeit, bei einer Zero-Day-Schwachstelle innerhalb von Stunden zu wissen, welche Fahrzeuge betroffen sind, welche Komponenten verwundbar sind und welche Maßnahmen greifen müssen.
• Die Fähigkeit, bei einer Architekturänderung sofort zu sehen, welche Sicherheitsziele neu bewertet werden müssen.
• Die Fähigkeit, im Schadensfall lückenlos zu rekonstruieren, warum eine Entscheidung getroffen wurde und welche Evidenz sie stützte.

Der Paradigmenwechsel ist klar: Weg von isolierten Dokumenten, hin zu einem vernetzten Ökosystem, in dem Item Definition, TARA, ALM und Vulnerability Monitoring in einem ständigen, validierten Dialog stehen. Weg von statischen Snapshots, hin zu dynamischen, versionierten Artefakten mit semantisch präzisen Verknüpfungen. Weg von manueller Synchronisation, die bei der ersten substanziellen Änderung kollabiert, hin zu automatisierten Mechanismen, die Suspect Links auslösen, Impact-Analysen anstoßen und Review-Prozesse orchestrieren.

Das ist keine Vision für übermorgen – das ist die Messlatte für heute.

Anmerkung: Mit der CYMETRIS-Plattform für intelligente Cyber-Risikomodellierung und TARA in der Fahrzeugentwicklung steht erstmals eine Software-Lösung zur Verfügung, die durchgängige Traceability von der Item Definition über die TARA bis ins ALM systematisch unterstützt.