Spam im Security-Postfach: Beg Bounty, Scanner-Berichte und Massenmails richtig behandeln

Jede öffentliche Meldeadresse zieht Mails an, die keine echten Schwachstellenmeldungen sind: automatisierte "Funde" mit der Bitte um eine Belohnung (Beg Bounty), ungeprüfte Scanner-Berichte, maschinell erzeugte Meldungen, Werbung und gewöhnlichen Spam. Löschen ist trotzdem die falsche Antwort. Die Leitlinie der Kommission verlangt, dass die Erstbewertung einer Meldung sofort beginnt, und die BSI TR-03183-3 verlangt, dass keine Meldung von einer einzelnen Person geschlossen wird. Professionell ist deshalb ein Dreiklang: eine Richtlinie, die klar sagt, was als Schwachstelle gilt und dass es keine Prämie gibt, eine Einstufung jeder Mail nach festen Merkmalen mit Protokoll, und vorbereitete Antworten für die wiederkehrenden Fälle.

Warum landet so viel Müll im Sicherheits-Postfach?

Eine security.txt soll gefunden werden, von Menschen und von Programmen. Dieselben Programme nutzen auch Leute, die mit wenig Aufwand an vielen Stellen Geld verlangen. Das Muster ist seit Jahren beschrieben: Ein Werkzeug prüft eine Domain auf Allerweltsbefunde, etwa einen fehlenden DMARC-Eintrag oder einen fehlenden HTTP-Header, und eine Vorlage macht daraus eine "Vulnerability Report"-Mail mit der Frage nach einer Prämie. Ziel sind bewusst kleinere Unternehmen ohne eigenes Belohnungsprogramm. Manche Absender werden nach einer Absage fordernder bis hin zur Drohung.

Seit 2025 kommen maschinell geschriebene Meldungen hinzu, die plausibel klingen, aber nicht stimmen. Das Open-Source-Projekt curl hat das öffentlich dokumentiert: 2025 waren nur rund 5 Prozent der Einreichungen gültig, etwa 20 Prozent stufte der Projektleiter als maschinell erzeugten Unsinn ein, und jede Meldung band drei bis vier Personen für 30 Minuten bis drei Stunden. Ende Januar 2026 beendete curl sein Prämienprogramm, um den Anreiz zu nehmen. Diese Zahlen stammen aus Belohnungsprogrammen. Wie viele solcher Mails ein gewöhnliches Postfach eines Mittelständlers erreichen, ist nicht öffentlich erhoben. Klar ist nur die Richtung: Mit der Meldepflicht nach Artikel 14 der Verordnung (EU) 2024/2847 und der Kontaktadresse nach Anhang I Teil II Nummer 6 werden viele Herstellerpostfächer zum ersten Mal maschinell auffindbar.

Welche Mails kommen an?

Die letzte Zeile ist der Grund für diesen Leitfaden. Eine echte Meldung sieht nicht immer professionell aus. Gute Forscher schreiben oft in drei Sätzen, auf Englisch, von einer Freemail-Adresse. Eine Mail, die ein Kunde nachts schickt, weil an seiner Anlage etwas Fremdes passiert, hat keinen Aufbau und keine Fachbegriffe. Wer nach Form sortiert, sortiert genau diese Meldungen aus.

Warum darf nichts still gelöscht werden?

Die 24-Stunden-Frist für die Frühwarnung beginnt nicht mit dem Eingang einer Mail, sondern mit der Kenntnis (Artikel 14 Absatz 2). Kenntnis liegt nach der Leitlinie der Kommission C(2026) 5252 vor, wenn die Erstbewertung mit hinreichender Gewissheit ergibt, dass eine Schwachstelle im eigenen Produkt aktiv ausgenutzt wird. Der Eingang startet aber die Pflicht, diese Erstbewertung sofort zu beginnen (Randnummer 213). Eine Mail, die drei Tage im Spamordner liegt, ist nicht sofort bewertet. Ob sich der Hersteller dann auf den späteren Zeitpunkt berufen kann, ist offen; eine Behördenpraxis gibt es noch nicht. Sicher ist nur, dass er erklären muss, warum die Bewertung so spät begann. Mehr dazu unter Kenntnis und Fristbeginn.

Die BSI TR-03183-3 setzt in Abschnitt 4.4.7 zwei weitere Regeln. Alle eingehenden Meldungen sollen bestmöglich behandelt werden und dürfen nicht von einem einzelnen Analysten geschlossen werden, damit keine gültige Schwachstelle verloren geht (Buchstabe g). Hinweise auf bereits behobene Schwachstellen sollen trotzdem angenommen und geprüft werden (Buchstabe a). Ein automatisches Löschen widerspricht beidem.

Für die Technik heißt das: Der Spamfilter des Sicherheits-Postfachs markiert und sortiert in Ordner, er weist nicht ab und löscht nicht. Jeder Ordner wird täglich angesehen, nur in unterschiedlicher Tiefe.

Was in die Richtlinie gehört

Die Richtlinie zur koordinierten Offenlegung ist das wirksamste Mittel gegen Beg Bounty, weil sie die Antwort vorwegnimmt. Drei Punkte machen den Unterschied.

Ob es eine Prämie gibt

Erwägungsgrund 76 der Verordnung sieht vor, dass Hersteller Belohnungsprogramme einrichten können, die TR-03183-3 empfiehlt eines. Pflicht ist es nicht. Wer keines anbietet, schreibt das ausdrücklich hinein, zum Beispiel: "Wir haben kein Bug-Bounty-Programm und zahlen keine Prämien. Auf Wunsch nennen wir Meldende auf unserer Danksagungsseite." Eine Danksagungsseite (Hall of Fame) ist ein Anreiz ohne Geld, den die TR ausdrücklich nennt.

Was als Schwachstelle gilt

Nach Abschnitt 4.4.5 der TR muss der Hersteller veröffentlichen, was er als gültige Schwachstelle ansieht. Die TR empfiehlt dafür nur drei Kriterien: Die Schwachstelle betrifft ein eigenes Produkt oder die eigene Infrastruktur, die Information ist möglichst nicht öffentlich bekannt, und die Meldung ist nicht bloß das Ergebnis automatischer Werkzeuge ohne nachvollziehbaren Beleg. Eine lange Liste zusätzlicher Ausschlüsse passt deshalb nicht zur TR. Gut passt eine Liste von Beispielen, die das dritte Kriterium erklärt:

• Fehlende oder abweichende HTTP-Sicherheitsheader ohne Nachweis, dass daraus ein Angriff möglich wird.
• Hinweise zu SPF, DKIM oder DMARC der Maildomain ohne konkreten Missbrauch.
• Clickjacking auf Seiten, auf denen keine Aktion ausgelöst werden kann.
• Sichtbare Versionsnummern von Server oder Software ohne Nachweis einer verwundbaren Version.
• Fehlende Ratenbegrenzung bei Formularen ohne Nachweis eines Schadens.
• Self-XSS und andere Fehler, die nur die meldende Person selbst treffen.

Wichtig ist die Formulierung "ohne Nachweis einer Auswirkung". Ein fehlender Header kann in einer bestimmten Anwendung ein echtes Problem sein. Die Liste schließt nicht das Thema aus, sondern die Meldung ohne Beleg.

Für wen die Antwortfristen gelten

Die TR verlangt in Abschnitt 4.4.8 eine persönliche, nicht automatische Antwort auf eine Schwachstellenmeldung binnen 5 Werktagen und eine Detailantwort binnen 10 Werktagen. Eine Beg-Bounty-Mail ist eine schwache Meldung und bekommt diese Antwort, der Textbaustein genügt. Werbung und Phishing sind keine Meldungen. Die Richtlinie kann das klarstellen: "Die Fristen gelten für Meldungen von Schwachstellen. Werbung und Massenmails beantworten wir nicht." Daneben hilft der Satz "Bitte nutzen Sie bevorzugt unser Meldeformular". Ein Formular mit Pflichtfeldern für Produkt, Version und Schritte zur Nachstellung erzeugt bessere Meldungen als eine freie Mail. Die E-Mail-Adresse muss trotzdem bleiben, die TR verlangt sie (Abschnitt 4.4.7 Buchstabe e).

Einstufen statt löschen

Jede eingehende Mail bekommt eine Stufe, und jede Stufe hat eine Begründung. Das dauert bei einer Massenmail eine halbe Minute und schafft zwei Dinge: Niemand muss sich auf sein Bauchgefühl verlassen, und der Hersteller kann später zeigen, dass er jede Mail angesehen hat.

1. Hinweis auf AusnutzungDie Mail behauptet oder belegt, dass eine Schwachstelle bereits ausgenutzt wird ("in the wild", fremde Zugriffe, Logauszüge, Erpressung nach Angriff), oder ein Kunde meldet Auffälligkeiten an einem Produkt. Sofort an die Rufkette, egal wie die Mail aussieht. Diese Stufe wird nie herabgestuft, nur nach einer dokumentierten Erstbewertung geschlossen.
2. SchwachstellenmeldungKonkretes Produkt oder System, nachvollziehbare Beschreibung. An das PSIRT oder CSIRT, Antwort binnen 5 Werktagen.
3. Schwacher Hinweis, Beg BountyAllerweltsbefund ohne Nachweis, Vorlagentext, Frage nach Prämie. Antwort mit Textbaustein, eine zweite Person bestätigt das Schließen.
4. MassenmailWerbung, Adresshandel, Phishing, kein Bezug zu einer Schwachstelle. Sammelordner, keine Antwort, täglicher Blick über die Liste.

Zwei Regeln halten das Verfahren sicher. Erstens wird nur nach eindeutigen Merkmalen herabgestuft, im Zweifel bleibt die höhere Stufe. Zweitens ist das Fehlen von Form kein Merkmal: Freemail-Absender, schlechtes Englisch, Kürze oder ein fehlender Betreff sagen nichts über den Inhalt.

Woran sich Massenmails erkennen lassen

• Der Befund passt auf jede Domain. Header, Mail-Einträge, Versionsangaben. Nichts davon setzt voraus, dass jemand das Produkt angesehen hat.
• Kein Produktbezug. Die Mail nennt kein Produkt und keine Version, nur die Webseite.
• Die Prämie kommt vor dem Befund. "Do you offer a bug bounty?" im ersten Satz, Details erst gegen Zusage.
• Gleicher Text an mehrere Adressen. info@, security@ und die Geschäftsführung bekommen dieselbe Mail.
• Druck ohne Inhalt. Dringlichkeit, Fristen oder Hinweise auf "critical" ohne Beschreibung der Auswirkung.

Das Protokoll muss nicht aufwendig sein: Datum, Absender, Betreff, Stufe, Begründung in einem Satz, wer eingestuft hat, wer geschlossen hat. Eine Tabelle reicht. Über ein Jahr zeigt sie außerdem, wie viele echte Meldungen kamen und wie schnell sie bearbeitet wurden.

Wie antworten?

Für die wiederkehrenden Fälle lohnen sich Textbausteine auf Deutsch und Englisch, die einmal abgestimmt und dann unverändert genutzt werden.

• Beg Bounty. Dank für die Nachricht, Hinweis auf die Richtlinie und darauf, dass der Befund ohne Nachweis einer Auswirkung nicht als Schwachstelle gilt, kein Bug-Bounty-Programm, Vorgang geschlossen. Nachfragen ohne neuen Inhalt bekommen keine weitere Antwort.
• Schwache Meldung. Dank, Bitte um Produkt, Version, Schritte zur Nachstellung und beobachtete Auswirkung, Hinweis, dass die Meldung ohne Antwort nach 30 Tagen geschlossen wird. Das entspricht den Endzuständen, die die TR in Abschnitt 4.4.11 vorsieht.
• Drohung oder Forderung. Wer Geld verlangt und mit Veröffentlichung oder Angriff droht, bekommt keine Verhandlung. Belege sichern, Geschäftsführung einbeziehen, prüfen, ob doch ein Hinweis auf Ausnutzung vorliegt. Ob Anzeige erstattet wird, entscheidet die Geschäftsführung, bei Bedarf mit ihrer Kanzlei.
• Massenmail und Phishing. Keine Antwort. Eine Antwort bestätigt nur, dass die Adresse gelesen wird.

Anhänge echter Meldungen, etwa ein Skript als Machbarkeitsnachweis, werden nur in einer abgetrennten Umgebung geöffnet. Das Sicherheits-Postfach ist ein naheliegendes Ziel für Angriffe, gerade weil dort jemand Anhänge erwartet. Die Textbausteine und eine Einstufungshilfe zum Ausdrucken enthält das Meldepflicht-Kit.

Typische Fehler

• Spamfilter auf Abweisen. Der Absender bekommt eine Fehlermeldung, der Hersteller sieht nichts. Gerade bei Meldungen von privaten Adressen oder neuen Domains greift das oft.
• Weiterleitung an eine Sammeladresse ohne Zuständigkeit. security@ landet in info@, dort liest es jeder ein bisschen und keiner ganz.
• Diskussion mit Beg-Bounty-Absendern. Jede weitere Antwort kostet Zeit und erzeugt neue Nachfragen. Eine Antwort, dann Schluss.
• Zahlung "aus Kulanz". Wer einmal zahlt, steht auf der Liste der Zahler.
• Sortieren nach Form. Die knappe Mail auf Englisch von einer Freemail-Adresse landet im Spam, die lange Vorlagenmail mit Fachbegriffen beim Entwicklungsleiter.
• Kein Protokoll. Ohne Liste lässt sich später nicht zeigen, dass eine Mail angesehen und begründet geschlossen wurde.

Was das praktisch heißt

Für einen Hersteller von Messgeräten mit 90 Beschäftigten bedeutet das: Richtlinie um den Satz zur Prämie und die Beispielliste ergänzen, den Spamfilter des Sicherheits-Postfachs auf Markieren stellen, zwei Personen für die tägliche Durchsicht benennen, Textbausteine freigeben, eine Tabelle als Protokoll anlegen. Das ist an einem Nachmittag erledigt. Schwierig wird es außerhalb der Arbeitszeit und im Urlaub, wenn die Mail mit dem Hinweis auf Ausnutzung zwischen zwanzig Massenmails steckt. CRA Response Center stuft jede Mail an der Meldeadresse nach festen Merkmalen ein und begründet die Stufe. Herabgestufte Mails sieht der Hersteller täglich im Sammelbericht, Mails mit Hinweis auf Ausnutzung werden nie herabgestuft und wecken die Rufkette. Die Antworten an Meldende schreibt der Hersteller selbst.

Kostenlose VorlagenCRA-Meldepflicht-KitMelde-Playbook, Kenntnisvermerk, Meldevorlagen für die ENISA-Plattform, Rufkette und Fristenrechner. Sechs Word-Vorlagen, zwei Excel-Mappen und ein Handbuch, kostenlos per E-Mail.Kit anfordern

Häufige Fragen

Weiterlesen

• Richtlinie zur koordinierten OffenlegungWo Prämie, gültige Schwachstelle und Antwortfristen geregelt werden.
• PSIRT im MittelstandWer das Postfach liest, wer bewertet und wer antwortet, mit wenigen Leuten.
• Kenntnis und FristbeginnWarum der Eingang einer Mail die Erstbewertung startet und nicht die Frist.
• security.txt nach RFC 9116 und BSI TR-03183-3Die Datei, über die das Postfach gefunden wird.

Quellen

• Verordnung (EU) 2024/2847, Artikel 13 Absatz 17, Artikel 14, Anhang I Teil II, Erwägungsgrund 76, Amt für Veröffentlichungen der EU, 20. November 2024.
• Leitlinien der Kommission C(2026) 5252, Annex, Randnummer 213, Europäische Kommission, 27. Juli 2026.
• BSI TR-03183-3 Vulnerability Reports and Notifications, Version 1.0.0, Abschnitt 4.4, Bundesamt für Sicherheit in der Informationstechnik, 20. August 2025.
• Have a domain name? "Beg bounty" hunters may be on their way, Sophos, 2021.
• Death by a thousand slops, Daniel Stenberg (curl), 14. Juli 2025.
• curl ending bug bounty program after flood of AI slop reports, BleepingComputer, 22. Januar 2026.