Automotive Cybersecurity
UN R155, ISO/SAE 21434 und die Automotive Threat Matrix des Auto-ISAC — wie Angreiferverhalten am Fahrzeug beschrieben, in der TARA bewertet und im Pentest nachgewiesen wird.
Secure Software Development von der ersten Codezeile bis zum Feldeinsatz: Secure Coding, sicherer Entwicklungsprozess (SSDLC), Pipeline- und Lieferkettensicherheit, Produktsicherheit nach Produkttyp – CRA, IEC 62443, UN R155/R156 mit ISO/SAE 21434, MDR/IVDR.
Sichere Software- und Produktentwicklung (Secure Software Development) bedeutet, Sicherheitsanforderungen über den gesamten Lebenszyklus eines Produkts nachweisbar umzusetzen – vom Design über Code, Build und Release bis zur Schwachstellenbehandlung im Feld. Das maßgebliche Regelwerk hängt vom Produkttyp ab: Hard- und Software mit digitalen Elementen fällt unter den Cyber Resilience Act (CRA), auch Industriekomponenten; für sie gilt die Normenreihe IEC 62443 als Stand der Technik, für Maschinen ab dem 20. Januar 2027 zusätzlich die Maschinenverordnung. Fahrzeuge benötigen für die Typgenehmigung UN R155 und R156, meist mit ISO/SAE 21434 umgesetzt. Für Medizinprodukte gelten MDR und IVDR, mit IEC 81001-5-1 als Bezugspunkt. Typgenehmigte Fahrzeuge und Medizinprodukte sind vom CRA ausgenommen, weil eigenes Sektorrecht gilt.
Jedes Thema führt zu einer eigenen Wissensseite mit Vertiefung, Praxisleitfäden und den passenden Leistungen.
UN R155, ISO/SAE 21434 und die Automotive Threat Matrix des Auto-ISAC — wie Angreiferverhalten am Fahrzeug beschrieben, in der TARA bewertet und im Pentest nachgewiesen wird.
Secure Coding, SSDLC-Aufbau und Developer-Enablement — Sicherheit als Teil des Handwerks, nicht als Nachbesserung.
Build-Ketten härten, Abhängigkeiten beherrschen, Artefakte signieren — von SBOM über SLSA bis zur KI-gestützten Pipeline-Security.
Welche Cybersicherheitsanforderungen gelten, entscheidet der Produkttyp. Die vier Produkttypen im Überblick – mit Geltungsbereich, maßgeblichen Normen und Stichtagen; wo eigenes Sektorrecht greift, tritt der CRA zurück.
Branchenübergreifende EU-Pflichten für Hersteller vernetzter Hard- und Software – von Planung und Entwicklung bis zur Schwachstellenbehandlung über den gesamten Lebenszyklus.
Internationale Normenreihe für sichere Entwicklungsprozesse, Komponenten und Systeme der industriellen Automatisierung – freiwillig, aber anerkannter Stand der Technik und Basis künftiger harmonisierter CRA-Normen.
Cybersicherheit ist Voraussetzung der Typgenehmigung: Fahrzeughersteller brauchen ein zertifiziertes Cybersecurity-Managementsystem (CSMS) und ein geregeltes Software-Update-Management.
IT-Sicherheit gehört zu den grundlegenden Sicherheits- und Leistungsanforderungen von MDR und IVDR – nachzuweisen vor dem Inverkehrbringen und fortzuführen über Marktüberwachung und Instandhaltung im Feld.
Wo stehen Sie? OWASP-basierte Selbstbewertungen (SAMM, ISVS, SCVS) und VamiAppSec — unsere LLM-gestützte Plattform für Secure SDLC und Produktsicherheits-Compliance, mit voll integriertem VamiDAST für KI-DAST.
Regelbasierte Scanner finden zuverlässig Syntaxfehler. Gebrochene Autorisierung, Geschäftslogik und falsch angenommene Berechtigungen haben dagegen keine Signatur. Wir bringen Regeln, KI-Reasoning und Exploit-Validierung in eine Ordnung, die Ihr Team betreiben kann.
Beratungsleistung — die Wissensseiten oben bleiben frei zugänglich.
Vertiefende Wissensseiten zu den Themen, die aktuell die meisten Fragen aufwerfen — mit verifizierten Quellen und konkreten Maßnahmen.
Wie Kliniken, Praxen und Labore KI-Systeme sicher betreiben: Betreiberpflichten nach dem AI Act im Zusammenspiel mit der MDR, geteilte Verantwortung mit dem Anbieter, ein Bedrohungsmodell für medizinische KI, Risikobewertung und belastbare Nachweise.
Zur WissensseiteWie Hersteller und Kliniken vernetzte Medizinprodukte im Feld sicher halten: mit Inventar und SBOM, klinisch begründeter Triage, Patches als kontrollierter Änderung, geordneter Schwachstellenmeldung und abgestimmten Meldewegen.
Zur WissensseiteWie Hersteller den gesetzlich geforderten Zugang zu Gerätedaten so gestalten, dass Patientensicherheit, Gesundheitsdaten und Geschäftsgeheimnisse geschützt bleiben – mit Bedrohungsmodell, Penetrationstest und integriertem Managementsystem.
Zur WissensseiteKI-Modelle schlagen Pakete vor, die es nicht gibt — und Angreifer können genau diese Namen registrieren. Coding-Agenten installieren mit Terminal-Zugriff, was sie für richtig halten. Dieser Deep Dive verbindet Typo- und Slopsquatting in npm und PyPI mit einem Sicherheitsmodell für Coding-Agenten und ihren Harness: Angriffskette, fünf Schutzschichten, Pflichten aus CRA, NIS2 und DORA, Self-Assessment und CISO-Whitepaper.
Zur WissensseiteWie die Auto-ISAC-Matrix Angreiferverhalten am Fahrzeug beschreibt – und wie sie TARA nach ISO/SAE 21434, den Nachweis nach UN R155, OWASP-Testkataloge und das Vehicle SOC auf eine gemeinsame Sprache bringt.
Zur WissensseiteWie Sie Schwachstellen systematisch vermeiden: die aktuelle Landkarte aus CWE Top 25 und OWASP Top 10:2025, ASVS 5.0 als Anforderungsrahmen und die Praktiken, die im Entwicklungsalltag den Unterschied machen.
Zur WissensseiteStatische Codeanalyse ist der am dichtesten kreuzreferenzierte Kontrollpunkt im sicheren Entwicklungszyklus – und zugleich das Werkzeug mit dem größten Frustpotenzial. Was SAST technisch leistet, wo seine Grenzen bewiesen sind, welche Standards es verlangen und was KI daran gerade ändert.
Zur WissensseiteSprachmodelle triagieren Findings, schließen semantisch über Funktionsgrenzen hinweg und finden reale Zero-Days. Was davon belegt ist, welche Werkzeuge es 2026 gibt und wo die neuen Grenzen und Risiken liegen — mit Quellen statt Marketing.
Zur WissensseiteWie Sie Sicherheit systematisch in jede Phase der Softwareentwicklung integrieren – mit dem NIST SSDF als Practice-Katalog, OWASP SAMM als Reifegradmodell und Security Gates von den Anforderungen bis zum Betrieb.
Zur WissensseiteTop 10, ASVS, Cheat Sheet Series, Developer Guide, WSTG, SAMM und Werkzeuge wie Dependency-Track und ZAP: was welches Projekt leistet – und wie sich die Bausteine im Entwicklungsalltag zu einem durchgängigen Prozess verbinden.
Zur WissensseiteWie Sie mit dem Vier-Fragen-Rahmen, STRIDE, PASTA und Attack Trees Sicherheitsrisiken bereits in der Designphase identifizieren – und Threat Modeling dauerhaft in SDLC und agilen Teams verankern.
Zur WissensseiteWie Sie Sicherheitswissen dauerhaft in Ihren Entwicklungsteams verankern – von der Auswahl geeigneter Champions über Zeitbudget und Community bis zur Erfolgsmessung nach OWASP-Guide und SAMM.
Zur WissensseiteWie Sie Software-Stücklisten (SBOMs) standardkonform erzeugen, verteilen und operativ nutzen – von der Formatwahl über die Build-Integration bis zur kontinuierlichen Schwachstellen-Korrelation.
Zur WissensseiteWarum Build- und Deployment-Pipelines zu den kritischsten Systemen Ihrer IT gehören – und wie Sie sie entlang der OWASP Top 10 CI/CD Security Risks und SLSA strukturiert absichern.
Zur WissensseiteWarum die Sicherheit vernetzter Produkte eigene Normen, Prozesse und Organisationsstrukturen erfordert – von ISO/SAE 21434 über IEC 62443 und EN 18031 bis zum PSIRT.
Zur WissensseiteJedes Whitepaper hat eine eigene Seite mit Details und direktem Download-Formular.
EU CRAEU Cyber Resilience Act — Praxisleitfaden für digitale ProdukteZur Whitepaper-Seite
CI/CD SecurityCI/CD Pipeline Security: Wie Angreifer Ihre Pipeline übernehmen — und wie Sie sie zurückerobernZur Whitepaper-Seite
DevSecOpsOWASP Top 10 CI/CD Security Risks — Praxisleitfaden mit Compliance-CrosswalkZur Whitepaper-Seite
Secure CodingSecure Coding in der KI-Ära: Die CWE Top 25 (2025) und Secure-by-DesignZur Whitepaper-Seite
KI & CI/CD SecurityKI-gestützte Security in der CI/CD-PipelineZur Whitepaper-Seite
Automotive CybersecurityAutomotive Threat Matrix — ATT&CK für FahrzeugeZur Whitepaper-Seite
Software-Lieferkette / KI-AgentenSlopsquatting & Coding-Agenten für CISOs — die KI-Software-Lieferkette absichernZur Whitepaper-Seite Welches Regelwerk gilt für welches Produkt – und wo greift der Cyber Resilience Act nicht? Kurze Antworten auf Fragen, die Hersteller und Verantwortliche für Regulatory Affairs häufig stellen.
Nein. Produkte, die unter die MDR oder die IVDR fallen, sind vom Cyber Resilience Act ausgenommen. Ihre Cybersicherheit regeln die beiden Medizinprodukte-Verordnungen; als Bezugspunkte dienen die Leitlinie MDCG 2019-16 Rev. 1 und die Norm IEC 81001-5-1, die bislang nicht harmonisiert ist. Software und Geräte ohne medizinische Zweckbestimmung – etwa allgemeine Klinik-IT – können dagegen sehr wohl unter den CRA fallen.
Für typgenehmigte Pkw, Busse, Lkw und Anhänger nicht: Sie fallen unter die EU-Typgenehmigung, die Cybersicherheit über UN R155 und Software-Updates über UN R156 regelt. Die Ausnahme erfasst in der Regel auch Systeme und Bauteile, die für solche Fahrzeuge typgenehmigt werden. Seit 2025 sind per delegiertem Rechtsakt zudem Zwei- und Dreiräder sowie Quads ausgenommen; für neue Typen dieser Klasse gilt UN R155 ab dem 11. Dezember 2027. Nachrüstprodukte, Ladetechnik oder Apps außerhalb der Typgenehmigung können dagegen unter den CRA fallen. Ebenfalls im CRA bleiben Fahrräder mit Pedalantrieb der Klasse L1e.
Nein, IEC 62443 ist eine internationale Normenreihe und kein Gesetz. Sie gilt jedoch als Stand der Technik für industrielle Komponenten und wird derzeit für den CRA aufbereitet – unter anderem durch Anpassungen von EN IEC 62443-4-1 und -4-2 sowie produktspezifische Profile. Die Vermutung, die gesetzlichen Anforderungen zu erfüllen (Konformitätsvermutung), entsteht erst, wenn eine harmonisierte Fassung im Amtsblatt der EU zitiert ist; Stand Oktober 2026 ist das nicht der Fall.
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die zentrale Meldeplattform der ENISA (Single Reporting Platform) an das zuständige nationale CSIRT melden. Die Fristen: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Bereitstellung einer Korrektur, bei Vorfällen binnen eines Monats nach der Meldung. Die Pflicht gilt auch für Produkte, die schon vor dem Stichtag in Verkehr gebracht wurden.
UN R155 ist eine verbindliche Typgenehmigungsvorschrift: Ohne zertifiziertes Cybersecurity-Managementsystem (CSMS) erhält ein Fahrzeugtyp keine Genehmigung. ISO/SAE 21434 ist dagegen der Engineering-Standard, mit dem Hersteller und Zulieferer die geforderten Prozesse umsetzen, etwa die Bedrohungs- und Risikoanalyse (Threat Analysis and Risk Assessment, TARA). Die Norm ist nicht gesetzlich vorgeschrieben, aber der übliche Nachweisweg; Lücken wie den Bedrohungskatalog der R155 decken Hersteller gesondert ab.
Noch nicht. Der Normungsauftrag der Kommission umfasst 41 horizontale und produktspezifische Normen. Nach einem Änderungsentwurf, der Stand Oktober 2026 nicht angenommen ist, sollen erste horizontale Normen bis Ende Oktober 2026 und produktspezifische bis Ende Dezember 2026 vorliegen. Solange keine Fassung im Amtsblatt zitiert ist, gibt es keine Konformitätsvermutung: Hersteller begründen die Erfüllung der Anforderungen eigenständig, und wichtige Produkte der Klasse I benötigen dann eine Benannte Stelle.
Im Erstgespräch ordnen wir Ihren SSDLC-Reifegrad ein — und zeigen, welche Maßnahmen in Pipeline, Code und Produktzulassung den größten Hebel haben.