Neue CVE veröffentlicht – sind Sie betroffen?
Dienstagmorgen, 8:30 Uhr: In einer weit verbreiteten Bibliothek wird eine kritische Sicherheitslücke veröffentlicht. Kurz darauf fragt ein Kunde, ob Ihre Software betroffen ist. Und die ehrliche Antwort lautet in vielen Unternehmen: „Wir schauen nach und melden uns.“
Aus „wir schauen nach“ werden dann schnell Tage. Teams durchsuchen Repositories, prüfen Lockfiles von Hand, fragen bei Kollegen nach, welche Version beim Kunden X läuft, und hoffen, dass niemand ein altes Container-Image vergessen hat. Dieser Beitrag zeigt, warum die Frage so schwer zu beantworten ist und wie Sie sie mit Secupipe in Minuten beantworten, weil die Prüfung schon beim Build beginnt.
Warum die Frage so schwer zu beantworten ist
- Transitive Abhängigkeiten: Die betroffene Bibliothek steht selten direkt in Ihrer
package.jsonodergo.mod. Sie kommt über eine Abhängigkeit einer Abhängigkeit ins Produkt. - Container und Basis-Images: Neben Ihrem Code liefern Sie ein Betriebssystem-Image mit Dutzenden Paketen aus, die niemand im Team bewusst ausgewählt hat.
- Viele Versionen im Feld: Beim Kunden läuft nicht der aktuelle Stand von
main, sondern ein Release von vor acht Monaten. Entscheidend ist, was ausgeliefert wurde, nicht was heute im Repository steht. - Die Lücke kommt nach dem Release: Eine Komponente, die beim Build sauber war, kann morgen eine kritische CVE haben. Eine einmalige Prüfung reicht deshalb nicht.
Wie teuer das werden kann, hat Log4Shell (CVE-2021-44228) im Dezember 2021 gezeigt: Viele Unternehmen haben Wochen gebraucht, um überhaupt herauszufinden, wo Log4j überall steckt. Die Hintertür in xz Utils (CVE-2024-3094) im März 2024 stellte dieselbe Frage erneut, diesmal für Linux-Pakete in Container-Images.
Warum es jetzt auch regulatorisch eilt
Seit dem 11. September 2026 gilt die Meldepflicht des Cyber Resilience Act: Aktiv ausgenutzte Schwachstellen in Ihren Produkten müssen innerhalb von 24 Stunden gemeldet werden. Die Frist läuft ab Kenntnis, also müssen Sie schnell wissen, ob Sie betroffen sind. Details stehen in unserem Beitrag CRA-Meldepflicht gilt seit 11. September 2026. Auch NIS2 verlangt, Risiken in der Lieferkette zu kennen und zu steuern.
Die Lösung: prüfen beim Build und danach laufend
1 · Pipeline baut Artefakte→2 · Secupipe prüft jedes Artefakt→3 · Alarm bei jeder neuen Lücke
1. Beim Build: jedes Artefakt wird erfasst und geprüft
Ihre CI/CD-Pipeline baut wie gewohnt Ihre Artefakte, etwa die Anwendung und das Container-Image. Direkt danach erzeugt ein Schritt eine Stückliste (SBOM) aller enthaltenen Komponenten und sendet sie an Secupipe, zusammen mit Commit, Branch und Link zum Pipeline-Lauf. Secupipe prüft sofort, und ein Freigabe-Gate lässt den Build fehlschlagen, wenn offene kritische Schwachstellen vorliegen. So gelangt eine bekannte Lücke gar nicht erst in die Auslieferung.
2. Secupipe prüft die Artefakte
Jede SBOM landet mit ihrer Herkunft in Secupipe: welches Artefakt, welche Version, welcher Commit, welcher Pipeline-Lauf. Secupipe gleicht alle Komponenten mit den Schwachstellendatenbanken OSV, der Ausnutzungswahrscheinlichkeit EPSS und dem KEV-Katalog der CISA ab. Zusätzlich sehen Sie, ob die SBOM vollständig ist, gemessen an der Technischen Richtlinie BSI TR-03183.
3. Danach: laufend neu prüfen und Alarm schlagen
Hier liegt der eigentliche Unterschied. Secupipe prüft nicht nur einmal beim Build, sondern gleicht alle gespeicherten SBOMs regelmäßig neu ab: im Free-Plan alle 6 Stunden, im Team-Plan alle 3 Stunden, in Enterprise laufend. Wird eine neue CVE veröffentlicht, die eine Ihrer Komponenten betrifft, meldet Secupipe sich, ohne dass jemand danach suchen muss: in Slack, Microsoft Teams, Mattermost, Discord, Matrix, Telegram, per Webhook oder direkt als Jira-Ticket.
Die Antwort auf „Sind wir betroffen?“
Wenn das nächste Mal eine neue CVE die Runde macht, geben Sie die Kennung in die Suche von Secupipe ein und sehen sofort:
- welche Artefakte die betroffene Komponente enthalten,
- in welcher Version und aus welchem Commit und Pipeline-Lauf sie stammen,
- wie wahrscheinlich eine Ausnutzung ist (EPSS) und ob sie bereits aktiv ausgenutzt wird (KEV).
Aus „wir melden uns“ wird eine Antwort in Minuten, mit Beleg. Und weil jeder Schritt protokolliert ist, können Sie später auch nachweisen, wann Sie Kenntnis hatten und wie Sie reagiert haben.
So starten Sie
- Kostenloses Konto anlegen und unter Pipelines ein Token erzeugen.
- In Ihrer Pipeline nach dem Build eine SBOM erzeugen, zum Beispiel mit Syft für Container oder den CycloneDX-Werkzeugen für npm und Go, und an Secupipe senden.
- Unter Integrationen festlegen, wohin Alarme gehen sollen.
Ein Projekt mit einer Pipeline ist dauerhaft kostenlos. Wenn es schnell gehen soll, binden wir mit dem Installationspaket bis zu fünf Pipelines für Sie an.