Responsible Disclosure & Sicherheitsrichtlinie

Koordinierte Offenlegung · ISO/IEC 29147 & ISO/IEC 30111

Unsere Methode

Wir sind ein Forschungsinstitut, kein Anbieter auf Kundenjagd. Wir führen Root-Level-Codeanalysen an öffentlich vertriebener Software durch und legen offen, was wir finden - gegenüber dem Unternehmen und der Aufsichtsbehörde, gleichzeitig. Hier ist, was das in der Praxis bedeutet, und warum es trägt. Wir veröffentlichen, was wir tun; die konkreten Techniken hinter einem einzelnen Fund bleiben im Bericht, den wir dem Unternehmen schicken, nicht auf dieser Seite.

• Kostenlose, bedingungslose Offenlegung. Öffentliche Offenlegung ist Tier 1. Sie erfolgt nach dem 90-Tage-Embargo, unabhängig von Zahlung, unabhängig von Antwort. Nichts wird für Geld zurückgehalten.
• Koordiniert, keine Kaltakquise. Wir folgen ISO/IEC 29147. Aufsichtsbehörden werden von Tag eins an in CC gesetzt - sichtbar, nicht verdeckt, nicht erst informiert, wenn nichts vorangeht.
• Evidenz, keine Behauptung. Jeder Fund verweist auf ein konkretes Artefakt in der tatsächlich ausgelieferten Software - eine deklarierte Berechtigung, eine kompilierte SDK-Klasse, einen hartkodierten Schlüssel. Jeder kompetente Dritte kann das unabhängig nachprüfen.
• Nicht gewinnorientiert, strukturell. RFI-IRFOS ist ein eingetragener, nicht gewinnorientierter Verein. Es gibt keine Anteilseigner; Überschüsse werden in Forschung reinvestiert. Kostenpflichtige Beratungsstufen sind optional und getrennt - nie eine Bedingung für kostenlose Offenlegung.
• Forschung, keine Erpressung. Unsere Arbeit gründet auf der Freiheit der Wissenschaft (Art. 17 B-VG) und Art. 89 DSGVO. Wir berichten über die eigene, vertriebene Software von Unternehmen - nie über private, gestohlene Daten oder Daten aus unbefugtem Zugriff.
• Niemals Störung. Kein Denial-of-Service, keine Lasttests. Funde stammen aus statischer Analyse der ausgelieferten Software, nie aus Angriffen auf die Produktivumgebung.
• Keine dynamischen Tests ohne Vereinbarung, kein Social Engineering. Live-Tests gegen die eigenen Systeme eines Unternehmens finden nur unter einem unterschriebenen Auftrag statt. Wir phishen nie, täuschen nie vor, manipulieren nie Personal, um Zugang zu erhalten.
• Kein erfundener Fortschritt, auch nicht von unseren eigenen Werkzeugen. Jedes hausinterne Agenten-Tool läuft unter einer schriftlichen Wahrheitsrichtlinie: nie behaupten, dass eine Datei existiert, Code gelaufen ist oder ein Test bestanden wurde, ohne dass es tatsächlich verifiziert wurde.

Unser Offenlegungsrahmen

Root-Level-Codeanalyse. Aufsichtsbehörden bei jeder Einreichung in CC - nationale Datenschutzbehörde + EDSB. 90 Tage koordinierte Offenlegung. Unser Rahmen. Unser Zeitplan.

Wir betreiben keine Bug-Bounty-Programme, kein HackerOne und keine Drittanbieter-Plattformen für Schwachstellenprämien. Alle Funde werden unter dem Forschungsfreiheitsgesetz (Art. 17 StGG) veröffentlicht und stellen freien wissenschaftlichen Wissensaustausch im EU-Forschungsrahmen dar - unabhängig von kommerziellem Anreiz.

Offenlegung ist bedingungslos. Jede Organisation auf unserem Ledger erhält dieselbe Behandlung - dasselbe Embargo, dieselbe Veröffentlichung, dieselbe Behördenbenachrichtigung - unabhängig davon, ob sie RFI-IRFOS kommerziell beauftragt.

90 Tage koordiniertes Embargo von der Erstbenachrichtigung bis zur öffentlichen Offenlegung. Aufsichtsbehörden (DSB, EDSA, CERT.at) werden parallel benachrichtigt — nicht im Nachhinein, nicht nur, „falls das hier zu nichts führt". Verlängerungen werden von Fall zu Fall geprüft, bei echter laufender Behebung, nie zum Hinauszögern.

Wir verbringen das meiste unserer Zeit damit, Dinge zu finden, die andere Unternehmen nicht gefunden haben wollten. Fairerweise: So findet man eines bei uns. Echtes Institut, echte Anschrift in Graz, Österreich, kein Bug-Bounty-Theater, kein Chatbot zwischen Ihnen und der Person, die das hier tatsächlich liest.

Eine Schwachstelle melden

E-Mail: rfi.irfos@gmail.com
PGP-Schlüssel auf Anfrage verfügbar. Wir bestätigen jede Meldung innerhalb von 48 Stunden — von einem Menschen, nicht einer Ticketnummer.

Wie wir mit Ihren Einsendungen umgehen

ISO/IEC-30111-Triage: reproduzieren, eingrenzen, beheben, Sie kreditieren. Kein Fund wird begraben, weil er unbequem ist — genau das ist die gesamte Beschwerde, die wir gegen alle anderen erheben, und wir nehmen uns davon nicht aus.

Nur rechtmäßige Grundlage. Wir akzeptieren Funde, die über öffentlich zugängliche Informationen, Ihre eigenen Geräte oder Software, zu deren Test Sie berechtigt sind, gewonnen wurden — derselbe Maßstab, an den sich auch unsere eigene Root-Level-Codeanalyse hält. Zeigt das, was Sie uns schicken, Hinweise auf unbefugten Zugriff auf ein System, das Sie nicht kontrollieren, veröffentlichen oder kreditieren wir es unter diesem Programm nicht. Wir melden es direkt an die zuständigen Behörden, genauso, wie wir behandelt werden wollten, wenn die Rollen vertauscht wären.

Namensnennung, Ihre Wahl. Vollständiger Name, Alias oder vollständig anonym — genau wie in unseren AGB festgelegt. Kein Anruf, kein Treffen. Alles bleibt schriftlich, wie bei jeder Offenlegung, die wir versenden.

Geltungsbereich

rfi-irfos.com · ternlang.com · lighthouse-rfi-irfos.fly.dev · github.com/rfi-irfos/*

Nicht im Geltungsbereich

Social Engineering, physische Angriffe, DoS/DDoS. Wir betreiben kein Bug-Bounty-Programm — keine Punkte, kein Merchandise, keine Bestenliste. Das hier ist keine Plattform, das ist ein Postfach.

Ehrentafel

Verantwortungsvolle Melder werden (mit Zustimmung) öffentlich in unseren Offenlegungsberichten genannt. Ihr Name, wo er verdient ist — nichts davon ist gamifiziert.

Safe Harbor

Sicherheitsforschung in gutem Glauben, die im Einklang mit dieser Richtlinie durchgeführt, uns privat gemeldet und mit angemessener Zeit zur Triage versehen wird, löst von unserer Seite keine zivil- oder strafrechtliche Anzeige aus. Wir behandeln Ihre Meldung nicht als unbefugten Zugriff, sondern als das, was sie ist.

Warum wir diese Seite überhaupt veröffentlichen

Weil ein Forschungsinstitut, das die undokumentierten Tracking-Mechanismen, hartkodierten Schlüssel und SDK-Initialisierungen vor Einwilligung anderer offenlegt, ohne seine eigene Sicherheitsrichtlinie zu veröffentlichen, genau der doppelte Standard wäre, den wir in unseren eigenen Berichten anprangern. Diese Seite existiert, damit niemand das auch hier nur glauben muss.

Ein Wort zum Ton

Wir arbeiten von Graz, Österreich aus — näher an den Alpen als an einem Glasturm. Wir folgen ISO/IEC 29147 buchstabengetreu, wir melden bei Behörden, bevor uns jemand dazu zwingt, und wir finden trotzdem, dass die meisten Sicherheitsseiten von Unternehmen klingen, als wären sie von dem Vorfall geschrieben worden, den sie eigentlich verhindern sollen. Diese hier nicht.