Offenlegung

Die Offenlegung der Details einer Schwachstelle vor Verfügbarkeit des Fixes nützt Angreifern mehr als Verteidigern. Die Funktion Sicherheit speichert die Details jedes nicht öffentlichen Fundes innerhalb von Coroid, und nur eine berechtigte Person entscheidet, wann diese Details preisgegeben werden.

Öffentlich und nicht öffentlich#

Jeder Fund gehört zu einer von zwei Kategorien:

• Öffentlich: Die Schwachstelle ist bereits öffentlich bekannt, beispielsweise eine Abhängigkeit mit einem veröffentlichten Advisory. In Fix-Pull-Requests kann das Advisory genannt werden.
• Nicht öffentlich: Alles andere, etwa ein von der Prüfung, der Coroid Rezension oder einer Code-Regel in Ihrem eigenen Code entdecktes Problem oder ein geleaktes Zugangsdaten.

Ein Fund ist nur dann öffentlich, wenn er mit einem nicht zurückgezogenen veröffentlichten Advisory verknüpft ist oder wenn ein Eigentümer oder Administrator seinen privaten Fix veröffentlicht (siehe unten).

Das Veröffentlichungs-Gateway#

Alles, was Coroid außerhalb von Coroid veröffentlicht, muss zuerst das Veröffentlichungs-Gateway durchlaufen: Rezensionsgremien, Inline-Rezensionskommentare und -zusammenfassungen, Prüfungsergebnisse und deren Anmerkungen, Titel und Beschreibungen von pull request, Commit-Nachrichten, Issue-Kommentare, Slack- und E-Mail-Nachrichten sowie Exporte. Das Gateway prüft den Text auf jegliche Sicherheitsprobleme, bestätigt oder nicht.

In einem öffentlichen Repository oder einem, dessen Sichtbarkeit Coroid nicht bestätigen kann, wird ein nicht öffentliches Problem durch eine neutrale Zeile mit einem Link ersetzt:

Coroid hat ein mögliches Sicherheitsproblem festgestellt; die Details finden Sie in Coroid.

In einem privaten Repository, wird der Text veröffentlicht. Ein noch nicht bestätigtes Problem wird mit „Unbestätigte Sicherheitsaussage: Coroid hat dies noch nicht überprüft.“ gekennzeichnet.

Zugangsdaten werden überall immer maskiert. Siehe Gekannte Geheimnisse.

Repository-Sichtbarkeit#

Coroid betrachtet ein Repository nur dann als privat, wenn es eine klare, aktuelle Angabe gibt, dass es privat ist – aus Ereignissen von GitHub oder durch direkte Anfrage bei GitHub, maximal ein Stunde alt. Ein internes Repository gilt als öffentlich. Wenn Coroid dies nicht feststellen kann, behandelt es das Repository als öffentlich.

Benachrichtigungen und Exporte#

• Glocke: Bei einem nicht öffentlichen Fund nennt die Glocke nur die Schwere und das Projekt, beispielsweise „Ein kritischer Fund erfordert Aufmerksamkeit“, mit einem Link zum Fund in der Funktion Sicherheit.
• Slack und E-Mail enthalten nur eine Zeile, die darauf hinweist, dass ein Fund Aufmerksamkeit benötigt, sowie den Link. Sie enthalten niemals die Schwachstelle oder den Code.
• Exporte: Der CycloneDX-Export listet Schwachstellen nur für öffentliche Funde auf. Das Organisations-Einstellungspaket enthält überhaupt keine Funde.

Fixen in einem öffentlichen Repository#

In einem privaten Repository ist ein Fix für einen nicht öffentlichen Fund ein normaler pull request. Seine Commit-Nachrichten und Beschreibungen beschreiben den Fix, nicht den Angriff.

In einem öffentlichen Repository oder einem, dessen Sichtbarkeit Coroid nicht bestätigen kann, würde ein öffentlicher pull request, Branch oder Commit das Problem vor dem Fix offenlegen. Daher commitet Coroid einen solchen Fix dort überhaupt nicht. Die Fix-Aufgabe wird mit einem Grund abgebrochen, der keine Details zum Fund nennt; die vorbereitete Änderung wird als privater Fix.

Private Fixes#

Ein Fund mit einem privaten Fix wird unter Private Fixesangezeigt. Nur Eigentümer und Administratoren sehen ihn.

• Fix herunterladen speichert die vorbereitete Änderung als .patch Datei, um sie selbst zu überprüfen oder anzuwenden.
• Veröffentlichen zeichnet auf, dass der Fund nun offengelegt ist, und erstellt eine Aufgabe, die die vorbereitete Änderung unverändert anwendet und ihren pull request öffnet. Veröffentlichen Sie den Fix und das Problem, wenn Sie bereit sind – beispielsweise wenn ein koordinierter Release-Termin erreicht ist. Ein zu großer Fix, der nicht über Coroid veröffentlicht werden kann, kann trotzdem heruntergeladen und manuell angewendet werden.
• Löschen löscht die vorbereitete Änderung.

Die Veröffentlichung und das Löschen werden im Audit-Log der Organisation festgehalten; beide Vorgänge löschen die vorbereitete Änderung aus Coroid.

Ein privater Fix, den niemand veröffentlicht oder löscht, wird für begrenzte Zeit aufbewahrt. Nach 180 Tagen werden Eigentümer und Administratoren daran erinnert. Nach 365 Tagen wird er gelöscht und sie werden darüber informiert.

Geplant#

• Sicherheitskontakte pro Projekt, die zusammen mit Eigentümern und Administratoren private Fixes überprüfen und veröffentlichen können.
• GitHub private Forks: Ein Fix wird in einem privaten Fork des Sicherheits-Advisories eines GitHub-Repositories mit seinen Regressions-Tests vorbereitet – statt ihn in Coroid zu belassen.
• Berichte an Maintainer: Wenn eine Schwachstelle im Code einer Abhängigkeit vorliegt, wird ein privater Bericht für die jeweiligen Maintainer entworfen, der ausschließlich von einem Menschen versendet wird.