Unter Sicherheit → Einstellungen finden Sie das Organisationsstandard und jedes Projekt folgt diesem Standard, bis ein eigenes Setup festgelegt wird; Den Standard verwenden setzt ihn wieder zurück. Inhaber und Administratoren können die Einstellungen ändern; Mitglieder sehen sie nur zur Einsicht.
Beobachten und Durchsetzen
Jede Schutzmaßnahme hat zwei getrennte Zustände:
- Beobachten: erkennen, protokollieren und anzeigen. Die Ergebnisse werden in der Rubrik Sicherheit angezeigt und im
Coroid SecurityPrüfung von Pull Requests werden sie gemeldet, ohne dass die Prüfung fehlschlägt. - Durchsetzen: führt zum Fehlschlagen der Prüfung. Eine Änderung, die eine Ergebnis mit der gewählten Schweregradstufe oder höher erzeugt, führt zum Fehlschlagen der Prüfung, und die Aufgaben von Coroid öffnen keinen Pull Request darüber hinaus.
Die Durchsetzung bietet pro Gültigkeitsbereich drei Optionen:
| Option | Bedeutung |
|---|---|
| Erben (der Standard) | Durchsetzen, sobald die Plattform-Bereitschaftsvoraussetzung der Schutzmaßnahme erfüllt ist. |
| Durchsetzen | Dasselbe, explizit für diesen Gültigkeitsbereich ausgewählt. |
| Nur beobachten | Die Prüfung nie zum Scheitern bringen, unabhängig von der Plattform. |
Jede Schutzmaßnahme startet im Modus „Beobachten“. Coroid aktiviert die Durchsetzung pro Schutzmaßnahme erst, nachdem diese die Bereitschaftsvoraussetzung erfüllt hat: Bei Abhängigkeiten die Abdeckungstests sowie eine Beobachtungsphase ohne falsche Blockierungen; bei Geheimnissen und Code-Regeln die unten beschriebene Kalibrierung sowie dieselbe Beobachtungsphase. Bis dahin beobachtet eine auf „Erben“ oder „Durchsetzen“ gesetzte Schutzmaßnahme, und die Einstellung wird entsprechend angezeigt. Sobald die Voraussetzung erfüllt ist, erhält jede Einstellung „Erben“ die Durchsetzung; wer „Nur beobachten“ gewählt hat, bleibt im Beobachtungsmodus.
„Durchsetzen“ bedeutet nicht, dass „GitHub das Zusammenführen verhindert“. GitHub blockiert das Zusammenführen nur, wenn das Repository die Coroid Security Prüfung erfordert. Siehe
GitHub-Berechtigungen und die Coroid-Sicherheitsprüfung.
Kalibrierte Regeln
Bei ausgeleckten Geheimnissen und Code-Scans wird die Durchsetzung nur mit Detektor-Versionen aktiviert, die die Kalibrierung bestanden haben: gemessene Genauigkeit und Vollständigkeit anhand einer gekennzeichneten Auswahl echter Code- und synthetischer Geheimnisdaten, eine Fehlblockierungsrate, die durch das Wiedergeben echter zusammengeführter Änderungen ermittelt wird, jeder gemeldete Fehler wird als Fall behandelt, der weiterhin bestehen muss, sowie 14 Tage Beobachtung ohne falsche Blockierungen.
Eine neue Detektor-Version übernimmt die Durchsetzung niemals automatisch. Die zuletzt genehmigte Version bleibt aktiv, während die neue Version parallel beobachtet, und die neue Version übernimmt erst, wenn ihre eigene Kalibrierung abgeschlossen ist. Falls keine genehmigte Version laufen kann, meldet die durchgesetzte Schutzmaßnahme ihre Nichtverfügbarkeit und die Prüfung schlägt fehl, anstatt unbemerkt zu bestehen.
Die Einstellungen
| Schutzmaßnahme | Umschalten | Anpassen |
|---|---|---|
| Anfällige Abhängigkeiten | Beobachten | Durchsetzen; „Durchsetzen ab“ (Standard: hoch) |
| Anfällige Abhängigkeiten beheben | Ein-/ausschalten | „Behebungsaufgaben ab“ (Standard: hoch); Limit für offene Behebungs-pull request pro Projekt (Standard: 5, bis zu 50); das Agentenstundenbudget gemäß Organisationsstandard |
| Ausgeleckte Geheimnisse | Beobachten | Durchsetzen. Nur im Organisationsstandard: Neue Geheimnisse blockieren und die größte analysierte Änderung. |
| Code-Scanning | Beobachten | Durchsetzen; Ihr eigener Scan-Befehl; die Liste der Regeln |
| Sicherheits-Rezension von Pull Requests | Beobachten | Durchsetzen; „Durchsetzen ab“ (Standard: hoch) |
| GitHub-Sicherheitswarnungen | Beobachten | Keine |
| Sicherheitsaudit | Ein-/ausschalten | Häufigkeit: täglich, wöchentlich (Standard) oder monatlich |
Einige Schutzmaßnahmen hängen von anderen ab:
- Sicherheits-Rezension von Pull Requests erfordert, dass die Coroid-Rezension für das Projekt in der Qualitätskontrolle aktiviert ist. Ist die Coroid-Rezension deaktiviert, wird dies in der Zeile angezeigt und die Schutzmaßnahme wirkt nicht.
- Anfällige Abhängigkeiten beheben im Organisationsstandard schaltet auch die integrierte Sicherheitsbehebungs-Anweisung ein und aus. Siehe Pull-Requests zur Behebung öffnen.
- Sicherheitsaudit folgt Ihrem Plan, sofern Sie es nicht ändern: Bei kostenpflichtigen Plänen aktiviert, bei kostenlosen Plänen deaktiviert. Siehe Sicherheitsaudit.
Die Sicherheit folgt immer den Vorgaben der Qualitätskontrolle.
Die Schutzmechanismen von Sicherheit hängen nicht von den Steuerungen der Qualitätskontrolle ab. Wenn die Option 'Anti-Slop' in der Qualitätskontrolle deaktiviert wird, werden nur die Qualitätsregeln ausgeschaltet – nicht die Code-Regeln der Sicherheit. Bei Pull Requests Coroid Security führt seinen eigenen Prüfungsvorgang durch, unabhängig davon, ob das Projekt ein veröffentlichtes Lieferdiagramm besitzt oder nicht.
Die Scanner-Konfiguration stammt aus Coroid.
Scanner werden mit der Konfiguration Coroid betrieben, die aus diesen Einstellungen sowie den in der Sicherheit akzeptierten Ausnahmen generiert wird – niemals aus Dateien der zu prüfenden Änderung. Eine Änderung, die die Scanner-Konfiguration hinzufügt oder bearbeitet (osv-scanner.toml,
.gitleaks.toml, .gitleaksignore, .github/secret_scanning.yml,
.secrets.baseline und ähnliche) wird unter der Konfiguration des Basis-Commits geprüft und erhält ein security.policy-changed Ergebnis. Eine Repository-Datei kann eine Ausnahme vorschlagen; diese wird erst wirksam, wenn ein Eigentümer oder Administrator sie in der Sicherheit akzeptiert. Die gleiche Regel gilt auch für die eigenen Korrektur-Aufgaben von Coroid: Ein Agent kann die eigene Prüfung nicht bestehen, indem er die ausgeschlossenen Elemente ändert.
Einstellungen werden zusammen mit der Organisation übertragen.
Die security Einstellungen gehören zum Einstellungspaket der Organisation, zusammen mit den anderen Qualitätsrichtlinien – ebenso wie das neueste Bedrohungsmodell jedes Projekts. Ausnahmen, Ergebnisse und Nachweise sind Resultate, keine Einstellungen, und werden daher nicht übertragen. Siehe Einstellungs-Portabilität.