Die Sicherheitsforschungs-Community ist einer der größten Vermögenswerte von GitHub. Jedes Jahr helfen uns Forscher aus der ganzen Welt dabei, Schwachstellen zu finden und zu beheben und so die Plattform für über 180 Millionen Entwickler sicherer zu machen. Unser Bug-Bounty-Programm gibt es, weil wir davon überzeugt sind, dass die Zusammenarbeit mit externen Forschern eine der effektivsten Möglichkeiten zur Verbesserung der Sicherheit ist, und wir fühlen uns diesem Ziel weiterhin verpflichtet.
Aber wie jedes Bug-Bounty-Programm passen wir uns einer sich verändernden Landschaft an. Wir möchten mitteilen, was wir sehen, was wir dagegen tun und wie wir über die Sicherheitsgrenzen einer Plattform wie GitHub denken.
Das Volumenproblem
Im vergangenen Jahr ist das Einreichungsvolumen in der gesamten Branche deutlich gestiegen. Neue Tools, einschließlich KI, haben die Eintrittsbarriere für die Sicherheitsforschung gesenkt, was in vielerlei Hinsicht eine positive Entwicklung ist. Mehr Menschen, die Angriffsflächen erkunden, bedeuten mehr Möglichkeiten, echte Probleme zu finden.
Allerdings haben wir neben der Zunahme legitimer Berichte auch einen starken Anstieg an Einsendungen beobachtet, die keine echten Sicherheitsauswirkungen nachweisen. Dazu gehören Berichte ohne Proof of Concept, theoretische Angriffsszenarien, die einer Prüfung nicht standhalten, und Erkenntnisse, die bereits in unserer veröffentlichten Liste der nicht zulässigen Unternehmen abgedeckt sind. Dies gilt nicht nur für GitHub. Programme in der gesamten Branche kämpfen mit der gleichen Herausforderung, und einige wurden ganz eingestellt.
Wir wollen nicht in diese Richtung gehen. Stattdessen möchten wir in die Verbesserung unseres Programms investieren.
Was eine starke Einreichung ausmacht
Wir legen die Messlatte für das, was wir als vollständige Einreichung betrachten, höher. Künftig werden Berichte strenger anhand dieser Kriterien bewertet:
- Ein funktionierender Proof of Concept mit nachgewiesenen Auswirkungen auf die Sicherheit. Zeigen Sie uns die Auswirkungen, beschreiben Sie sie nicht nur. Was könnte ein Angreifer eigentlich erreichen? Wir brauchen einen funktionierenden Proof of Concept, der die tatsächliche Ausnutzung und konkrete Auswirkungen auf die Sicherheit nachweist. Zeigen Sie uns die Grenze, die überschritten werden kann, und nicht nur, dass es eine theoretisch gibt. Wenn in Ihrem Bericht steht „Dies könnte zu … führen“, aber nicht angegeben wird, dass dies der Fall ist, ist er unvollständig.
- Bewusstsein über den Umfang und die unzulässigen Ergebnisse. Überprüfen Sie vor dem Einreichen unseren Umfang und Liste der nicht zulässigen Ergebnisse. Berichte zu bekannten nicht zulässigen Kategorien (DMARC/SPF/DKIM-Konfiguration, Benutzeraufzählung, fehlende Sicherheitsheader ohne nachgewiesenen Angriffspfad und andere) werden als „Nicht anwendbar“ geschlossen, was sich auf Ihr HackerOne-Signal und Ihren Ruf auswirken kann.
- Validierung vor der Übermittlung. Unabhängig davon, welche Tools Sie verwenden (Scanner, statische Analyse, KI-Assistenten), müssen Sie die Ausgabe vor der Übermittlung validieren. Ein falsch positives Ergebnis, das manuell überprüft wurde, wird erkannt, bevor es Zeitverschwendung für irgendjemanden darstellt. Eines, bei dem das nicht der Fall ist, ist nur Lärm.
Wir begrüßen KI in der Sicherheitsforschung
Wir möchten dies ausdrücklich betonen: Wir haben kein Problem damit, dass Forscher KI-Tools verwenden. 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üßen es.
Was wir brauchen, ist derselbe Standard, den wir immer erwartet haben: Validierung. Ein KI-gestützter Befund, der verifiziert, reproduziert und mit einem funktionierenden Machbarkeitsnachweis eingereicht wurde, ist eine großartige Einreichung. Eine nicht validierte Ausgabe, die im Ist-Zustand ohne Vervielfältigung 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ür die Richtigkeit der Einreichung verantwortlich.
Wir bitten die Forscher außerdem, die Berichte prägnant und strukturiert zu halten. Ein aussagekräftiger Bericht besteht aus drei Dingen: einer kurzen Zusammenfassung des Problems, klaren Schritten zur Reproduktion mit unterstützenden Beweisen (Screenshots, HTTP-Anfragen, Terminalausgabe) und einer Auswirkungserklärung, die erklärt, was ein Angreifer tatsächlich erreichen kann. Das ist es. Ausführliche Berichte wie mehrseitige theoretische Erzählungen, ausgeruhter Hintergrundkontext oder KI-generierte Füllmaterialien verlangsamen die Triage, da der eigentliche Befund untergeht. Je klarer und direkter Ihr Bericht, desto schneller können wir darauf reagieren.
Die Werkzeuge spielen keine Rolle. Die Qualität der Arbeit stimmt.
Das Sicherheitsmodell von GitHub verstehen: Geteilte Verantwortung
Ein Muster, das wir häufig beobachten, verdient eine eigene Diskussion. Viele Berichte beschreiben Szenarien, in denen ein Benutzer mit vom Angreifer kontrollierten Inhalten interagiert (ein bösartiges Repository, ein manipuliertes Problem, nicht vertrauenswürdiger Code) und ein unerwünschtes Ergebnis erlebt. Diese Berichte sind oft gut geschrieben und in ihren Beobachtungen technisch korrekt, aber sie verstehen falsch, wo die Sicherheitsgrenze liegt.
Wir investieren stark in Systeme und Teams, die sich der Erkennung und Handhabung bösartiger Inhalte auf der gesamten Plattform widmen, vom automatisierten Scannen bis zur manuellen Überprüfung. Allerdings arbeitet GitHub nach einem Modell der geteilten Verantwortung. Benutzer sind verantwortlich für:
- Auswählen, welchen Repositories, Problemen und Codes sie vertrauen. GitHub hostet über 600 Millionen Repositories. Nicht alle davon sind harmlos. Von Benutzern wird erwartet, dass sie ein Urteil darüber fällen, womit sie interagieren.
- Überprüfen von Inhalten vor der Ausführung oder Interaktion mit ihnen. Dies gilt für Code, Skripte, Workflows und alle anderen ausführbaren Inhalte.
- Zu verstehen, dass das Klonen eines Repositorys die Entscheidung bedeutet, diesem Code zu vertrauen. Git-Hooks, Build-Skripts und andere Automatisierungen auf Repository-Ebene werden ausgeführt, weil der Benutzer sich entschieden hat, dieses Repository auszuchecken.
- Die eigene Umgebung sicher konfigurieren. Token-Verwaltung, Anmeldeinformationsspeicherung und lokale Sicherheitseinstellungen liegen in der Verantwortung des Benutzers.
Wenn ein „Angriff“ erfordert, dass das Opfer aktiv nach vom Angreifer kontrollierten Inhalten sucht und mit ihnen interagiert (ein bösartiges Repo klonen, ein KI-Tool mit der Analyse nicht vertrauenswürdigen Codes beauftragen, eine manipulierte Datei öffnen), ist die Sicherheitsgrenze die Entscheidung des Benutzers, diesem Inhalt zu vertrauen. Diese Szenarien stellen im Allgemeinen keine Umgehung der Sicherheitskontrollen von GitHub dar.
Häufige Beispiele
Um Forschern bei der Kalibrierung zu helfen, sehen wir hier regelmäßig Muster, die in die gemeinsame Verantwortung fallen:
| Szenario | Warum es geteilte Verantwortung ist |
|---|---|
| Sofortige Injektion über Inhalte, die der Benutzer ausgewählt hat, um sie einem KI-Tool zuzuführen | Der Benutzer hat beschlossen, darauf zu vertrauen Inhalt |
| Git-Hooks oder Filter, die Code in einem Repository ausführen, das der Benutzer ausgecheckt hat | So funktioniert Git von Natur aus |
| Schädliche Inhalte in einem Repository, das der Benutzer geklont hat | Klonen ist ein Akt des Vertrauens |
| LLM erzeugt unerwartete Ausgaben, wenn nicht vertrauenswürdige Eingaben verarbeitet werden | Der Benutzer hat ausgewählt um diese Eingabe bereitzustellen |
Die Forschung in diesen Bereichen ist immer noch äußerst wertvoll. Wenn Sie glauben, einen blinden Fleck in unseren Abwehrmaßnahmen gefunden zu haben (eine Möglichkeit, eine tatsächliche Sicherheitskontrolle zu umgehen, die Benutzer betrifft, ohne von ihnen zu verlangen, dass sie schädlichen Inhalten aktiv vertrauen), dann möchten wir genau das hören. Diese Ergebnisse gehören zu den wirkungsvollsten Einsendungen, die wir erhalten. Und wenn Sie auf Inhalte stoßen, die gegen unsere Nutzungsbedingungen verstoßen, melden Sie diese bitte.
Was das für Forscher bedeutet
Wenn Sie bereits hochwertige Forschungsergebnisse einreichen, vielen Dank. Für Sie ändert sich nichts außer schnelleren Reaktionszeiten, da wir den Warteschlangenlärm reduzieren.
Wenn Sie neu bei Bug Bounty sind, herzlich willkommen! Nehmen Sie sich ein paar Minuten Zeit, um unseren Leistungsumfang durchzulesen, die Liste der nicht förderfähigen Angebote zu überprüfen und vor der Einreichung in einen funktionierenden Proof of Concept zu investieren. Qualitativ hochwertige Beiträge von neuen Forschern werden immer geschätzt und geschätzt.
Wenn Sie der Lautstärke Priorität eingeräumt haben, würden wir eine Verlagerung in Richtung Tiefe empfehlen. Eine gut recherchierte, validierte Entdeckung ist mehr wert als 10 spekulative Entdeckungen, sowohl in Bezug auf die Prämienauszahlung als auch auf den Ruf. Die Forscher, die am meisten mit unserem Programm verdienen, sind diejenigen, die in die Tiefe gehen.
Änderungen an der Art und Weise, wie wir Ergebnisse mit geringem Risiko belohnen
Nicht jede gültige Übermittlung stellt ein erhebliches Sicherheitsrisiko dar. In einigen Berichten werden Verbesserungsmöglichkeiten oder Dokumentationslücken identifiziert, die zwar nicht ausgenutzt werden können, aber dennoch zu Verbesserungen führen, die wir vornehmen möchten. Wir schätzen diese Arbeit.
Zukünftig aktualisieren wir die Art und Weise, wie wir mit diesen Fällen umgehen. Einsendungen, die keine nennenswerten Auswirkungen auf die Sicherheit haben, aber dennoch zu einer Korrektur des Codes oder der Dokumentation führen, werden mit einem GitHub-Swag und nicht mit einer Prämienauszahlung gewürdigt. Dadurch können wir den Beitrag anerkennen und uns gleichzeitig mit unseren großzügigen Ressourcen auf die Erkenntnisse konzentrieren, die den größten Einfluss auf die Plattformsicherheit haben.
Wir möchten lieber, dass Forscher ihre Zeit in tiefergehende, wirkungsvolle Forschung investieren und entsprechend entlohnt werden, als bei risikoarmen Erkenntnissen auf Volumen zu optimieren.
Blick nach vorne
Wir sind bestrebt, das Bug-Bounty-Programm von GitHub zu einem der besten der Branche zu machen, sowohl für Forscher als auch für die Sicherheit der Plattform. Das bedeutet eine schnellere Triage, eine klarere Kommunikation und die Sicherstellung, dass gültige Ergebnisse die Aufmerksamkeit und Vergütung erhalten, die sie verdienen. Die Erhöhung der Qualitätsstandards ist Teil dieser Investition.
Sicherheitsforscher machen GitHub für jeden Entwickler, der darauf angewiesen ist, sicherer. Diese Arbeit ist wichtig und wir halten sie nicht für selbstverständlich.
Viel Spaß beim Hacken! 🚀
Der Beitrag Die Messlatte höher legen: Qualität, gemeinsame Verantwortung und die Zukunft des Bug-Bounty-Programms von GitHub erschien zuerst auf The GitHub Blog.
Bir yanıt yazın