Leistung · Produkt-Cybersecurity

Produkt-Cybersecurity & CRA

Security auf Produktebene, im Engineering verankert statt als Papierwerk daneben: CRA-Readiness, IEC 62443, Secure SDLC, SBOM und Schwachstellenmanagement. Ich übersetze regulatorische Anforderungen in Architektur, Build-Infrastruktur und Prozesse, die Ihr Team im Alltag tatsächlich lebt.

CRA · IEC 62443 · IEC 81001-5-1 · Secure SDLC · SBOM · Threat Modelling
Umfang

Was ich mache

CRA-Readiness-Assessment

Bestandsaufnahme Ihres Produkts gegen die Anforderungen des Cyber Resilience Act: was bereits erfüllt ist, was fehlt und ein realistischer Fahrplan mit Prioritäten statt einer abstrakten Lückenliste.

Secure SDLC & Entwicklungsprozesse

Sichere Entwicklung als Teil des bestehenden Workflows: Coding-Regeln, Reviews, Security-Gates in der CI und Prozesse, die auf IEC 62443-4-1 abbilden, ohne das Team auszubremsen.

Threat Modelling & Risikoanalyse

Systematische Bedrohungsanalyse auf Architekturebene: Angriffsflächen, Schutzbedarf und daraus abgeleitete Designmaßnahmen, dokumentiert so, dass Auditoren und Entwickler dasselbe Dokument nutzen können.

SBOM & Dependency-Kontrolle

Software Bill of Materials als Nebenprodukt des Builds statt als manuelle Excel-Pflege: kontrollierte Abhängigkeiten mit Conan und CMake, aus denen SBOMs automatisch erzeugt werden.

Sichere Updates & Schwachstellenmanagement

Update-Mechanismen für Geräte im Feld, Monitoring bekannter Schwachstellen in Drittkomponenten und ein Prozess, der aus einer CVE eine bewertete, nachvollziehbare Entscheidung macht.

Security für Gesundheitssoftware

IEC 81001-5-1 und FDA-Cybersecurity-Anforderungen, integriert in den IEC-62304-Lebenszyklus: ein gemeinsamer Workflow statt zwei paralleler Dokumentationswelten.

Typische Einsätze

Wann Teams mich hinzuziehen

Die meisten Security-Engagements beginnen in einer dieser Situationen. Wenn Ihre ähnlich aussieht, lohnt sich ein Gespräch.

01
Der CRA kommt auf Ihr Produktportfolio zu

Ihre Produkte fallen unter den Cyber Resilience Act und niemand weiß genau, was das konkret bedeutet. Ich bewerte den Stand, priorisiere die Lücken und setze die Engineering-Maßnahmen mit um.

02
Kunden oder Auditoren verlangen IEC-62443-Nachweise

Ein Großkunde oder eine Zertifizierung fordert Nachweise zu sicherer Entwicklung. Ich baue die Prozesse und Artefakte in Ihren bestehenden Workflow ein, statt eine Parallelwelt zu schaffen.

03
Die SBOM ist nicht lieferbar

Abhängigkeiten sind historisch gewachsen und unkontrolliert, eine belastbare SBOM ist unmöglich. Ich modernisiere Build und Dependency-Management, sodass die SBOM aus dem Build kommt.

04
Security-Feedback im Zulassungsverfahren

FDA oder Benannte Stelle verlangen Cybersecurity-Prozesse für Ihr Medizinprodukt. Ich integriere Threat Modelling, SBOM und Schwachstellenmanagement in Ihren 62304-Lebenszyklus.

Engineering-Umgebung

Werkzeuge und Normen, mit denen ich arbeite

Security-Beratung aus der Engineering-Praxis: dieselben Build- und CI-Werkzeuge, die Ihr Produkt erzeugen, erzeugen auch die Nachweise. Die genannten Normen bezeichnen Projekterfahrung, keine persönliche Zertifizierung.

CRA IEC 62443 IEC 81001-5-1 IEC 62304 Threat Modelling SBOM / CycloneDX Conan CMake GitLab CI Azure DevOps
Arbeitsergebnisse bilden auf Anforderungen ab
SBOM aus dem Build
CRA · Conan / CMake
Secure-SDLC-Prozesse
IEC 62443-4-1
Threat Model & Risikoanalyse
IEC 62443 · Schnittstelle ISO 14971
Update- & Schwachstellenprozess
CRA · CVE-Monitoring
Security für Gesundheitssoftware
IEC 81001-5-1 · FDA Guidance

Security-Projekt besprechen

CRA-Readiness, IEC 62443, SBOM oder Security im Zulassungsverfahren: Erzählen Sie mir, wo Ihr Produkt steht.