Heartbleed in OpenSSL
Eine Lücke in einer Bibliothek, die in Millionen Produkten steckte. Überall dieselbe Frage: Wo genau setzen wir OpenSSL ein, in welcher Version und in welchen ausgelieferten Releases?
Cyber Resilience Act · Stufe 1
Ihre SBOMs. Zehn Jahre. Durchsuchbar.
Eine Schwachstelle wird aktiv ausgenutzt. Ab Kenntnis bleiben höchstens 24 Stunden für die Frühwarnung. Wissen Sie sofort, welche ausgelieferten Releases die betroffene Komponente enthalten?
Produktakte archiviert die SBOMs all Ihrer Releases, macht sie durchsuchbar und vergleichbar. Damit Sie bei der nächsten Jackson-, Log4j- oder XZ-Meldung nicht raten, sondern nachschlagen.
Zeitachse
Zwölf Jahre dieselbe Frage. Und zwei Fristen, die daraus eine Pflicht machen.
Bernstein: die Tage, an denen tausende Teams wissen mussten, wo eine Library steckt. Blau: die Termine, ab denen der CRA dafür eine dokumentierte Antwort verlangt.
Apache Struts: Patch da, Einsatz unbekannt
Der Patch war im März verfügbar. Sechs Monate später wurde bekannt, dass die Lücke bei Equifax offen geblieben war. Nicht aus Böswilligkeit. Es fehlte das Wissen, wo Struts überhaupt lief.
Log4Shell: das Wochenende der Handarbeit
Die halbe Branche durchsuchte ihre Abhängigkeiten manuell, weil transitiv niemand wusste, wo Log4j steckt. Genau der Fall, den wir selbst erlebt haben.
Spring4Shell: dieselbe Übung, vier Monate später
Wer nach Log4Shell ein durchsuchbares Archiv aufgebaut hatte, war in Minuten fertig. Alle anderen schrieben wieder Rundmails an alle Teams.
XZ Utils: Hintertür statt Fehler
Über zwei Jahre eingeschleust. Ohne SBOM-Historie pro Release lässt sich nicht beantworten, welche Auslieferung die manipulierte Version enthielt. Genau das fragt danach jeder Kunde.
Der Cyber Resilience Act ist in Kraft
Die Verordnung (EU) 2024/2847 gilt seit dem 10.12.2024. Die Pflichten greifen gestaffelt. Die Vorbereitungszeit war eingeplant, nicht geschenkt.
Konformitätsbewertungsstellen können notifiziert werden
Ab hier steht die Infrastruktur für Konformitätsbewertungen. Für Hersteller vor allem ein Signal: Der Zeitplan ist keine Theorie mehr.
Meldepflicht für aktiv ausgenutzte Schwachstellen
Erstmeldung binnen 24 Stunden an BSI-CSIRT und ENISA, detaillierte Meldung nach 72 Stunden, danach Abschlussbericht. Das gilt auch für Produkte, die längst auf dem Markt sind. Dafür müssen Sie in Minuten wissen, welche Releases betroffen sind.
Heute: Die Uhr läuft
Seit heute greift die Meldepflicht: aktiv ausgenutzte Schwachstellen binnen 24 Stunden an BSI-CSIRT und ENISA melden. Bis dahin gehört ein Meldeprozess aufgesetzt und geprobt. In 433 Tagen folgt die volle Geltung. Dann gilt: SBOM in maschinenlesbarem Format pro Release, mindestens zehn Jahre aufbewahrt. Wer jetzt die SBOM-Erzeugung in den Build integriert und die Historie pro Release archiviert, erfüllt beides ohne Endspurt.
SBOM-Pflicht und zehn Jahre Aufbewahrung
Wer Software in der EU in Verkehr bringt, braucht eine SBOM in maschinenlesbarem Format als Teil der technischen Dokumentation. Sie muss mindestens zehn Jahre aufbewahrt werden, bei längerem Supportzeitraum entsprechend länger.
9 / 10
20112012201320142015201620172018201920202021202220232024202520262027202820292030
Der Fall
Ein Freitagnachmittag, eine Schwachstelle, hundert Microservices
Eine Schwachstelle in einer verbreiteten Programmierbibliothek wird bekannt. Im Unternehmen laufen über hundert Microservices, viele nutzen die Library, manche direkt, manche über transitive Abhängigkeiten, ohne dass es jemand weiß.
Alle Entwickler werden angeschrieben. Dann noch einmal von der Security-Abteilung. Dann vom Vorgesetzten. Jedes Team prüft von Hand. Einer beantragt eine pauschale Ausnahme, „betrifft uns nicht direkt“, und übersieht, dass ein Feature einer ganz anderen Library die verwundbare Version unter der Haube zieht.
Gebraucht hätte es eine einzige Suche: Welche Services enthalten die Library, in welcher Version, in welchen Releases, auch in denen, die noch beim Kunden laufen? Wer muss handeln, und wer kann in Ruhe weiterarbeiten?
Was Produktakte kann
Ein Archiv, das Fragen beantwortet und nicht nur Dateien aufbewahrt.
Eine Library, eine Suche, alle Treffer über sämtliche Produkte und Releases, inklusive transitiver Abhängigkeiten.
Betroffenheitssuche
118 Services · 4.812 SBOMslibrary: com.fasterxml.jackson.core:jackson-databind version: < 2.15.0
payment-api
v4.2.0 – v4.7.1 · 2.14.2 · transitiv über spring-boot-starter-web
legacy-portal
v1.3.4 · 2.13.0 · beim Kunden, seit 2023 nicht aktualisiert
billing-worker
v2.9.0 · 2.15.3 · direkte Abhängigkeit
Und das Gedächtnis, das Ihr Scanner nicht hat
Wir scannen nicht selbst und ersetzen Ihren Scanner nicht. Wir stehen daneben und erinnern uns.
Unbegrenzte Historie
Jede SBOM jedes Releases bleibt erhalten und abrufbar. Ihr Scanner zeigt nur den neuesten Report? Oder lässt er Sie mit gerade einmal zwanzig zurück? Wir zeigen alle: zehn Jahre und länger, wie es der CRA verlangt.
Audit-Modus
Der Auditor fragt, Sie zeigen. Nachweis über Betroffenheit oder Nicht-Betroffenheit für jeden Zeitpunkt, exportierbar für den Bericht.
Automatische Einlieferung
SBOMs aus Ihrer CI/CD-Pipeline landen automatisch direkt im Archiv, pro Build und Release, ohne Handarbeit. Oder manuell hochladen, wenn Ihnen das lieber ist.
Software allein löst kein Compliance-Problem
Der Auditor will nicht nur ein Tool sehen, sondern einen beschriebenen Prozess: Wer erfasst eine Schwachstelle, wer bewertet sie, in welcher Frist wird sie behoben, wo steht das? Wir haben diese Prozesse in einem Konzernumfeld selbst aufgebaut und auditieren lassen. Das geben wir weiter.
Beratung
Bestandsaufnahme Ihrer SBOM- und Schwachstellenprozesse, konkrete Schritte zur CRA-Readiness.
Vor Ort oder remoteWorkshops
Ein Tag mit Ihrem Team: SBOM erzeugen, verwalten, im Incident-Fall damit arbeiten. Anhand Ihrer eigenen Software, nicht anhand von Folien.
1 Tag · Ihr CodeWebinare
Der kompakte Einstieg: Was verlangt der CRA ab wann und was heißt das für Ihre Produkte? Gut für den Überblick, bevor Sie Budget anfassen.
60 Minuten · onlineAus der Praxis, aus Deutschland
Wir sind Softwareentwickler, die das Problem nicht aus Whitepapers kennen, sondern aus Incident-Calls und Audits. Wir sitzen in Deutschland, kennen die EU-Verordnung und die deutsche Auslegung durch das BSI, und Sie erreichen uns ohne Ticketsystem in Ihrer Sprache.
Klare Empfehlungen statt vager Aussagen und endloser Beratung.
Philip Marienfeld, Geschäftsführer
Dipl. Inf. (FH)
Bringen Sie eine SBOM mit, wir suchen gemeinsam.
Ein Termin, Ihre echten Daten, keine Folienshow. Danach wissen Sie, ob das Archiv Ihr Problem löst.
Termin anfragenSchildern Sie uns in zwei Sätzen, wo Sie stehen.
Kein Sales-Call mit Skript. Wir schauen auf Ihren Stand und sagen, was als Nächstes sinnvoll ist.
E-Mailkontakt@produktakte.de
Rückruf
Lieber telefonieren? Nennen Sie im Formular ein Zeitfenster, wir rufen zurück.
Häufige Fragen
Was hier nicht steht, beantworten wir per E-Mail, meist am selben Tag.
Was ist eine SBOM und wer braucht sie?
Eine Software Bill of Materials ist das Inhaltsverzeichnis Ihrer Software: alle Komponenten und Abhängigkeiten mit Version und Herkunft, maschinenlesbar in CycloneDX oder SPDX. Ab voller Geltung des CRA braucht sie jeder, der Software oder Produkte mit Software in der EU in Verkehr bringt, auch als Zulieferer.
Ab wann gilt der Cyber Resilience Act?
In zwei Stufen: Ab dem 11.09.2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen (Erstmeldung binnen 24 Stunden, Detailmeldung binnen 72 Stunden, danach Abschlussbericht). Ab dem 11.12.2027 gelten die vollständigen Anforderungen einschließlich einer SBOM als Teil der technischen Dokumentation und einer Aufbewahrungsfrist von zehn Jahren.
Muss ich meine SBOM veröffentlichen?
Nein. Die SBOM ist Teil Ihrer technischen Dokumentation und muss den Marktüberwachungsbehörden auf Verlangen vorgelegt werden. Eine Veröffentlichung verlangt der CRA nicht. Dass Kunden sie vertraglich verlangen, ist eine andere Frage.
Reicht mein Scanner (Nexus IQ, Dependency-Track o. Ä.) nicht aus?
Für die Gegenwart oft ja. Scanner bewerten, was heute im Build liegt, und halten meist nur eine begrenzte Zahl älterer Reports. Die CRA-Fragen sind aber Fragen an die Vergangenheit: Welches Release enthielt was, seit wann, auch transitiv? Wir ergänzen Ihren Scanner um dieses Gedächtnis, wir ersetzen ihn nicht.
Wir bekommen Software von Dienstleistern. Wessen Problem ist die SBOM?
Ihres. Und das Ihres Dienstleisters. Wer das Produkt in Verkehr bringt, haftet für die Dokumentation. Das gilt auch für die zugelieferten Teile. Praktisch heißt das: SBOM-Lieferung in den Vertrag, Format und Zeitpunkt festlegen, Eingang archivieren. Bei der Formulierung helfen wir.
Was ist eine SBOM und wer braucht sie?
Eine Software Bill of Materials ist das Inhaltsverzeichnis Ihrer Software: alle Komponenten und Abhängigkeiten mit Version und Herkunft, maschinenlesbar in CycloneDX oder SPDX. Ab voller Geltung des CRA braucht sie jeder, der Software oder Produkte mit Software in der EU in Verkehr bringt, auch als Zulieferer.
Ab wann gilt der Cyber Resilience Act?
In zwei Stufen: Ab dem 11.09.2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen (Erstmeldung binnen 24 Stunden, Detailmeldung binnen 72 Stunden, danach Abschlussbericht). Ab dem 11.12.2027 gelten die vollständigen Anforderungen einschließlich einer SBOM als Teil der technischen Dokumentation und einer Aufbewahrungsfrist von zehn Jahren.
Muss ich meine SBOM veröffentlichen?
Nein. Die SBOM ist Teil Ihrer technischen Dokumentation und muss den Marktüberwachungsbehörden auf Verlangen vorgelegt werden. Eine Veröffentlichung verlangt der CRA nicht. Dass Kunden sie vertraglich verlangen, ist eine andere Frage.
Reicht mein Scanner (Nexus IQ, Dependency-Track o. Ä.) nicht aus?
Für die Gegenwart oft ja. Scanner bewerten, was heute im Build liegt, und halten meist nur eine begrenzte Zahl älterer Reports. Die CRA-Fragen sind aber Fragen an die Vergangenheit: Welches Release enthielt was, seit wann, auch transitiv? Wir ergänzen Ihren Scanner um dieses Gedächtnis, wir ersetzen ihn nicht.
Wir bekommen Software von Dienstleistern. Wessen Problem ist die SBOM?
Ihres. Und das Ihres Dienstleisters. Wer das Produkt in Verkehr bringt, haftet für die Dokumentation. Das gilt auch für die zugelieferten Teile. Praktisch heißt das: SBOM-Lieferung in den Vertrag, Format und Zeitpunkt festlegen, Eingang archivieren. Bei der Formulierung helfen wir.