Basis
Basis-Workshop und Scope-Klärung
Typisch 1 bis 3 Tage
Gemeinsames Bild zu regulatorischem Druck, Produktlandschaft, Datenquellen und erstem Pilotumfang.
CRA, NIS2 und Vulnerability Disclosure
Transparenz für Software-Lieferketten
Wenn CRA, NIS2 oder Kundenanforderungen Druck machen, schaffen wir zuerst fachliche Klarheit und dann technische Umsetzbarkeit. SBOMs, Formate wie CycloneDX und Werkzeuge wie Dependency-Track setzen wir so ein, dass daraus belastbare Abläufe für Transparenz, Bewertung und Nachverfolgbarkeit entstehen.
Einstieg und Pilot besprechenWarum das Thema gerade auf dem Tisch liegt
Regulatorischer Druck, aber kein klarer Einstieg
CRA, NIS2, Kundenaudits und Vulnerability Disclosure erzeugen Handlungsdruck. Viele Verantwortliche wissen aber zuerst nur, dass mehr Transparenz über eingesetzte Software und Schwachstellen nötig wird.
Viele Datenquellen, keine gemeinsame Sicht
Builds, Paketquellen, Lieferantenangaben und manuelle Listen liefern Informationen mit unterschiedlicher Qualität. Ohne gemeinsames Zielbild bleibt unklar, welche Daten für Audits, Support und Meldepflichten belastbar sind.
Tool-Auswahl allein löst das Problem nicht
SBOMs, Formate wie CycloneDX oder SPDX und Werkzeuge wie Dependency-Track sind Mittel zum Zweck. Erst mit Projektstruktur, Rollen, Freigaben und Nachverfolgbarkeit entsteht nutzbarer Mehrwert.
Betrieb muss audit- und rolloutfähig bleiben
Plattformbetrieb, Ticketing, Produktpflege, Releaseprozesse und bestehende Security-Abläufe müssen sauber zusammenspielen. Sonst bleibt Transparenz punktuell und versandet nach dem ersten Pilot.
Worum es hier eigentlich geht
Erst fachlich verstehen, dann passende Technik auswählen und sinnvoll einführen.
Worum geht es fachlich
Im Kern geht es um nachvollziehbare Antworten auf einfache Fragen: Welche Fremd- und Open-Source-Bausteine stecken in welchem Produkt? Welche Schwachstellen sind relevant? Wer muss reagieren und wie lässt sich das gegenüber Kunden, Audits und Regulierung belegen?
Was ist eine SBOM
Eine SBOM ist vereinfacht gesagt die Zutatenliste einer Software. Sie beschreibt Komponenten, Versionen und Beziehungen. Dadurch werden Vulnerability Disclosure, Patch-Planung, Lieferantenbewertung und spätere Nachverfolgung überhaupt erst systematisch möglich.
Welche Tools gibt es
Typische Austauschformate sind CycloneDX und SPDX. Erzeugt werden sie oft in Build- oder CI/CD-Strecken. Werkzeuge wie Dependency-Track helfen später beim Sammeln, Bewerten und Nachverfolgen. Wir erklären diese Technik im richtigen Maß und binden nur das ein, was für Ihren Einstieg sinnvoll ist.
Module
Erst Scope, Zielbild und Pilot. Danach klarer Ausbaupfad mit passenden Paketen statt isolierter Tool-Einführung.
Basis
Pilotimplementierung
Typisch 5 bis 15 Tage
Erste nutzbare Umgebung und belastbarer durchgängiger Pfad für ausgewählte Produkte, Releases und SBOM-Daten.
Basis
Beratung zu Struktur, Integration und Prozessen
Typisch 4 bis 12 Tage, verteilt über mehrere Termine
Zielmodell für Projektstruktur, Verantwortlichkeiten, Lifecycle und Einbindung in bestehende Abläufe.
Erweiterung
Erweiterte Implementierung
Typisch ab 5 Tagen, abhängig von Rollouttiefe
Ausbau vom Piloten zu wiederholbaren Rollout- und Integrationsmustern für weitere Produkte und Teams.
Erweiterung
Schulung und Enablement
Typisch 1 bis 3 Tage
Praxisnaher Wissenstransfer für SBOM-Nutzung, Bewertung, Pflege und Betrieb.
Erweiterung
Managed Service
Typisch 3 bis 10 Tage Setup, danach laufende monatliche Unterstützung
Nachhaltige Unterstützung für Plattform, Projektpflege und operative Fragen im Tagesgeschäft.
Pakete
Richtwerte für typische Einstiege. Inhalt und Aufwand passen wir an Produktlandschaft, Reifegrad und regulatorischen Druck an.
Einstiegsworkshop
2 Tage
ab 5.000 EUR
Schneller Einstieg mit erstem Zielbild für Transparenz, Vulnerability Disclosure und sinnvolle nächste Schritte.
Enthalten
Scope-Klärung CRA- und NIS2-Einordnung SBOM- und Datenquellen-Überblick Erste Roadmap
Workshop plus Pilot
Workshop plus erste Pilotimplementierung
ab 10.000 EUR
Vom Verstehen ins Machen: Nach Workshop setzen wir für ausgewählte Produkte erste belastbare Datenflüsse und eine nutzbare Pilotumgebung auf.
Enthalten
Einstiegsworkshop Pilotzuschnitt Erste SBOM-Erzeugung Pilot-Setup für Transparenz und Findings
Komplettpaket
Workshop, Pilot, Prozessberatung und Training
ab 25.000 EUR
Kompletter Einstieg mit fachlicher Einordnung, technischem Pilot, Prozessberatung und Enablement für Teams, die nicht nur prüfen, sondern tragfähig aufbauen wollen.
Enthalten
Einstiegsworkshop Pilotimplementierung Prozess- und Governance-Beratung Training und Enablement
Was nach Pilot und Beratung steht
Kein loses Tool-Setup, sondern ein nutzbarer Arbeitsmodus für Produkte, Releases und laufenden Betrieb.
Belastbare Sicht auf betroffene Software
Sie sehen früher, welche Komponenten in welchen Produkten stecken, welche Daten belastbar sind und wo akuter Handlungsbedarf entsteht.
Tragfähige Prozesse für CRA
Security, Produktpflege, Betrieb und Ticketing arbeiten auf Basis eines gemeinsamen Zielbilds für Transparenz, Vulnerability Disclosure und Nachverfolgbarkeit.
Skalierbarer Rollout
Wenn Pilot und Zielbild stehen, lassen sich weitere Produkte, Integrationen und Rolloutmuster planbar ergänzen.
Mehr Eigenständigkeit im Team
Ihr Team bekommt einen nutzbaren Arbeitsmodus für Bewertung, Nachverfolgung und Betrieb, punktuell begleitet oder dauerhaft unterstützt.
Was wir fachlich und technisch mitdenken
- 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
CRA-Einstieg noch offen?
Wenn zuerst regulatorische Einordnung, Betroffenheit und erste Handlungsfelder geklärt werden sollen, passt unser CRA Workshop als vorgelagerter Einstieg.
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.
Pilot statt Big Bang
Wir starten mit wenigen Produkten, belastbaren Datenflüssen und einem operativ nutzbaren Setup. Danach entscheiden Sie auf Basis echter Ergebnisse, wie weit Rollout, Schulung und Betriebsmodell ausgebaut werden sollen.
Relevante Informationen
Lunaris auf der DWX 2026
3. Juli 2026 2 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
30. Juni 2026 12 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.
CRA als Reifegradtest für Softwareentwicklung: Unser dotnetpro-Artikel als PDF
24. Juni 2026 1 Min.
Unser Artikel in der dotnetpro 3/26 zeigt, warum der Cyber Resilience Act kein reines Compliance-Thema ist, sondern ein ehrlicher Reifegradtest für Softwareentwicklung und Produktverantwortung.
5 typische Azure-RBAC-Fehler in Projekten und wie du sie vermeidest
23. Juni 2026 9 Min.
Azure RBAC scheitert im Projektalltag selten an der Technik, sondern meist an zu breiten Rollen, falschen Scopes und fehlender Governance.
CRA und Lieferkette: Was Hersteller von ihren Lieferanten fordern müssen
9. Juni 2026 14 Min.
Der Cyber Resilience Act endet nicht an der eigenen Fabrikhalle: Dieser Artikel zeigt, was Hersteller aus Maschinenbau und Industrie von ihren Lieferanten fordern müssen und wie SBOM, Assessments und Vertragsklauseln die Lieferkette absichern.
Mit Dependency-Track aus SBOMs verwertbare Governance machen
2. Juni 2026 9 Min.
Dependency-Track verbindet SBOMs, Vulnerability Intelligence und Policy-Prüfungen zu einer belastbaren Grundlage für Priorisierung, Compliance und Governance in der Software Supply Chain.
CVD-Policy unter dem CRA: So baust du eine echte Vulnerability Disclosure Policy auf
19. Mai 2026 9 Min.
Ab dem 11. September 2026 müssen Hersteller eine CVD-Policy veröffentlichen und eine erreichbare Meldestelle betreiben – dieser Artikel zeigt, wie eine praxistaugliche Vulnerability Disclosure Policy aussieht.
Entra ID PIM: Weniger Dauerechte, mehr Kontrolle
12. Mai 2026 6 Min.
Privileged Identity Management in Entra ID reduziert permanente Administratorrechte und bringt mehr Kontrolle, Transparenz und Sicherheit in den Alltag von IT-Teams.
CRA Meldepflichten: Was Hersteller ab September 2026 melden müssen
28. April 2026 10 Min.
Ab dem 11. September 2026 sind Hersteller verpflichtet, aktiv ausgenutzte Schwachstellen und Sicherheitsvorfälle innerhalb von 24 Stunden an ENISA zu melden – dieser Artikel zeigt, was konkret zu tun ist.