Dokumentation

GitHub-Berechtigungen und die Coroid-Sicherheitsprüfung

Welche GitHub-App-Berechtigungen die Sicherheit nutzt und warum, wie sich die Coroid-Sicherheitsprüfung verhält, wie man sie erforderlich macht und wie die eigenen Sicherheitswarnungen von GitHub importiert werden.

Die Sicherheit arbeitet über die GitHub-App von Coroid. Diese Seite listet auf, was die App für die Sicherheit benötigt, was die Coroid Security Prüfung meldet, wie man GitHub dazu bringt, sie erforderlich zu machen, und wie die eigenen Sicherheitswarnungen von GitHub in der Sicherheit angezeigt werden.

Berechtigungen

Die Sicherheit nutzt die Berechtigungen, die die App bereits für Ihre Repositorys hat: Lesen von Code und Pull Requests sowie Schreiben von Prüfungen. Diese sind optional und fügen jeweils eine Funktion hinzu:

BerechtigungWas sie hinzufügtOhne diese Berechtigung
Merge-Warteschlangen: Nur-Lese-Zugriff, mit dem Merge-Gruppen-EreignisCoroid Security bei Commit-Aktionen in der Merge-WarteschlangeMerge-Warteschlangen erhalten kein Coroid Security Ergebnis
Dependabot-Warnungen: Nur-Lese-Zugriff, mit dem zugehörigen EreignisImportiert Dependabot-WarnungenNicht importiert
Code-Scanning-Warnungen: Nur-Lese-Zugriff, mit dem zugehörigen EreignisImportiert die GitHub-Code-Scanning-WarnungenNicht importiert
Geheimnis-Scan-Warnungen: Nur-Lese-Zugriff, mit dem zugehörigen EreignisImportiert die GitHub-Geheimnis-Scan-Warnungen, ohne die geheimen WerteNicht importiert

Wenn die App eine neue Berechtigung anfordert, bittet GitHub den Besitzer Ihrer Organisation, sie für die Installation zu akzeptieren. Bis dahin zeigt die Ansicht Sicherheit → Übersicht an, welche Repositorys die Berechtigung fehlen, mit einem Link zur Installation auf GitHub.

Coroid liest auch aus den Ereignissen von GitHub sowie durch Anfrage bei GitHub ab, ob jedes Repository öffentlich oder privat ist, um zu entscheiden, was dort veröffentlicht werden darf. Siehe Offenlegung.

Die Coroid-Sicherheitsprüfung

Coroid Security ist eine einzige Prüfung mit einem Namen – egal ob sie eigenständig oder als Teil des Delivery-Graphen des Projekts in der Qualitätskontrolle läuft – sodass ein Repository sie nur einmal erforderlich machen kann. Sie meldet die Schutzmechanismen, die jede Änderung überprüfen: Anfällige Abhängigkeiten und ausgelaufene Geheimnisse. Das schlimmere Ergebnis bestimmt das Gesamtergebnis. Code-Scanning-Berichte werden über die Prüfungen der Qualitätskontrolle gemeldet, und Sicherheits-Rezensionen über die Coroid-Rezensionsprüfung.

Sie läuft auf GitHub-Repositorys, die über die App verbunden sind:

  • wenn ein pull request-Pull-Request geöffnet, wiedereröffnet, aktualisiert oder zur Rezension bereit gemeldet wird;
  • bei jedem Commit in der Merge-Warteschlange, mit der Berechtigung für Merge-Warteschlangen;
  • wenn jemand sie auf GitHub erneut ausführt.

Sobald das Ereignis eintrifft, wird sie als im Gange angezeigt. Der Link zu ihren Details öffnet das Projekt in der Sicherheit.

Was sie meldet

ZustandErzwungenNur beobachten
Vollständige Abdeckung der Änderung, nichts auf oder über dem SchwellenwertErfolgErfolg
Ein Fund auf oder über dem SchwellenwertFehlerNeutral, mit Benennung
Der Scan ist fehlgeschlagen oder konnte nicht ausgeführt werden, eine Datei, die von der Änderung betroffen ist, wird nur teilweise abgedeckt, oder die Konfiguration konnte nicht gelesen werdenFehler, mit Angabe des Grundes und Hinweis zum erneuten AusführenNeutral, mit Angabe des Grundes
Kein Ergebnis innerhalb von 10 MinutenFehler, „Zeitüberschreitung“Neutral
Alle Schutzmechanismen für das Projekt sind deaktiviertNeutralNeutral

Sie wird niemals als „übersprungen“ gekennzeichnet: GitHub zählt eine übersprungene erforderliche Prüfung als bestanden, sodass ein erzwungener Schutz, der nicht ausgeführt wurde, als Bestehen angezeigt wird. Eine erforderliche Prüfung liefert immer eines der oben genannten Ergebnisse, sodass die Merge-Warteschlange nie ewig wartet.

Die Prüfung berücksichtigt nur das, was die Änderung einführt, nicht die Funde, die bereits im Basis-Branch vorhanden sind. Ihr Text nennt niemals einen Fund, der nicht öffentlich ist; er gibt an, wie viele gefunden wurden, bei welchem Schwellenwert und dass die Details auf Coroid zu finden sind.

Die Coroid-Sicherheitsprüfung erforderlich machen

Ein erzwungener Schutz führt dazu, dass die Prüfung fehlschlägt. GitHub blockiert das Zusammenführen nur, wenn das Repository die Prüfung erforderlich macht:

  1. Branch-Schutz: in den Repository-Einstellungen → Branches die Regel für Ihren Standard-Branch bearbeiten und aktivieren Erfordert, dass Statusprüfungen vor dem Zusammenführen bestanden werden“, und „ Coroid Security.
  2. Regelsätze: In Einstellungen → Regeln → Regelsätze einen neuen Regelsatz für Ihren Standard-Branch hinzufügen, „Erfordert, dass Statusprüfungen bestanden werden“ dem Regelsatz hinzufügen, und Coroid Securitydie GitHub-App von Coroid als Quelle auswählen.
  3. Merge-Warteschlangen: Die Prüfung in derselben Regel erforderlich machen. Die App benötigt die Berechtigung für Merge-Warteschlangen, damit die Prüfung bei Commit-Aktionen in der Merge-Warteschlange ausgeführt wird.

Erfordern Sie diese Einstellung, sobald die zu erzwingenden Schutzmaßnahmen aktiv sind. Eine erforderliche Prüfung, die lediglich Beobachtungen vornimmt, gilt dennoch als bestanden.

GitHub-Sicherheitswarnungen

Mit GitHub-Sicherheitswarnungen aktivieren Sie diese in Sicherheit → Einstellungen sowie die oben genannten Berechtigungen. Anschließend übernimmt die Sicherheitsfunktion die Warnungen von Dependabot, Code Scanning und Secret Scanning als Beobachtungen zu denselben Befunden, die auch die eigenen Scans von Coroid liefern. Neue Warnungen werden übermittelt, sobald GitHub sie sendet, und Coroid prüft die Warnungen jedes Repositorys täglich erneut.

  • Importiert, nicht bestätigt. Eine Warnung, die durch die eigenen Scans von Coroid noch nicht bestätigt wurde, wird mit dem Hinweis „Aus GitHub importiert, noch nicht bestätigt“ gekennzeichnet. Sie wird aufgelistet und gezählt, gibt jedoch keine Benachrichtigung aus und blockiert nichts, bis der Scan von Coroid sie bestätigt hat.
  • Die Quellen stimmen nicht überein. Wenn GitHub und Coroid ein Befund unterschiedlich melden, wird dies im jeweiligen Befund angezeigt sowie der Status jeder Quelle: vorhanden, entfernt, ignoriert oder nicht lesbar.
  • Jede Quelle schließt einen Befund auf ihre eigene Weise. Eine Dependabot-Warnung wird bei GitHub als behoben markiert, sobald die verwundbare Version nicht mehr im Standardzweig vorhanden ist. Eine Code Scanning-Warnung gilt als behoben, wenn die Analyse des Standardzweigs sie nicht mehr meldet. Eine Secret Scanning-Warnung bleibt offen, bis jemand sie auf GitHub löst – das Zusammenführen einer Korrektur schließt sie daher nicht.
  • Fehlende Berechtigung. Falls die App eine Berechtigung verliert oder GitHub eine Funktion deaktiviert, werden die Befunde, die nur von dieser Quelle gemeldet wurden, ab diesem Zeitpunkt mit dem Status „Status unbekannt seit“ gekennzeichnet – und nichts wird geschlossen.

In der Übersicht wird pro Repository und Quelle angezeigt, ob die Warnungen bereits gelesen wurden, ob die Berechtigung fehlt, ob die Funktion auf GitHub deaktiviert ist oder ob das Repository nicht erreichbar war.