Zum Inhalt springen

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.

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.

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

Abschnitt betitelt „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.

„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

Abschnitt betitelt „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

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:

  • dem exakten security.txt-Inhalt zum Kopieren (dessen Canonical auf Ihren Apex zeigt, dessen CSAF:-Zeile auf uns),
  • dem Ablageort — https://<ihre-domain>/.well-known/security.txt.

Zwei Punkte, die stimmen müssen:

  • 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.

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.

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:

  • CNAMEcsaf.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.

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.

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

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.

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.