CSAF-Advisory-Hosting

Wenn Sie in Resilic einen Sicherheitshinweis freigeben, können wir ihn als CSAF-2.0-Provider auf einer von Ihnen kontrollierten Domain veröffentlichen — ein maschinenlesbarer Feed, den Schwachstellen-Tools, nachgelagerte Integratoren und nationale Datenbanken automatisch abrufen können.

Was das ist — und was nicht. CSAF (Common Security Advisory Framework) ist ein Interoperabilitätsformat, keine gesetzliche Pflicht. Der CRA schreibt weder CSAF, einen „Provider”, Custom-Domain-Hosting, ROLIE noch einen bestimmten Discovery-Weg namentlich vor. Der CRA erwartet, dass Sie Nutzer über Schwachstellen und Behebungen informieren können (Anhang II Ziffer 2 sowie die Pflicht zur koordinierten Schwachstellenoffenlegung). Einen CSAF-Feed zu veröffentlichen ist ein sauberer, breit unterstützter Weg dorthin — er macht Ihre Hinweise skalierbar konsumierbar —, aber es ist eine Entscheidung über Bereitschaft und Interoperabilität, keine Konformitätsfeststellung. Resilic entwirft und strukturiert den Feed; Sie geben jeden Hinweis vor der Veröffentlichung frei.

Die Hosting-Domain

Ihre Hinweise werden auf einem Host unter einer Ihnen gehörenden Domain ausgeliefert — csaf.<ihre-domain> — mit eigenem verwaltetem HTTPS-Zertifikat. Die Domain begründet zugleich Ihren Herausgeber-Namespace, die stabile Kennung, die sagt „diese Hinweise kommen von uns”. Identität und Auslieferung sind bewusst getrennt: der Namespace ist Ihre Apex-Domain (https://<ihre-domain>), während das Bundle von https://csaf.<ihre-domain> ausgeliefert wird.

Die Einrichtung erfolgt in drei Schritten: registrieren → verifizieren → ausliefern.

1. Registrieren

Geben Sie unter Sicherheitshinweise → CSAF-Hosting-Domain die Domain ein, unter der Sie veröffentlichen möchten (zum Beispiel acme.example). Resilic stellt ein einmaliges Verifizierungs-Token aus und zeigt Ihnen die hinzuzufügenden DNS-Einträge.

2. Verifizieren — belegen Sie die Kontrolle über die Domain

Die Kontrolle belegen Sie per DNS. Zwei Einträge sind beteiligt, und sie haben unterschiedliche Aufgaben — die App kennzeichnet, welcher welcher ist:

• CNAME (Auslieferung) — csaf.<ihre-domain> → das von Resilic angezeigte Hosting-Ziel. Dieser ist erforderlich für die Veröffentlichung über HTTPS: er delegiert den Auslieferungs-Host an uns, damit das Zertifikat ausgestellt werden kann und Ihre Hinweise tatsächlich erreichbar sind.
• TXT (Nachweis) — _aegis-csaf.<ihre-domain> → das Verifizierungs-Token. Dies ist der Kontrollnachweis. Er ist optional, sobald der CNAME gesetzt ist — der delegierende CNAME belegt die Kontrolle über den Host bereits —, Sie können ihn aber stattdessen nutzen, wenn Sie den CNAME nicht sofort hinzufügen möchten.

Fügen Sie die Einträge bei Ihrem Registrar hinzu und klicken Sie dann auf Verifizieren. Nach der Verifizierung löst der Domain-Namespace jeden selbst deklarierten Namespace ab und verschließt die Tür für ein Vortäuschen Ihrer Identität.

3. Ausliefern — verifiziert vs. live

„Verifiziert” ist nicht dasselbe wie „live”. Die Verifizierung bestätigt, dass Sie die Domain kontrollieren; das Zertifikat muss danach noch fertig ausgestellt werden, bevor der Endpunkt tatsächlich ausliefert. Die Hosting-Karte zeigt beide Zustände getrennt:

• Live über HTTPS — das Zertifikat ist aktiv und Ihre Hinweise sind erreichbar.
• Zertifikat wird ausgestellt … — verifiziert, aber das Zertifikat wird noch validiert. Das klärt sich normalerweise innerhalb weniger Minuten bis Stunden, nachdem der CNAME korrekt ist.
• Nicht erreichbar — prüfen Sie den CNAME — das Zertifikat ist nicht live geworden. Stellen Sie sicher, dass der csaf.<ihre-domain>-CNAME existiert und auf das Hosting-Ziel zeigt.

Resilic prüft verifizierte Domains planmäßig erneut. Verschwindet die Delegation später, stellen wir die Behauptung Ihres Namespace ein, benachrichtigen Sie per E-Mail und geben Ihnen ein Kulanzfenster, um das DNS zu korrigieren, bevor der Host entfernt wird — so hält ein abgelaufener Eintrag niemals still ein Zertifikat für eine Domain am Leben, die Sie nicht mehr kontrollieren.

Gefunden werden: security.txt unter Ihrer Unternehmensdomain veröffentlichen

Das Ausliefern Ihrer Advisories ist nur die halbe Auffindbarkeit. Sicherheitsforschende, Scanner und Aggregatoren beginnen bei Ihrer Unternehmensdomain, nicht bei csaf.<ihre-domain> — RFC 9116 verlangt die Discovery-Datei im Wurzelverzeichnis Ihrer Domain:

Scanner → https://<ihre-domain>/.well-known/security.txt → dessen CSAF:-Zeile → https://csaf.<ihre-domain>/.well-known/csaf/provider-metadata.json → Ihre Advisories

Die Verweise in dieser Datei sind live, sobald Ihre Domain verifiziert ist und ein Signaturschlüssel existiert — der Provider wird schon vor Ihrem ersten Advisory veröffentlicht, sodass ein Scanner, der der Kette folgt, provider-metadata.json und Ihren Schlüssel findet statt eines 404.

Wir liefern eine Kopie der security.txt auf dem CSAF-Host aus, aber das erste Glied dieser Kette ist von Ihnen bereitzustellen — wir können keine Datei im Wurzelverzeichnis Ihrer Unternehmensdomain ablegen, denn das ist die Autorität Ihrer Website, nicht unsere. Eine Domain kann also vollständig verifiziert sein und ausliefern und dennoch von Ihrer Unternehmensdomain aus unauffindbar bleiben, bis Sie diese erste Datei veröffentlichen.

Die Hosting-Karte liefert Ihnen die exakte Datei. Sobald Ihre Domain verifiziert ist, zeigt sie einen Block „security.txt unter Ihrer Unternehmensdomain veröffentlichen” mit:

• der exakten security.txt-Datei zum Herunterladen oder Kopieren (deren Canonical-Zeilen sowohl Ihren Apex als auch den Serving-Host nennen, deren CSAF:-Zeile auf uns zeigt),
• dem Ablageort — https://<ihre-domain>/.well-known/security.txt.

Die Datei ist eine OpenPGP-Klartextsignatur unter Ihrem Advisory-Signaturschlüssel, wie RFC 9116 es empfiehlt, und sechs Monate gültig. Veröffentlichen Sie sie unverändert samt Signaturblock und kopieren Sie vor dem Expires:-Datum eine frische Fassung von derselben Stelle — wir erinnern per E-Mail, wenn sie abzulaufen droht. Jeder Contact:-Wert muss eine URI sein: eine E-Mail-Adresse (wir machen mailto: daraus), ein mailto:-, tel:- oder https:-Link. Mehrere Kontakte, die bevorzugten zuerst, werden in den Herausgeber-Einstellungen durch Komma getrennt.

Drei Punkte, die stimmen müssen:

• Als Datei hochladen, nicht einfügen. Website-Baukästen und CMS-Textfelder ändern Zeilenenden und entfernen den abschließenden Zeilenumbruch — und RFC-9116-Prüfer beanstanden eine Datei, deren letzte Zeile keinen Zeilenumbruch hat. Nutzen Sie security.txt herunterladen und laden Sie diese Datei unverändert hoch; falls Sie doch einfügen müssen, achten Sie darauf, dass die letzte Zeile mit einem Zeilenumbruch endet.
• HTTPS ist erforderlich. RFC-9116-Discovery funktioniert nur über https:// im Wurzelverzeichnis Ihrer Domain. Liefert Ihr Apex nur einfaches HTTP aus, beheben Sie das zuerst — einer reinen HTTP-security.txt wird nicht vertraut.
• Aktuell halten. Die Datei trägt ein Expires-Datum und, wenn Sie einen Signaturschlüssel gesetzt haben, einen Encryption-Verweis. Kopieren Sie sie neu, wenn sich Kontakt oder Schlüssel ändern. Haben Sie einen eigenen OpenPGP-Schlüssel importiert, zeigt die Herausgeber-Karte sein Ablaufdatum, und Sie erhalten 30 Tage vorher eine E-Mail — ein abgelaufener Schlüssel entwertet jede Signatur, also rechtzeitig rotieren; von Resilic erzeugte Schlüssel laufen nie ab.
• Der Schlüssel nennt Ihren Kontakt. Ein von Resilic verwalteter Schlüssel trägt Ihre Organisation, Ihre Domain und jede E-Mail-Kontaktadresse als OpenPGP-Benutzer-IDs (Essert GmbH (essert.com) <[email protected]>) — genau damit vergleichen RFC-9116-Prüfwerkzeuge die Contact:-Zeile. Ändern Sie den Kontakt, wird die neue Adresse vor der nächsten Veröffentlichung auf denselben Schlüssel zertifiziert — der Fingerabdruck bleibt gleich, frühere Signaturen bleiben gültig. Ein importierter Schlüssel gehört Ihnen: Fehlt ihm die Adresse, sagt die Herausgeber-Karte das, und Sie ergänzen die Benutzer-ID mit Ihrem eigenen PGP-Werkzeug und importieren erneut.

Sobald Sie sie veröffentlicht haben, prüft die Hosting-Karte Ihre Unternehmensdomain und zeigt ein Kennzeichen — Von Ihrer Domain auffindbar, wenn Ihre Apex-security.txt live ist und auf uns verweist, oder einen Hinweis, wenn sie fehlt oder noch nicht zurückverweist. So müssen Sie nicht raten, ob Ihr Teil der Kette tatsächlich vorhanden ist. Ihr Dashboard zeigt denselben Bereitschaftsstand auf einen Blick, sodass ein fehlender Schritt sichtbar ist, ohne diesen Bildschirm zu öffnen.

Ist das Bearbeiten des Wurzelverzeichnisses Ihrer Unternehmensdomain nicht praktikabel, ist der DNS-Path-Weg unten die andere Möglichkeit, von Ihrer Domain aus gefunden zu werden, ohne etwas am Apex zu veröffentlichen.

Alternative: Weiterleitung statt eigener Datei

Wenn Sie die Datei nicht selbst pflegen wollen, richten Sie an Ihrer Unternehmensdomain eine dauerhafte Weiterleitung (HTTP 301) ein:

https://<ihre-domain>/.well-known/security.txt  →  https://csaf.<ihre-domain>/.well-known/security.txt

Das Ziel ist die Kopie, die wir auf dem CSAF-Host ausliefern. Sie wird bei jeder täglichen Veröffentlichung neu signiert, und ihr Expires:-Datum wandert dabei mit — sie läuft also nie ab, und Sie müssen nichts mehr erneuern. RFC 9116 erlaubt eine solche Weiterleitung ausdrücklich, und die Canonical:-Zeilen der Datei nennen beide Adressen, sodass ein Scanner die Weiterleitung als beabsichtigt erkennt. Die Hosting-Karte folgt der Weiterleitung ebenfalls; das Kennzeichen Von Ihrer Domain auffindbar bleibt grün.

Die meisten Website-Baukästen und CMS bieten Weiterleitungen an, auch wenn sie keine beliebigen Dateien unter /.well-known/ zulassen — für diese Systeme ist die Weiterleitung der einfachste Weg. Zwei Bedingungen: Die Weiterleitung muss von https:// ausgehen (nicht nur von http://), und sie muss dauerhaft sein (301 oder 308), damit Scanner sie zwischenspeichern dürfen.

Betreiben Sie Ihren Webserver selbst, sind beide Wege gleichwertig: Weiterleitung, oder die Datei per Cron mit einem Integrations-Token täglich neu abholen.

Optional: DNS-Path-Discovery

CSAF beschreibt mehrere Wege, auf denen ein Konsument Ihren Provider auffinden kann. Standardmäßig liefert Resilic den Well-Known-Weg aus. Zusätzlich können Sie den DNS-Path-Weg aktivieren: einen zweiten Host, csaf.data.security.<ihre-domain>, dessen Adresse ein Tool allein aus Ihrer Domain ableiten und Ihre Provider-Metadaten ohne vorherige Konfiguration abrufen kann.

Er ist opt-in, weil er einen zweiten CNAME und ein zweites Zertifikat benötigt. Aktivieren Sie „Auch den DNS-Path-Discovery-Weg bereitstellen” in der Hosting-Karte und fügen Sie dann den zusätzlichen angezeigten Eintrag hinzu:

• CNAME — csaf.data.security.<ihre-domain> → dasselbe Hosting-Ziel wie Ihr primärer Host.

Lassen Sie ihn aus, wird nur der Well-Known-Weg ausgeliefert — was für sich genommen vollständig gültig ist. Aktivieren Sie ihn, wenn Sie die zusätzliche Auffindbarkeit wünschen; schalten Sie ihn wieder ab, wird der zweite Host entfernt.

Was veröffentlicht wird

Jeder freigegebene Hinweis wird als CSAF-2.0-Dokument mit seiner losgelösten Signatur und den Hashes veröffentlicht, zusammen mit den Discovery-Dateien, die ein Konsument benötigt — die Provider-Metadaten, der Index, der Changes-Feed und ein ROLIE-Feed mit seinen Service- und Category-Dokumenten, damit ein ROLIE-Client den Feed selbst auffinden kann. Das Zurückziehen eines Hinweises entfernt ihn aus dem Feed und aktualisiert die Discovery-Dateien am Edge, sodass eine Korrektur oder ein Rückzug sich zügig verbreitet, statt einen Cache abzuwarten.

Jede Veröffentlichung — der tägliche Lauf wie jeder Klick auf Veröffentlichen — hinterlässt einen Beleg auf der Herausgeber-Karte: wann, durch wen (oder „täglicher Lauf”), wie viele Dateien und welche Hinweise anhand ihrer Tracking-ID. Die Karte verlinkt außerdem die live ausgelieferten provider-metadata.json und index.txt auf Ihrem CSAF-Host, damit Sie prüfen können, was Konsumenten tatsächlich sehen, statt dem Beleg zu vertrauen. Der Veröffentlichungsverlauf zeigt die letzten zwanzig.

Signaturschlüssel, Herausgeber-Kontaktdaten und der Advisory-Workflow selbst werden im Bildschirm Sicherheitshinweise und in Berichte & Fristen behandelt.

Hinweise ohne CVE

Die meisten Hinweise entstehen aus einer korrelierten Flotten-Schwachstelle — einer CVE, die gegen eine hochgeladene SBOM abgeglichen wurde. Manche können das nicht: ein Problem, das Ihr eigenes Team gefunden hat und das noch keine CVE trägt, ein Produkt, dessen SBOM nicht in Resilic liegt, oder eine Schwachstelle, die gar keine Komponente ist (eine Standardkonfiguration, ein Protokoll, physischer Zugang). Dafür erstellen Sie über Neuer Hinweis auf dem Bildschirm „Sicherheitshinweise” einen Hinweis von Hand:

• ein Titel und Ihre eigene Beschreibung des Problems — die Faktenbasis, aus der die KI Zusammenfassung und Abhilfe entwirft (sie ergänzt nichts, was Sie nicht angegeben haben);
• die betroffenen Versionen, ausgewählt aus Ihrem Register — nie Freitext;
• optional eine CVE, eine externe Kennung (Ihre Hinweisnummer, eine GHSA- oder CERT-Kennung) und ein CVSS-Basiswert.

Danach ist der Ablauf identisch: Sie bestätigen die behobene Version, unterschreiben, und der Hinweis wird mit dem nächsten Bündel veröffentlicht. CSAF 2.0 verlangt keine CVE; das exportierte Dokument lässt das Feld weg, trägt den Titel und führt die externe Kennung unter ids. Der Hinweis ist in Resilic als Manuell erstellt gekennzeichnet, damit Prüfende ihn von einem aus Korrelationsdaten zusammengestellten unterscheiden können.

Ihre CVD-Richtlinie, öffentlich bereitgestellt

Sobald Sie Ihre Richtlinie zur koordinierten Schwachstellenoffenlegung (CVD) freigeben, wird sie auf demselben Host unter https://csaf.<ihre-domain>/cvd-policy (eine lesbare Webseite) und …/cvd-policy.pdf (das gebrandete PDF) bereitgestellt, und das Policy:-Feld Ihrer security.txt verweist darauf — damit Sicherheitsforschende, die Ihre Offenlegungsstelle finden, nachlesen können, wie eine Schwachstelle zu melden ist. Nur eine freigegebene Richtlinie wird bereitgestellt; ein Entwurf wird nie veröffentlicht, und das Bearbeiten einer freigegebenen Richtlinie setzt sie auf Entwurf zurück, bis Sie erneut unterschreiben. Die bereitgestellte Seite trägt denselben Hinweis zur Bereitschaft wie der Export — eine CVD-Richtlinie ist ein Element von CRA Anhang I / Artikel 13, das ab 11. Dezember 2027 gilt, und ihre Bereitstellung ist für sich genommen kein Nachweis der Konformität. Ohne verifizierte CSAF-Domain bleibt die Richtlinie wie bisher nur als Export verfügbar.

Richtliniendokumente existieren je Sprache: Die englische und die deutsche Variante werden unabhängig voneinander entworfen, bearbeitet und freigegeben (eine ungeprüfte Übersetzung ist kein Nachweis). Die englische Variante besitzt die kanonischen /cvd-policy-URLs; eine freigegebene deutsche Variante wird zusätzlich unter …/cvd-policy.de und …/cvd-policy.de.pdf bereitgestellt. Die Seite „Dokumente“ öffnet die Fassung, die Ihrer Oberflächensprache entspricht; ist diese noch leer und die andere enthält bereits Inhalt oder ein hochgeladenes Dokument, weist ein Hinweis mit einem Klick zum Wechsel darauf hin — ein auf Deutsch hochgeladenes Dokument gilt so für Kolleginnen und Kollegen auf Englisch nie als fehlend.

Wir prüfen zudem täglich, ob Ihre veröffentlichte Richtlinie erreichbar bleibt. Wird eine freigegebene Richtlinie unter ihrer URL nicht mehr ausgeliefert — der Fall „in der App signiert, öffentlich 404” —, kennzeichnet der Richtlinien-Bildschirm dies und wir benachrichtigen Sie per E-Mail (abschaltbar unter Benachrichtigungen), damit eine defekte Offenlegungsstelle nicht unbemerkt bleibt.