Coordinated vulnerability disclosure

Active theme: Light

← Richtlinien

GitLab: Richtlinie zur verantwortungsvollen Offenlegung

Bitte senden Sie eine E-Mail an security@gitlab.com, um Sicherheitslücken zu melden. Wir bestätigen den Eingang Ihres Schwachstellenberichts am nächsten Werktag und bemühen uns, Ihnen regelmäßig Neuigkeiten zu unserem Fortschritt zu senden. Wenn Sie wissen möchten, wie der Stand Ihrer Offenlegung ist, schreiben Sie uns gerne erneut. Wenn Sie Ihre Offenlegungs-E-Mail verschlüsseln möchten, bitten Sie uns per E-Mail um unseren PGP-Schlüssel.

Alternativ können Sie uns Ihren Bericht auch über HackerOne senden.

Bitte sehen Sie davon ab, für das Melden von Schwachstellen eine Vergütung zu verlangen. Wenn Sie möchten, würdigen wir Ihre verantwortungsvolle Offenlegung öffentlich. Wir versuchen außerdem, das vertrauliche Issue nach der Bekanntgabe der Schwachstelle öffentlich zu machen; ein Beispiel finden Sie in unserem Issue zur Funktion „Identität übernehmen“. HackerOne macht die Fehlerberichte außerdem nach 30 Tagen öffentlich, wenn keine der Parteien widerspricht; ein Beispiel ist der Bericht über ein persistentes XSS auf der Seite eines öffentlichen Projekts.

Es ist Ihnen nicht gestattet, auf GitLab.com selbst nach Schwachstellen zu suchen. GitLab ist Open-Source-Software; Sie können selbst eine Kopie installieren und dagegen testen. Sie können entweder CE, EE oder das GitLab Development Kit herunterladen. Wenn Sie testen möchten, ohne GitLab selbst einzurichten, kontaktieren Sie uns, um Zugriff auf einen Staging-Server zu vereinbaren.

Weitere Einzelheiten dazu, wie wir mit Sicherheitsreleases umgehen, finden Sie hier.

Auf unserer Website erfahren Sie mehr über Verfügbarkeit und Sicherheit von GitLab.com. Sicherheitsprobleme, die keine Schwachstellen sind, sind in unserem öffentlichen Issue-Tracker einsehbar.

Vertrauliche Issues

Wenn eine Schwachstelle entdeckt wird, erstellen wir ein vertrauliches Issue, um sie intern nachzuverfolgen. Sicherheits-Patches werden auf dev.gitlab.org gepusht, das nicht öffentlich zugänglich ist, und in den Branch security gemergt. Sie sollten auf GitLab.com erst erscheinen, wenn das Sicherheitsrelease angekündigt wurde und aktualisierte Pakete verfügbar sind.

Einzelheiten finden Sie in unserem Prozess für kritische Releases.