CRA, NIS2 und Vulnerability Disclosure

SBOM und Vulnerability Disclosure für vernetzte Produkte

Wir helfen Maschinen- und Geräteherstellern, Software-Komponenten, Schwachstellen und Verantwortlichkeiten nachvollziehbar zu machen. Erst klären wir den Scope, dann setzen wir einen passenden Pilot auf.

Vorgehen

Vom Transparenzbedarf zum nutzbaren Pilot

Jede Zusammenarbeit liefert eine sichtbare Entscheidungs- oder Lieferbasis. Sie behalten die fachliche Verantwortung, wir bringen Struktur und technische Tiefe ein.

Ausgangslage

Warum das Thema gerade auf dem Tisch liegt

Einordnung

Worum es hier geht

Erst fachlich verstehen, dann passende Technik auswählen und sinnvoll einführen.

Leistungsbausteine

Module

Erst Scope, Zielbild und Pilot. Danach klarer Ausbaupfad mit passenden Paketen statt isolierter Tool-Einführung.

Pakete

Pakete

Richtwerte für typische Einstiege. Inhalt und Aufwand passen wir an Produktlandschaft, Reifegrad und regulatorischen Druck an.

* Reisekosten werden zusätzlich berechnet und sind nicht im Preis enthalten. Alle Pakete sind auch Remote und auf Englisch möglich.

Ihr Ergebnis

Was nach Pilot und Beratung steht

Weg von einem losen Tool-Setup hin zu einem nutzbaren Arbeitsmodus für Produkte, Releases und laufenden Betrieb.

Umsetzung

Was wir fachlich und technisch mitdenken

Im Pilot mitgedacht

Wir verbinden die technischen Datenflüsse mit den Rollen und Routinen, die sie im Alltag belastbar machen.

Bestandteile

  • Hosting in Azure, AWS oder On-Premises
  • Erzeugung von SBOMs in Formaten wie CycloneDX oder SPDX und Uploadpfade aus bestehenden Build-, CI/CD- und Release-Systemen
  • Struktur für Projekte, Versionen und Releases für spätere Pflege, Audits und CRA-Nachweise
  • Einbindung von Ticketing, Produktpflege und organisatorischen Freigaben
  • Vulnerability-Transparenz über Auslieferung, Betrieb und Supportzeiträume hinweg
  • Lizenz-Governance, Supplier-Daten und manuelle Ergänzungen als Teil des Gesamtbilds

Einstieg

CRA-Einstieg noch offen?

Wenn zuerst regulatorische Einordnung, Betroffenheit und erste Handlungsfelder geklärt werden sollen, passt unser CRA Workshop als vorgelagerter Einstieg.

FAQ

Häufige Fragen zum Einstieg

  • Was ist eine SBOM überhaupt?

    Eine SBOM ist eine strukturierte Stückliste Ihrer Software. Sie beschreibt, welche Komponenten und Versionen in einem Produkt stecken. Das schafft Grundlage für Schwachstellenbewertung, Kundenanfragen, Audits und Vulnerability Disclosure.

  • Welche Formate sind typisch?

    Häufig begegnen uns CycloneDX und SPDX. Welches Format sinnvoll ist, hängt von vorhandenen Tools, Lieferanten und Zielen ab. Wir erklären Vor- und Nachteile im Workshop und bauen darauf passenden Pilot auf.

  • Muss die Lösung in der Cloud betrieben werden?

    Nein. Wir unterstützen Betriebsmodelle in Azure, AWS und On-Premises und richten den Ansatz nach Ihrer Infrastruktur und Governance aus.

  • Müssen wir Dependency-Track, SBOM oder CycloneDX schon kennen?

    Nein. Genau dafür ist Einstieg gedacht. Wir holen Fachbereiche, Entwicklungsleitung und technische Teams auf gemeinsamen Stand und führen Begriffe, Formate und Werkzeugoptionen so ein, dass daraus konkrete Entscheidungen werden.

  • Müssen sofort alle Produkte angebunden werden?

    Nein. Der Einstieg ist bewusst gestuft angelegt: erst Scope, SBOM-Pilot und Zielbild, danach optional Rollout und weiterer Ausbau.

  • Geht es nur um Vulnerabilities?

    Nein. Neben Schwachstellen betrachten wir auch Lizenz-Governance, Produktkontext, Nachverfolgbarkeit und Prozessintegration.

  • Wie passt das zu CRA und NIS2?

    Das Vorgehen schafft Transparenz über Abhängigkeiten, unterstützt nachvollziehbare Sicherheitsprozesse und hilft, regulatorische Anforderungen im Produktlebenszyklus praktisch umzusetzen.

  • Können bestehende Pipelines und SBOM-Generatoren weiterverwendet werden?

    In vielen Fällen ja. Wir binden vorhandene Flows aus bestehenden Pipeline-, Build- oder Automatisierungssystemen ein, statt unnötig neue Toolketten aufzubauen.

  • Brauchen wir vor dem Start bereits fertige SBOMs?

    Nein. Im Workshop klären wir, welche Daten heute schon aus Builds, Paketquellen oder bestehenden Tools kommen und was im Pilot ergänzt werden muss.

  • Wer sollte beim Pilot beteiligt sein?

    Typisch sind Produktverantwortliche, Entwicklung, Security und Plattform oder DevOps. Ziel ist ein Pilot, der technisch funktioniert und organisatorisch getragen wird.

  • Was steht nach Pilot und Beratung konkret?

    Typisch stehen dann ein belastbarer durchgängiger Pfad, klare Verantwortlichkeiten, erste auswertbare CycloneDX und Dependency-Track Daten und ein priorisierter Ausbaupfad für weitere Produkte und Integrationen.

  • Können Sie auch nach dem Pilot weiter begleiten?

    Ja. Je nach Bedarf unterstützen wir bei Rollout, Schulung, Betriebsstabilisierung oder als Managed Service im laufenden Betrieb.

Gespräch

Ihren SBOM-Pilot sinnvoll zuschneiden

Wir verbinden Produkte, Datenquellen und Prozesse zu einem Einstieg, der im Betrieb trägt.

Wissen

Relevante Informationen

Neue Sicherheitsmeldung: Welche unserer Maschinen ist betroffen?

Neue Sicherheitsmeldung: Welche unserer Maschinen ist betroffen?

6. Oktober 202610 Min.
Ein Advisory am Freitagnachmittag, ein Schaltschrank voller Komponenten und eine einfache Frage: Welche Maschinen müssen wir prüfen? Wie Produktidentität die Antwort möglich macht.
Dependency-Track für Maschinenhersteller sinnvoll strukturieren

Dependency-Track für Maschinenhersteller sinnvoll strukturieren

29. September 20269 Min.
Maschinenhersteller können Software-Releases in Dependency-Track bewerten und über die Installed Base nachvollziehen, welche Version auf welcher Maschine läuft.
Die versteckten Kosten alter Software: Wann Legacy-Systeme zum Geschäftsrisiko werden

Die versteckten Kosten alter Software: Wann Legacy-Systeme zum Geschäftsrisiko werden

22. September 202612 Min.
Softwaremodernisierung ist mehr als ein Technologiewechsel. Wenn Wissen verloren geht, Änderungen langsamer werden und Sicherheitsupdates ausbleiben, wird aus einer funktionierenden Anwendung ein Geschäftsrisiko.
CRA: Guidance hilft, entscheiden musst du trotzdem selbst

CRA: Guidance hilft, entscheiden musst du trotzdem selbst

15. September 20266 Min.
Zwei aktuelle VDMA-Stellungnahmen zeigen, warum Hersteller offene CRA-Auslegungsfragen begründet entscheiden und später überprüfen müssen.
CRA-Normen werden konkret: Vier neue Bausteine für Hersteller

CRA-Normen werden konkret: Vier neue Bausteine für Hersteller

25. August 20269 Min.
BSI TR-03183-1 in Version 1.0.0, prEN 40000-1-3, prEN 50742 und die ENISA Single Reporting Platform machen die CRA-Vorbereitung prüfbarer. Der Beitrag zeigt, welche neuen Nachweise Hersteller daraus ableiten können.
Copilot und Coding Agents wirksam nutzen

Copilot und Coding Agents wirksam nutzen

4. August 20269 Min.
Gute Prompts und Instructions reichen nicht. Erst eine belastbare Grundlage in der Softwareentwicklung aus Anforderungen, Tests, Pipelines und Betrieb macht Änderungen mit GenAI nutzbar.
CRA und Open Source: Die neue Rolle des Open Source Stewards erklärt

CRA und Open Source: Die neue Rolle des Open Source Stewards erklärt

21. Juli 202612 Min.
Der Cyber Resilience Act schafft erstmals eine eigene Rolle für Open-Source-Verantwortliche. Dieser Artikel erklärt, wer als Open Source Steward gilt, welche Pflichten Art. 24 CRA tatsächlich fordert und was Hersteller beim Einsatz von Open Source beachten müssen.
Lunaris auf der DWX 2026

Lunaris auf der DWX 2026

3. Juli 20262 Min.
Wir waren 2026 auf der Developer Week mit vier Vorträgen vertreten. Wer nicht dabei war, kann die Folien herunterladen.
CRA Konformitätsbewertung: Von der Produktkategorie zur CE-Kennzeichnung

CRA Konformitätsbewertung: Von der Produktkategorie zur CE-Kennzeichnung

30. Juni 202612 Min.
Der Cyber Resilience Act schreibt je nach Produktkategorie unterschiedliche Konformitätsbewertungsverfahren vor. Dieser Artikel zeigt, welches Verfahren für welches Produkt gilt und wie Hersteller Schritt für Schritt zur CE-Kennzeichnung gelangen.