CRACI für PSIRT-Teams und Produktsicherheitsverantwortliche

Das Problem eines PSIRT-Managers

Die Leitung der Produktsicherheit verantwortet Antworten, die das PSIRT nicht allein liefern kann. Wenn eine CVE in einer weit verbreiteten Bibliothek auftaucht, stellen Kunden, Führungskräfte und zunehmend auch Behörden innerhalb von Stunden dieselben Fragen: Sind wir betroffen, in welchen Produkten und Versionen, seit wann, und wann ist es behoben?

Die Antworten hängen vom Inventar ab, und das Inventar stammt meist von Scannern, die Lockfiles oder Manifeste nachträglich lesen. Sie listen Entwicklungsabhängigkeiten auf, die nie ausgeliefert werden, und übersehen Pakete, die der Build auf anderem Weg heruntergeladen hat. Also bittet das PSIRT die Entwicklungsteams um eine Prüfung von Hand, und die Antwort kommt nach Tagen, mit Vorbehalten.

Das FIRST PSIRT Services Framework bezeichnet ein Inventar der Produktkomponenten als unverzichtbar, um bei geerbten Schwachstellen die betroffenen Produkte schnell zu identifizieren. Bei diesem Inventar setzt CRACI an. Das Gesamtbild der Rolle finden Sie unter Was ist ein PSIRT.

Was CRACI einem PSIRT gibt

Ein aus dem Build aufgezeichnetes Inventar

CRACI führt Ihre GitHub-Actions-Builds auf eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus CI-Caches wiederhergestellter Pakete und Abhängigkeiten, die in keinem Lockfile stehen. Es ist ein Rekorder, kein Scanner. Jede SBOM trägt einen Vollständigkeitsstatus, eine teilweise Aufzeichnung ist also als teilweise gekennzeichnet, und SBOMs lassen sich als CycloneDX oder SPDX exportieren.

Kontinuierliche Überwachung des Ausgelieferten

Überwachte SBOMs werden laufend neu bewertet, sobald neue Schwachstellen veröffentlicht werden, und Befunde werden über Builds und Repositories hinweg zusammengeführt. Eine CVE, die nächsten Monat veröffentlicht wird, wird mit den bereits ausgelieferten Releases abgeglichen, nicht nur mit dem nächsten Build. Bekannte bösartige Releases mit veröffentlichter CVE werden wie jede andere Schwachstelle gekennzeichnet.

Betroffene Produkte, Versionen und Zeiträume

Die Build-Historie zeigt jeden früheren Build mit seiner SBOM und welche Builds eine verwundbare Abhängigkeit enthielten, direkt oder transitiv. So kennen Sie innerhalb Ihrer Aufbewahrungsfrist den Zeitraum, in dem Sie betroffen waren. Die Inventaransicht zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind. Zusammen machen sie aus „Sind wir betroffen?“ eine einfache Abfrage.

Zugekaufte Komponenten

Produkte bestehen selten nur aus Ihrem eigenen Code. Hersteller-SBOMs lassen sich hinzufügen, sodass Komponenten von Drittanbietern zusammen mit Ihren eigenen Builds überwacht werden.

Triage, Weiterleitung und VEX

Sicherheitsteams sichten entdeckte Schwachstellen und leiten sie an die Teams weiter, die für den Fix zuständig sind. Das entspricht dem verteilten PSIRT-Modell, in dem Produktteams die Behebung übernehmen. CRACI unterstützt VEX. Unter VEX lesen Sie, wie Aussagen zu „nicht betroffen“ einem PSIRT und seinen Kunden Arbeit ersparen.

Eine behobene CVE aus späteren Builds heraushalten

Policy-Gates können einen Build aufgrund von Befunden blockieren, auch Builds, die eine bestimmte CVE enthalten. Nach Abschluss eines PSIRT-Falls verhindert ein Gate für diese CVE, dass die verwundbare Version in einem späteren Release unbemerkt zurückkehrt.

Nachweise für Audits und Kunden

Die API liefert SBOMs, Netzwerk-Traces und Provenienz für jeden Build. Die Aufzeichnung hinter einem Advisory oder einer Audit-Antwort ist also auch außerhalb der Oberfläche verfügbar. Wo der EU Cyber Resilience Act gilt, reicht CRACI außerdem die erforderlichen Meldungen im Namen des Herstellers bei den Behörden ein; die Pflicht bleibt beim Hersteller. Siehe Was ist der CRA.

Wo CRACI im PSIRT-Prozess ansetzt

PSIRT-Phase	Was CRACI beiträgt
Vorbereitung	Eine SBOM pro Build, während der Ausführung aufgezeichnet, mit Vollständigkeitsstatus
Entdeckung	Laufende Neubewertung überwachter SBOMs, einschließlich Hersteller-SBOMs
Verifizierung	Welche Builds, Versionen und Produkte die Komponente enthalten, und seit wann
Behebung	Triage an das zuständige Team; Policy-Gates, die die CVE aus späteren Builds heraushalten
Release und Offenlegung	VEX-Unterstützung; SBOM-Export; API-Zugriff auf die Build-Aufzeichnung

Die Phasen folgen dem Lebenszyklus des Schwachstellenmanagements.

Was CRACI nicht tut

• Erreichbarkeitsanalyse. CRACI zeigt, dass ein verwundbares Paket im Build war, nicht, ob Ihr Code die verwundbare Funktion aufruft.
• Quellcode-Scanning. SAST und Secrets-Scanning gehören nicht zum Umfang; dafür gibt es viele gute Tools, die neben CRACI arbeiten.
• Andere CI-Systeme als GitHub Actions. Heute GitHub Actions; weitere CI-Systeme sind auf der Roadmap.
• Compliance in Ihrem Auftrag. CRACI liefert die Nachweise; NIS2, den CRA oder jedes andere Framework zu erfüllen, bleibt ein Prozess Ihrer Organisation.

CRACI für PSIRT-Teams: häufig gestellte Fragen

Ist CRACI ein PSIRT-Tool?

CRACI deckt den Teil der PSIRT-Arbeit ab, der davon abhängt, zu wissen, was Sie ausliefern: Build-SBOMs, ihre kontinuierliche Überwachung, welche Builds und Produkte eine verwundbare Komponente enthalten, und die Triage an das zuständige Team. Ihr Offenlegungskanal und Ihr Advisory-Prozess bauen auf dieser Aufzeichnung auf.

Woher weiß CRACI, was in einem Produkt steckt?

Builds laufen auf den GitHub-Actions-Runnern von CRACI, und CRACI zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus CI-Caches wiederhergestellter Pakete und Abhängigkeiten, die in keinem Lockfile stehen. Es ist ein Rekorder, kein Scanner. Jede SBOM trägt einen Vollständigkeitsstatus, Sie wissen also, wann die Aufzeichnung unvollständig ist.

Kann CRACI uns sagen, welche früheren Releases von einer CVE betroffen waren?

Ja, innerhalb Ihrer Aufbewahrungsfrist. Die Build-Historie zeigt jeden früheren Build mit seiner SBOM und welche Builds eine verwundbare Abhängigkeit enthielten, direkt oder transitiv. So kennen Sie den Zeitraum, in dem Sie betroffen waren. Die Inventaransicht zeigt, welche Softwareversionen in welchen Produkten im Einsatz sind.

Deckt CRACI Komponenten ab, die wir von Lieferanten kaufen?

Sie können Hersteller-SBOMs hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren eigenen Builds überwacht werden.

Unterstützt CRACI VEX?

Ja. CRACI unterstützt VEX, um festzuhalten, wie eine bekannte Schwachstelle Ihr Produkt betrifft. Die Status und Formate finden Sie unter VEX, und wie Advisories sie transportieren, unter CSAF.

Welche CI-Systeme unterstützt CRACI?

Heute GitHub Actions. Weitere CI-Systeme sind auf der Roadmap.