Compliance Intelligence für vernetzte und sicherheits- kritische Produkte

Die HARA (Hazard Analysis and Risk Assessment nach ISO 26262) bewertet, wie Systemfehlfunktionen Menschen gefährden können. Die TARA (Threat Analysis and Risk Assessment nach ISO 21434) bewertet, wie Angreifer das System kompromittieren können. Beide analysieren dasselbe System — deshalb teilen sie sich die Systemgrenze.

Der entscheidende Unterschied: Safety schützt die Umgebung vor dem System (vor unbeabsichtigten Fehlfunktionen), Security schützt das System vor der Umgebung (vor gezielten Angriffen). Methodisch arbeiten beide risikobasiert und lifecycle-übergreifend. Eine gemeinsame, modellbasierte Systemarchitektur als Basis für HARA und TARA reduziert Redundanz erheblich — und ist der Ansatz, den itemis in Projekten mit parallelen Safety- und Security-Anforderungen verfolgt.

Ja — das ist sogar methodisch sinnvoll und die effizienteste Umsetzung. Alle drei verlangen lückenlose Traceability von Anforderungen bis zur Verifikation. itemis ANALYZE implementiert eine herstellerunabhängige Traceability-Schicht über bestehende Werkzeuglandschaften — ohne Migration bestehender Werkzeuge.

Sicherheitsanforderungen aus der HARA, Cybersecurity-Ziele aus der TARA und Systemarchitektur werden im gleichen Modell verknüpft. Änderungen propagieren automatisch; Compliance-Nachweise entstehen als Nebenprodukt der Entwicklung statt als separate Dokumentationsaufgabe vor dem Audit. ASPICE fordert bidirektionale Traceability als Baseline-Praxis — ein gut eingeführtes Traceability-System nach diesem Ansatz erfüllt ASPICE-Anforderungen und liefert gleichzeitig die Evidenzkette für ISO 26262 und ISO 21434.

Excel-TARAs altern schnell: Qualität variiert je nach Bearbeiter, jede Änderung erfordert manuelle Aktualisierung aller verknüpften Dokumente, und Konsistenz ist strukturell nicht sicherstellbar. Bei kurzen Entwicklungszyklen oder OTA-Updates skaliert das nicht.

itemis SECURE macht die TARA modellbasiert: Bedrohungen, Angriffspfade und Maßnahmen sind an ein konsistentes Modell gebunden. KI-Assistenten schlagen Bedrohungen und Angriffsbäume kontextbewusst vor — auf Basis der vollständigen TARA-Geschichte und vorhandener Systemarchitektur. Änderungen propagieren durch das Modell. Laut itemis reduziert die agentische Automatisierung den TARA-Aufwand um bis zu 80 % bei vollem Human-in-the-Loop-Kontrollprinzip. Das Ergebnis: ein lebendes Sicherheitsmodell statt eines PDFs, das drei Monate nach dem Audit veraltet ist.

Zwei Fristen sind entscheidend: Ab September 2026 gelten Meldepflichten für aktiv ausgenutzte Schwachstellen — 24-Stunden-Frühwarnung, 72-Stunden-vollständige Meldung an ENISA. Ab Dezember 2027 gelten alle CRA-Anforderungen: Security by Design, SBOM-Pflicht, Lifecycle-Verantwortung und CE-Kennzeichnung mit Cybersecurity-Nachweis.

Empfohlene Reihenfolge: Erstcheck ob Produkt in den Geltungsbereich fällt → Vulnerability-Disclosure-Prozess etablieren → TARA für alle CRA-relevanten Produkte durchführen → Requirements Traceability für die Nachweisführung aufbauen → Konformitätsbewertung und CE-Kennzeichnung. Die CRAIG-Community (itemis ist Gründungsmitglied) bietet kostenlose Scope-Checks, Templates und lokale Netzwerke. itemis SECURE deckt die technische Umsetzung ab — von der TARA bis zum Lifecycle Management.

Traceability lohnt sich, wenn mehrere Disziplinen an einem System arbeiten, Regulierungsdruck durch Standards wie ISO 26262, ISO 21434, CRA oder ASPICE besteht und Anforderungen sich dynamisch ändern. Die ROI-Kalkulation kippt schnell: ASPICE-Vorbereitungen, die bisher Wochen dauern, lassen sich mit durchgängiger Traceability auf Stunden reduzieren.

Zu früh ist es, wenn Grundlagenprozesse noch nicht definiert sind — dann digitalisiert Traceability nur das vorhandene Chaos. Oder wenn Management-Commitment fehlt: Traceability ist eine kulturelle Veränderung, kein Werkzeug-Rollout. itemis sagt das klar im ersten Gespräch — und empfiehlt, womit zu starten ist, wenn Traceability noch nicht passt.

ASPICE (Automotive SPICE) ist ein Prozessreifemodell — es bewertet, wie gut Entwicklungsprozesse organisiert sind, nicht was gebaut wird. ISO 26262 ist ein produktbezogener Safety-Standard für elektrische und elektronische Systeme in Fahrzeugen. ISO 21434 ist der entsprechende Cybersecurity-Standard.

Die Verbindung: ASPICE fordert bidirektionale Traceability als Baseline-Praxis für alle Engineering-Prozesse. Das ist dieselbe Grundlage, die ISO 26262 für die Safety-Evidenzkette und ISO 21434 für die Security-Evidenzkette verlangt. Wer Traceability einmal sauber einführt, erfüllt damit gleichzeitig die Prozessanforderungen aller drei Frameworks — statt drei separate Compliance-Welten zu pflegen.