Schwachstellenverfolgung
Verfolgen Sie jede bekannte Schwachstelle in der Software, die Sie ausliefern, vom Build, der sie hereingeholt hat, bis zum Release, das sie behoben hat. CRACI zeichnet die SBOM jedes Builds auf, prüft sie laufend gegen neue Schwachstellendaten und leitet jeden Befund an das Team weiter, das für die Behebung zuständig ist.
Was ist Schwachstellenverfolgung?
Schwachstellenverfolgung ist die fortlaufende Aufzeichnung jeder bekannten Schwachstelle, die Ihre Software betrifft, von der Entdeckung, bis sie behoben oder ausgeschlossen ist. Für jede beantwortet sie vier Fragen: Wo steckt sie, welche Produkte und Releases enthalten sie, wer ist für die Behebung zuständig, und welchen Status hat sie?
Viele Tools beantworten die erste Frage, indem sie nachträglich Manifest- und Lock-Dateien scannen, und überlassen den Rest Tabellen und Tickets. CRACI setzt früher an. Ihre GitHub-Actions-Jobs laufen auf CRACI-Runnern, und während sie laufen, zeichnet CRACI jedes Paket auf, das der Build tatsächlich geladen hat, einschließlich Paketen aus CI-Caches. Diese Build-Time-SBOM überwacht CRACI. Die Schwachstellen, die Sie verfolgen, sind also die im ausgelieferten Artefakt, nicht die aus einem Scan, der irgendwo daneben lief.
Die Software verfolgen, die Sie ausliefern, nicht nur Ihre IT-Assets
Die meisten Tools zur Schwachstellenverfolgung sind für die IT gebaut: Sie scannen Server, Laptops und Cloud-Konten, und der Fix ist ein Patch, den jemand installiert. Software, die Sie bauen und verkaufen, braucht eine andere Aufzeichnung. Der verwundbare Code steckt in Ihrem Release, der Fix ist ein neuer Build, und Kunden wie Behörden fragen, welche Versionen wie lange betroffen waren.
Genau diese Aufzeichnung führt CRACI: die SBOM jedes Builds, die Produkte und Versionen, auf denen er im Einsatz ist, die zugekauften Komponenten Ihrer Lieferanten und den Status jeder Schwachstelle über all das hinweg.
Laufende Neubewertung dessen, was Sie ausgeliefert haben
CRACI zeichnet die SBOM auf, während jeder Build läuft, und bewertet überwachte SBOMs danach laufend neu anhand von Schwachstellendaten. Eine Schwachstelle, die lange nach einem Release veröffentlicht wird, erscheint trotzdem beim betroffenen Release, ohne dass jemand einen Scan erneut ausführt.
Eine Ansicht über Builds und Repositories hinweg
Befunde werden über Builds und Repositories hinweg zusammengeführt, mit Organisationsansichten für den Standard-Branch. Die Inventaransicht zeigt genau, welche Softwareversionen auf welchen Produkten im Einsatz sind, und die Build-Historie zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten. So wissen Sie, welche Produkte wie lange betroffen waren.
Sichtung und Weiterleitung an das zuständige Team
Sicherheitsteams sichten gefundene Schwachstellen und geben sie an die Teams weiter, die für die Behebung zuständig sind, sodass jeder Befund die Menschen erreicht, die handeln können. CRACI unterstützt außerdem VEX, um festzuhalten, wie sich eine Schwachstelle auf Ihr Produkt auswirkt, und Policy-Gates können jeden Build blockieren, der eine bestimmte CVE enthält.
Hersteller-SBOMs neben Ihren eigenen verfolgt
Fügen Sie die SBOMs Ihrer Lieferanten hinzu, und zugekaufte Komponenten werden zusammen mit der Software überwacht, die Sie selbst bauen. Fremdcode in Ihrem Produkt wird am selben Ort verfolgt wie Ihre eigenen Abhängigkeiten.
Vom Befund zur CRA-Meldung
Für den Cyber Resilience Act reicht CRACI die Schwachstellenmeldungen in Ihrem Namen ein: die Frühwarnung, die Meldung und den Abschlussbericht. SBOMs lassen sich als CycloneDX oder SPDX exportieren, mit den in ihren Komponenten gefundenen Schwachstellen, für Audits, Kunden und Ihre eigenen Unterlagen.
Jedes verwundbare Paket und was es hereinzieht
Jeder Build listet seine Pakete mit Version, Package-URL, Lizenz und Schwachstellenstatus und zeigt, ob seine SBOM vollständig ist. Öffnen Sie ein Paket, um seine Sicherheitsmeldungen mit Schweregrad zu sehen und die Pakete, die es benötigen.
Der Lebenszyklus der Schwachstellenverfolgung in CRACI
- Finden. Jeder Build erzeugt eine SBOM mit Vollständigkeitsstatus, exportiert als CycloneDX oder SPDX mit transitiven Abhängigkeiten. Überwachte SBOMs, Ihre eigenen und die Ihrer Lieferanten, werden laufend neu anhand von Schwachstellendaten bewertet.
- Lokalisieren. Organisationsansichten über Builds und Repositories hinweg, die Inventaransicht und die Build-Historie zeigen, welche Produkte und Versionen betroffen sind, und seit wann.
- Priorisieren und sichten. Jede Sicherheitsmeldung zeigt ihren Schweregrad. Sicherheitsteams sichten jeden Befund, mit VEX-Unterstützung, um festzuhalten, wie sich eine Schwachstelle auf Ihr Produkt auswirkt.
- Beheben. Jeder Befund geht an das Team, das für die Behebung zuständig ist, und „Required by“ zeigt, welches Paket eine transitive Schwachstelle hereinzieht. Policy-Gates können eine bestimmte CVE aus späteren Builds heraushalten.
- Prüfen. Die SBOM des nächsten Builds zeigt, ob die verwundbare Version verschwunden ist, sodass die Aufzeichnung bis zum behobenen Release reicht.
- Berichten. CRACI reicht Schwachstellenmeldungen nach dem CRA in Ihrem Namen ein, und SBOMs lassen sich mit den in ihren Komponenten gefundenen Schwachstellen exportieren.
Was Sie zu jeder Schwachstelle festhalten sollten
- Schwachstelle
- Die Sicherheitsmeldung und ihre IDs (CVE, GHSA und weitere), mit Schweregrad.
- Komponente
- Das Paket und die genaue Version, und ob es eine direkte oder transitive Abhängigkeit ist.
- Pfad
- Die Pakete, die das verwundbare Paket hereinziehen. Daran sehen Sie, was Sie aktualisieren müssen.
- Exposition
- Welche Produkte, Releases und Builds es enthalten, und seit wann.
- Verantwortlich
- Das Team, das für die Behebung zuständig ist.
- Status
- Offen, in Untersuchung, nicht betroffen oder behoben, idealerweise als VEX festgehalten.
- Nachweis
- Der Build oder das Release, der bzw. das die verwundbare Version nicht mehr enthält.
Kennzahlen, die zeigen, ob die Verfolgung funktioniert
Sicherheitsteams berichten meist über vier Zahlen:
- Mittlere Behebungszeit (MTTR): wie lange es von der Entdeckung einer Schwachstelle bis zu einem Release ohne sie dauert.
- Einhaltung der Behebungsfristen: der Anteil der Schwachstellen, die innerhalb der Frist behoben werden, die Ihre Richtlinie für ihren Schweregrad vorgibt.
- Entwicklung des Rückstands: ob die Zahl offener Schwachstellen steigt oder sinkt.
- Expositionszeitraum: wie lange jedes Produkt eine verwundbare Version ausgeliefert hat. Die Build-Historie von CRACI zeigt, welche Builds eine verwundbare Abhängigkeit enthielten, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren.
Was CRACI heute nicht kann
CRACI bietet keine Erreichbarkeitsanalyse und ordnet Befunde deshalb nicht danach, ob Ihr Code die verwundbare Funktion aufruft. Es zeigt keine Behebungskennzahlen wie MTTR, Fristeneinhaltung oder die Entwicklung des Rückstands. Warnungen bei einem Schweregrad-Schwellenwert gibt es heute nicht; die Warnmeldungen decken Verstöße gegen Egress-Richtlinien ab. Kommentare zu Befunden, ein Vergleich zwischen Releases, Schwellenwert-Warnungen und Schwachstellen-Webhooks sind auf der Roadmap.
VEX: welche Schwachstellen Ihr Produkt tatsächlich betreffen
Eine verwundbare Komponente in Ihrer SBOM bedeutet nicht immer ein verwundbares Produkt. Der betroffene Code ist vielleicht gar nicht Teil dessen, was Sie ausliefern, oder nicht so erreichbar, wie ein Angriff es bräuchte. VEX (Vulnerability Exploitability eXchange) ist ein maschinenlesbarer Weg, genau das festzuhalten: Jede VEX-Aussage verknüpft ein Produkt, eine Schwachstelle und einen Status. Die Standardstatus sind not affected, affected, fixed und under investigation.
Das wird wichtig, sobald Kunden und Behörden Ihre SBOMs mit Schwachstellendatenbanken abgleichen. Ohne VEX-Aussage sieht jeder Treffer wie ein offenes Problem aus, und Ihr Team erklärt immer wieder dieselben Fehlalarme. CRACI unterstützt VEX, um festzuhalten, wie sich eine Schwachstelle auf Ihr Produkt auswirkt, zusammen mit der Sichtung, die jeden Befund an das Team weitergibt, das für die Behebung zuständig ist.
Neugierig, wie viel es zu verfolgen gibt? Sehen Sie, wie viele CVEs jeden Tag veröffentlicht werden und wie stark die Zahl der Schwachstellen mit Schweregrad High und Critical gewachsen ist.
Schwachstellenverfolgung erklärt
Häufige Fragen zur Verfolgung von Schwachstellen in Software, die Sie bauen und zukaufen
Was ist Schwachstellenverfolgung?
Schwachstellenverfolgung ist die fortlaufende Aufzeichnung jeder bekannten Schwachstelle, die Ihre Software betrifft, von ihrer Entdeckung, bis sie behoben oder ausgeschlossen ist: in welcher Komponente und Version sie steckt, welche Produkte und Releases sie enthalten, wer für die Behebung zuständig ist und welchen Status sie hat. Bei Software, die Sie ausliefern, beginnt sie mit einer genauen Liste der Komponenten, und genau die liefert eine SBOM.
Was sind die Schritte des Schwachstellenmanagements?
Der übliche Zyklus hat fünf Schritte: die Schwachstellen in dem finden, was Sie betreiben oder ausliefern, sie priorisieren, sie beheben, prüfen, dass der Fix sie entfernt hat, und berichten. Die Verfolgung verbindet die Schritte, damit ein Befund zwischen Entdeckung und behobenem Release nicht verloren geht. In CRACI bestehen die Schritte darin, die Build-Time-SBOM aufzuzeichnen, jeden Befund zu sichten, ihn an das zuständige Team weiterzuleiten, zu bestätigen, dass ein späterer Build die verwundbare Version nicht mehr enthält, und über SBOM-Exporte und CRA-Meldungen zu berichten.
Wie verfolgt man die Behebung von Schwachstellen?
Geben Sie jeder Schwachstelle eine verantwortliche Person und einen Status, und schließen Sie sie erst, wenn ein Build oder Release die verwundbare Version nicht mehr enthält. Messen Sie, wie lange Fixes dauern, ob sie Ihre Fristen einhalten und ob der offene Rückstand schrumpft. In CRACI zeigt die SBOM jedes Builds, ob die verwundbare Version noch enthalten ist, und ein Policy-Gate kann eine bestimmte CVE aus späteren Builds heraushalten.
Was ist SBOM-basiertes Schwachstellenmanagement?
SBOM-basiertes Schwachstellenmanagement bedeutet, die in Ihren Software-Stücklisten aufgeführten Komponenten mit Schwachstellendaten abzugleichen, und das immer wieder, sobald neue Schwachstellen veröffentlicht werden. Das Ergebnis ist nur so gut wie die SBOM. CRACI zeichnet die SBOM auf, während der Build läuft, sodass die Liste wiedergibt, was der Build tatsächlich geladen hat, einschließlich Paketen aus CI-Caches.
Worin unterscheidet sich Schwachstellenverfolgung vom Schwachstellenscan?
Ein Scan ist eine Momentaufnahme: Er liest Dateien, meldet Befunde und hört auf. Die Verfolgung hält Befunde, Verantwortliche und Status über die Zeit fest und prüft ausgelieferte Software weiter, sobald neue Schwachstellen auftauchen. CRACI ist ein Rekorder, kein Scanner: Es zeichnet jeden Build auf und bewertet die überwachten SBOMs dann laufend neu.
Verfolgt CRACI Schwachstellen in Software von Drittanbietern?
Ja. Sie können Hersteller-SBOMs hinzufügen, und diese zugekauften Komponenten werden zusammen mit der Software überwacht, die Sie auf CRACI bauen.
Kann CRACI einen Build blockieren, der eine bekannte Schwachstelle enthält?
Ja. Policy-Gates können einen Build aufgrund von Befunden blockieren, auch jeden Build, der eine bestimmte CVE enthält. So kehrt eine Schwachstelle, die Sie behoben haben, nicht in einem späteren Build zurück.
Wie benachrichtigt mich CRACI über Schwachstellen?
Befunde erscheinen in den Organisationsansichten von CRACI, wo Sicherheitsteams sie sichten und an die zuständigen Teams weitergeben. Warnmeldungen decken heute Verstöße gegen Egress-Richtlinien ab. Schwellenwert-Warnungen und Schwachstellen-Webhooks sind auf der Roadmap, ebenso Warnungen in Slack und Teams.
Hilft CRACI bei der Schwachstellenmeldung nach dem CRA?
Ja. CRACI reicht die Schwachstellenmeldungen nach dem CRA in Ihrem Namen ein: die Frühwarnung, die Meldung und den Abschlussbericht. Die Erfüllung des Cyber Resilience Act bleibt der Prozess des Herstellers; CRACI automatisiert einen wesentlichen Teil der Transparenz über die Lieferkette und der Nachweise, die dieser Prozess braucht.
Unterstützt CRACI VEX?
Ja. CRACI unterstützt VEX (Vulnerability Exploitability eXchange), um festzuhalten, wie sich eine bekannte Schwachstelle auf Ihr Produkt auswirkt, zusammen mit der Sichtung und Weiterleitung an das Team, das für die Behebung zuständig ist. Eine VEX-Aussage teilt Kunden und Behörden mit, ob eine in Ihrer SBOM gefundene Schwachstelle das Produkt tatsächlich betrifft, damit sie keinen Fehlalarmen nachjagen. Buchen Sie eine Demo und sehen Sie, wie es in Ihren Sichtungsprozess passt.
Führt CRACI eine Erreichbarkeitsanalyse durch?
Nein. CRACI bietet keine Erreichbarkeitsanalyse (Reachability-Analyse). Es zeigt, welche Ihrer Builds, Repositories und Produkte eine verwundbare Komponente enthalten, und unterstützt VEX, um festzuhalten, wie sich eine Schwachstelle auf Ihr Produkt auswirkt.
Sehen Sie die Schwachstellenverfolgung an Ihren eigenen Builds
Buchen Sie eine Demo, und wir zeigen Ihnen, welche Schwachstellen in die Software gelangen, die Sie ausliefern, und wer für jeden Fix zuständig ist
Demo buchen