Die Sicherheitsforschungs-Community ist einer der gr\u00f6\u00dften Verm\u00f6genswerte von GitHub. Jedes Jahr helfen uns Forscher aus der ganzen Welt dabei, Schwachstellen zu finden und zu beheben und so die Plattform f\u00fcr \u00fcber 180 Millionen Entwickler sicherer zu machen. Unser Bug-Bounty-Programm gibt es, weil wir davon \u00fcberzeugt sind, dass die Zusammenarbeit mit externen Forschern eine der effektivsten M\u00f6glichkeiten zur Verbesserung der Sicherheit ist, und wir f\u00fchlen uns diesem Ziel weiterhin verpflichtet.<\/p>\n
Aber wie jedes Bug-Bounty-Programm passen wir uns einer sich ver\u00e4ndernden Landschaft an. Wir m\u00f6chten mitteilen, was wir sehen, was wir dagegen tun und wie wir \u00fcber die Sicherheitsgrenzen einer Plattform wie GitHub denken.<\/p>\n
Im vergangenen Jahr ist das Einreichungsvolumen in der gesamten Branche deutlich gestiegen. Neue Tools, einschlie\u00dflich KI, haben die Eintrittsbarriere f\u00fcr die Sicherheitsforschung gesenkt, was in vielerlei Hinsicht eine positive Entwicklung ist. Mehr Menschen, die Angriffsfl\u00e4chen erkunden, bedeuten mehr M\u00f6glichkeiten, echte Probleme zu finden.<\/p>\n
Allerdings haben wir neben der Zunahme legitimer Berichte auch einen starken Anstieg an Einsendungen beobachtet, die keine echten Sicherheitsauswirkungen nachweisen. Dazu geh\u00f6ren Berichte ohne Proof of Concept, theoretische Angriffsszenarien, die einer Pr\u00fcfung nicht standhalten, und Erkenntnisse, die bereits in unserer ver\u00f6ffentlichten Liste der nicht zul\u00e4ssigen Unternehmen abgedeckt sind. Dies gilt nicht nur f\u00fcr GitHub. Programme in der gesamten Branche k\u00e4mpfen mit der gleichen Herausforderung, und einige wurden ganz eingestellt.<\/p>\n
Wir wollen nicht in diese Richtung gehen. Stattdessen m\u00f6chten wir in die Verbesserung unseres Programms investieren.<\/p>\n
Wir legen die Messlatte f\u00fcr das, was wir als vollst\u00e4ndige Einreichung betrachten, h\u00f6her. K\u00fcnftig werden Berichte strenger anhand dieser Kriterien bewertet:<\/p>\n
Wir m\u00f6chten dies ausdr\u00fccklich betonen: Wir haben kein Problem damit, dass Forscher KI-Tools verwenden.<\/strong> KI ist ein Kraftmultiplikator und wir gehen davon aus, dass sie in der Sicherheitsforschung eine zunehmende Rolle spielen wird. Wir nutzen KI in unseren eigenen internen Sicherheitsprogrammen und wir sehen, dass die besten externen Forscher dasselbe tun. Wir begr\u00fc\u00dfen es.<\/p>\n Was wir brauchen, ist derselbe Standard, den wir immer erwartet haben: Validierung. Ein KI-gest\u00fctzter Befund, der verifiziert, reproduziert und mit einem funktionierenden Machbarkeitsnachweis eingereicht wurde, ist eine gro\u00dfartige Einreichung. Eine nicht validierte Ausgabe, die im Ist-Zustand ohne Vervielf\u00e4ltigung oder nachgewiesene Auswirkung eingereicht wird, gilt nicht. Dies ist kein neuer Standard. Es ist derselbe Standard, den wir auf die Scannerausgabe, die statische Analyse und jedes andere Tool anwenden. Der menschliche Forscher ist f\u00fcr die Richtigkeit der Einreichung verantwortlich.<\/p>\n Wir bitten die Forscher au\u00dferdem, die Berichte pr\u00e4gnant und strukturiert zu halten. Ein aussagekr\u00e4ftiger Bericht besteht aus drei Dingen: einer kurzen Zusammenfassung<\/strong> des Problems, klaren Schritten zur Reproduktion<\/strong> mit unterst\u00fctzenden Beweisen (Screenshots, HTTP-Anfragen, Terminalausgabe) und einer Auswirkungserkl\u00e4rung<\/strong>, die erkl\u00e4rt, was ein Angreifer tats\u00e4chlich erreichen kann. Das ist es. Ausf\u00fchrliche Berichte wie mehrseitige theoretische Erz\u00e4hlungen, ausgeruhter Hintergrundkontext oder KI-generierte F\u00fcllmaterialien verlangsamen die Triage, da der eigentliche Befund untergeht. Je klarer und direkter Ihr Bericht, desto schneller k\u00f6nnen wir darauf reagieren.<\/p>\n Die Werkzeuge spielen keine Rolle. Die Qualit\u00e4t der Arbeit stimmt.<\/p>\n Ein Muster, das wir h\u00e4ufig beobachten, verdient eine eigene Diskussion. Viele Berichte beschreiben Szenarien, in denen ein Benutzer mit vom Angreifer kontrollierten Inhalten interagiert (ein b\u00f6sartiges Repository, ein manipuliertes Problem, nicht vertrauensw\u00fcrdiger Code) und ein unerw\u00fcnschtes Ergebnis erlebt. Diese Berichte sind oft gut geschrieben und in ihren Beobachtungen technisch korrekt, aber sie verstehen falsch, wo die Sicherheitsgrenze liegt.<\/p>\n Wir investieren stark in Systeme und Teams, die sich der Erkennung und Handhabung b\u00f6sartiger Inhalte auf der gesamten Plattform widmen, vom automatisierten Scannen bis zur manuellen \u00dcberpr\u00fcfung. Allerdings arbeitet GitHub nach einem Modell der geteilten Verantwortung<\/strong>. Benutzer sind verantwortlich f\u00fcr:<\/p>\n Wenn ein \u201eAngriff\u201c erfordert, dass das Opfer aktiv nach vom Angreifer kontrollierten Inhalten sucht und mit ihnen interagiert (ein b\u00f6sartiges Repo klonen, ein KI-Tool mit der Analyse nicht vertrauensw\u00fcrdigen Codes beauftragen, eine manipulierte Datei \u00f6ffnen), ist die Sicherheitsgrenze die Entscheidung des Benutzers, diesem Inhalt zu vertrauen. Diese Szenarien stellen im Allgemeinen keine Umgehung der Sicherheitskontrollen von GitHub dar.<\/p>\n Um Forschern bei der Kalibrierung zu helfen, sehen wir hier regelm\u00e4\u00dfig Muster, die in die gemeinsame Verantwortung fallen:<\/p>\nDas Sicherheitsmodell von GitHub verstehen: Geteilte Verantwortung<\/h2>\n
\n
H\u00e4ufige Beispiele<\/h3>\n