allstar
v4.2
Allstar ist eine GitHub-App, die GitHub-Organisationen oder Repositorys kontinuierlich auf die Einhaltung bewährter Sicherheitspraktiken überwacht. Wenn Allstar einen Verstoß gegen die Sicherheitsrichtlinien erkennt, erstellt es ein Problem, um den Repository- oder Organisationseigentümer zu benachrichtigen. Bei einigen Sicherheitsrichtlinien kann Allstar auch automatisch die Projekteinstellung ändern, die den Verstoß verursacht hat, und sie auf den erwarteten Zustand zurücksetzen.
Das Ziel von Allstar ist es, Ihnen eine fein abgestimmte Kontrolle über die Dateien und Einstellungen zu geben, die sich auf die Sicherheit Ihrer Projekte auswirken. Sie können auswählen, welche Sicherheitsrichtlinien sowohl auf Organisations- als auch auf Repository-Ebene überwacht werden sollen und wie mit Richtlinienverstößen umgegangen werden soll. Sie können auch neue Richtlinien entwickeln oder beisteuern.
Allstar wird als Teil des OpenSSF Scorecard-Projekts entwickelt.
Wenn Sie unerwünschte Probleme erhalten, die von Allstar verursacht werden, befolgen Sie diese Anweisungen, um sich abzumelden.
Allstar ist hochgradig konfigurierbar. Es gibt drei Hauptkontrollebenen:
Diese Konfigurationen werden im .allstar Repository der Organisation vorgenommen.
Repo-Ebene: Repository-Betreuer in einer Organisation, die Allstar verwendet, können wählen, ob sie für ihr Repository die Durchsetzung auf Organisationsebene aktivieren oder deaktivieren möchten. Hinweis: Diese Steuerelemente auf Repo-Ebene funktionieren nur, wenn „Repo-Override“ in den Einstellungen auf Organisationsebene zulässig ist. Diese Konfigurationen werden im .allstar Verzeichnis des Repositorys vorgenommen.
Richtlinienebene: Administratoren oder Betreuer können auswählen, welche Richtlinien für bestimmte Repos aktiviert sind und welche Maßnahmen Allstar ergreift, wenn gegen eine Richtlinie verstoßen wird. Diese Konfigurationen werden in einer Richtlinien-YAML-Datei entweder im .allstar Repository der Organisation (Admins) oder im .allstar Verzeichnis des Repositorys (Maintainer) vorgenommen.
Bevor Sie Allstar auf Organisationsebene installieren, sollten Sie ungefähr entscheiden, auf wie vielen Repositorys Allstar ausgeführt werden soll. Dies hilft Ihnen bei der Wahl zwischen der Opt-In- und der Opt-Out-Strategie.
Mit der Opt-In-Strategie können Sie die Repositorys, auf denen Allstar ausgeführt werden soll, manuell hinzufügen. Wenn Sie keine Repositories angeben, läuft Allstar trotz Installation nicht. Wählen Sie die Opt-In-Strategie, wenn Sie Richtlinien nur für eine kleine Anzahl Ihrer gesamten Repositorys erzwingen möchten oder Allstar an einem einzelnen Repository testen möchten, bevor Sie es für weitere aktivieren. Seit der Version v4.3 werden Globs unterstützt, um problemlos mehrere Repositorys mit einem ähnlichen Namen hinzuzufügen.
Die Opt-Out-Strategie (empfohlen) aktiviert Allstar für alle Repositorys und ermöglicht Ihnen die manuelle Auswahl der Repositorys, um sich von Allstar-Durchsetzungen abzumelden. Sie können sich auch dafür entscheiden, alle öffentlichen Repos oder alle privaten Repos abzulehnen. Wählen Sie diese Option, wenn Sie Allstar auf allen Repositorys in einer Organisation ausführen möchten oder nur eine kleine Anzahl von Repositorys oder einen bestimmten Repository-Typ (z. B. öffentlich oder privat) ausschließen möchten. Seit der Version v4.3 werden Globs unterstützt, um problemlos mehrere Repositorys mit einem ähnlichen Namen hinzuzufügen.
| Abmelden (empfohlen) optOutStrategy = true | Melden Sie sich an optOutStrategy = false | |
|---|---|---|
| Standardverhalten | Alle Repos sind aktiviert | Es sind keine Repos aktiviert |
| Manuelles Hinzufügen von Repositorys | Durch das manuelle Hinzufügen von Repos wird Allstar für diese Repos deaktiviert | Durch manuelles Hinzufügen von Repos wird Allstar für diese Repos aktiviert |
| Zusätzliche Konfigurationen | optOutRepos: Allstar wird auf den aufgelisteten Repos deaktiviert optOutPrivateRepos: Wenn „true“, wird Allstar auf allen privaten Repos deaktiviert optOutPublicRepos: Wenn „true“, wird Allstar auf allen öffentlichen Repos deaktiviert (optInRepos: Diese Einstellung wird ignoriert) | optInRepos: Allstar wird auf den aufgelisteten Repos aktiviert (optOutRepos: Diese Einstellung wird ignoriert) |
| Repo-Überschreibung | Wenn wahr: Repos können sich von den Allstar-Durchsetzungen ihrer Organisation abmelden, indem sie die Einstellungen in ihrer eigenen Repo-Datei verwenden. Opt-in-Einstellungen auf Organisationsebene, die für dieses Repository gelten, werden ignoriert. Bei „false“: Repos können die auf Organisationsebene konfigurierten Allstar-Durchsetzungen nicht deaktivieren. | Wenn wahr: Repos können sich für die Allstar-Durchsetzungen ihrer Organisation entscheiden, auch wenn sie auf Organisationsebene nicht für das Repo konfiguriert sind. Opt-out-Einstellungen auf Organisationsebene, die für dieses Repository gelten, werden ignoriert. Bei „falsch“: Repos können sich nicht für Allstar-Durchsetzungen entscheiden, wenn diese nicht auf Organisationsebene konfiguriert sind. |
Sowohl die Schnellstart- als auch die manuelle Installationsoption beinhalten die Installation der Allstar-App. Sie können die angeforderten Berechtigungen überprüfen. Die App fordert Lesezugriff auf die meisten Einstellungen und Dateiinhalte an, um die Einhaltung von Sicherheitsbestimmungen zu erkennen. Es fordert Schreibzugriff auf Issues und Prüfungen an, damit es Issues erstellen und die block zulassen kann.
Diese Installationsoption ermöglicht es Allstar, die Opt-Out-Strategie für alle Repositorys in Ihrer Organisation zu verwenden. Alle aktuellen Richtlinien werden aktiviert und Allstar benachrichtigt Sie über Richtlinienverstöße, indem es ein Problem meldet. Dies ist der schnellste und einfachste Weg, Allstar zu nutzen, und Sie können alle Konfigurationen später noch ändern.
Aufwand: sehr einfach
Schritte:
.allstar einDas ist es! Alle aktuellen Allstar-Richtlinien sind jetzt für alle Ihre Repositorys aktiviert. Allstar erstellt ein Problem, wenn gegen eine Richtlinie verstoßen wird.
Informationen zum Ändern von Konfigurationen finden Sie in den manuellen Installationsanweisungen.
Diese Installationsoption führt Sie durch die Erstellung von Konfigurationsdateien gemäß der Opt-In- oder Opt-Out-Strategie. Diese Option bietet von Anfang an eine detailliertere Kontrolle über Konfigurationen.
Aufwand: mäßig
Schritte:
Jede Richtlinie kann mit einer Aktion konfiguriert werden, die Allstar ausführt, wenn festgestellt wird, dass ein Repository nicht den Konformitätsrichtlinien entspricht.
log : Dies ist die Standardaktion und wird tatsächlich für alle Aktionen ausgeführt. Alle Ergebnisse und Details der Richtlinienausführung werden protokolliert. Protokolle sind derzeit nur für den App-Betreiber sichtbar, Pläne zur Offenlegung dieser Protokolle sind in der Diskussion.issue : Diese Aktion erstellt ein GitHub-Problem. Pro Richtlinie wird nur ein Problem erstellt und der Text beschreibt die Details des Richtlinienverstoßes. Wenn das Problem bereits offen ist, wird es ohne Updates alle 24 Stunden mit einem Kommentar angepingt (derzeit nicht vom Benutzer konfigurierbar). Wenn sich das Richtlinienergebnis ändert, wird ein neuer Kommentar zum Problem hinterlassen und im Problemtext verlinkt. Sobald der Verstoß behoben ist, wird das Problem von Allstar innerhalb von 5–10 Minuten automatisch geschlossen.fix : Diese Aktion ist richtlinienspezifisch. Die Richtlinie nimmt die Änderungen an den GitHub-Einstellungen vor, um den Richtlinienverstoß zu beheben. Nicht alle Richtlinien können dies unterstützen (siehe unten).Vorgeschlagene, aber noch nicht umgesetzte Maßnahmen. Definitionen werden in Zukunft hinzugefügt.
block : Allstar kann eine GitHub-Statusprüfung festlegen und die Zusammenführung aller PR im Repository blockieren, wenn die Prüfung fehlschlägt.email : Allstar würde eine E-Mail an den/die Repository-Administrator(en) senden.rpc : Allstar sendet einen RPC an ein organisationsspezifisches System.Zur Konfiguration der Problemaktion stehen zwei Einstellungen zur Verfügung:
issueLabel ist auf Organisations- und Repository-Ebene verfügbar. Durch die Festlegung wird die standardmäßige allstar -Beschriftung überschrieben, die Allstar zur Identifizierung seiner Probleme verwendet.
issueRepo ist auf Organisationsebene verfügbar. Durch die Festlegung wird erzwungen, dass alle in der Organisation erstellten Probleme im angegebenen Repository erstellt werden.
Ähnlich wie bei der Allstar-App-Aktivierungskonfiguration werden alle Richtlinien mit einer Yaml-Datei entweder im .allstar Repository der Organisation oder im .allstar Verzeichnis des Repositorys aktiviert und konfiguriert. Wie bei der App sind Richtlinien standardmäßig aktiviert, auch die log führt nicht zu sichtbaren Ergebnissen. Eine einfache Möglichkeit, alle Richtlinien zu aktivieren, besteht darin, für jede Richtlinie eine Yaml-Datei mit folgendem Inhalt zu erstellen:
optConfig:
optOutStrategy: true
action: issue
Die Einzelheiten dazu, wie die fix für jede Richtlinie funktioniert, finden Sie weiter unten. Wenn unten weggelassen, ist die fix nicht anwendbar.
Die Konfigurationsdatei dieser Richtlinie heißt branch_protection.yaml und die Konfigurationsdefinitionen finden Sie hier.
Die Zweigschutzrichtlinie überprüft, ob die Zweigschutzeinstellungen von GitHub entsprechend der angegebenen Konfiguration korrekt eingerichtet sind. Im Problemtext wird beschrieben, welche Einstellung falsch ist. Informationen zum Korrigieren von Einstellungen finden Sie in der Dokumentation von GitHub.
Durch die fix werden die Zweigschutzeinstellungen so geändert, dass sie mit der angegebenen Richtlinienkonfiguration übereinstimmen.
Die Konfigurationsdatei dieser Richtlinie trägt den Namen binary_artifacts.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie umfasst den Scheck aus der Scorecard. Entfernen Sie das binäre Artefakt aus dem Repository, um die Compliance zu gewährleisten. Da die Scorecard-Ergebnisse ausführlich sein können, müssen Sie möglicherweise die Scorecard selbst ausführen, um alle detaillierten Informationen anzuzeigen.
Die Konfigurationsdatei dieser Richtlinie heißt codeowners.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie prüft, ob in Ihren Repositorys eine CODEOWNERS Datei vorhanden ist.
Die Konfigurationsdatei dieser Richtlinie heißt outside.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie prüft, ob externe Mitarbeiter entweder Administratorzugriff (Standard) oder Push-Zugriff (optional) auf das Repository haben. Nur Organisationsmitglieder sollten über diesen Zugriff verfügen, da nicht vertrauenswürdige Mitglieder andernfalls Einstellungen auf Administratorebene ändern und Schadcode begehen können.
Die Konfigurationsdatei dieser Richtlinie heißt security.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie überprüft, ob das Repository über eine Sicherheitsrichtliniendatei in SECURITY.md verfügt und diese nicht leer ist. Das erstellte Problem verfügt über einen Link zur GitHub-Registerkarte, mit deren Hilfe Sie eine Sicherheitsrichtlinie für Ihr Repository festlegen können.
Die Konfigurationsdatei dieser Richtlinie heißt dangerous_workflow.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie überprüft die GitHub Actions-Workflow-Konfigurationsdateien ( .github/workflows ) auf Muster, die mit bekanntem gefährlichem Verhalten übereinstimmen. Weitere Informationen zu dieser Prüfung finden Sie in der OpenSSF Scorecard-Dokumentation.
Die Konfigurationsdatei dieser Richtlinie heißt scorecard.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie führt alle in der checks aufgeführten Scorecard-Prüfungen aus. Alle durchgeführten Prüfungen müssen eine Punktzahl aufweisen, die der threshold entspricht oder darüber liegt. Weitere Informationen zu den einzelnen Prüfungen finden Sie in der OpenSSF Scorecard-Dokumentation.
Die Konfigurationsdatei dieser Richtlinie heißt actions.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie überprüft die GitHub Actions-Workflow-Konfigurationsdateien ( .github/workflows ) (und in einigen Fällen Workflow-Ausführungen) in jedem Repository, um sicherzustellen, dass sie den Regeln (z. B. Erfordernis, Verweigern) entsprechen, die in der Konfiguration auf Organisationsebene für das definiert sind Politik.
Die Konfigurationsdatei dieser Richtlinie heißt admin.yaml und die Konfigurationsdefinitionen finden Sie hier.
Diese Richtlinie prüft, ob allen Repositorys standardmäßig ein Benutzer oder eine Gruppe als Administrator zugewiesen sein muss. Sie können optional konfigurieren, ob Benutzer Administratoren (im Gegensatz zu Teams) sein dürfen.
Sehen Sie sich dieses Repo als Beispiel für die verwendete Allstar-Konfiguration an. Ziehen Sie als Organisationsadministrator eine README.md mit einigen Informationen darüber in Betracht, wie Allstar in Ihrer Organisation verwendet wird.
Standardmäßig wird erwartet, dass sich Konfigurationsdateien auf Organisationsebene, wie die obige Datei allstar.yaml , in einem .allstar Repository befinden. Wenn dieses Repository nicht vorhanden ist, wird das allstar Verzeichnis .github -Repositorys als sekundärer Speicherort verwendet. Zur Verdeutlichung für allstar.yaml :
| Vorrang | Repository | Weg |
|---|---|---|
| Primär | .allstar | allstar.yaml |
| Sekundär | .github | allstar/allstar.yaml |
Dies gilt auch für die Konfigurationsdateien auf Organisationsebene für die einzelnen Richtlinien, wie unten beschrieben.
Allstar sucht auch nach Richtlinienkonfigurationen auf Repo-Ebene im .allstar Repository der Organisation, unter dem Verzeichnis mit demselben Namen wie das Repository. Diese Konfiguration wird unabhängig davon verwendet, ob „Repo-Override“ deaktiviert ist.
Allstar sucht beispielsweise die Richtlinienkonfiguration für eine bestimmte Repo- myapp in der folgenden Reihenfolge:
| Repository | Weg | Zustand |
|---|---|---|
myapp | .allstar/branch_protection.yaml | Wenn „Repo-Override“ zulässig ist. |
.allstar | myapp/branch_protection.yaml | Alle Zeiten. |
.allstar | branch_protection.yaml | Alle Zeiten. |
.github | allstar/myapp/branch_protection.yaml | Wenn das .allstar Repo nicht existiert. |
.github | allstar/branch_protection.yaml | Wenn das .allstar Repo nicht existiert. |
Für Allstar- und Richtlinienkonfigurationsdateien auf Organisationsebene können Sie das Feld baseConfig angeben, um ein anderes Repository anzugeben, das die Basis-Allstar-Konfiguration enthält. Dies lässt sich am besten anhand eines Beispiels erklären.
Angenommen, Sie haben mehrere GitHub-Organisationen, möchten aber eine einzige Allstar-Konfiguration beibehalten. Ihre Hauptorganisation ist „acme“, und das Repository acme/.allstar enthält allstar.yaml :
optConfig :
optOutStrategy : true
issueLabel : allstar-acme
issueFooter : Issue created by Acme security team. Sie haben auch eine Satelliten-GitHub-Organisation mit dem Namen „acme-sat“. Sie möchten die Hauptkonfiguration wiederverwenden, aber zusätzlich einige Änderungen vornehmen, indem Sie Allstar in bestimmten Repositorys deaktivieren. Das Repository acme-sat/.allstar enthält allstar.yaml :
baseConfig : acme/.allstar
optConfig :
optOutRepos :
- acmesat-one
- acmesat-two Dadurch wird die gesamte Konfiguration von acme/.allstar als Basiskonfiguration verwendet, aber dann werden alle Änderungen in der aktuellen Datei zusätzlich zur Basiskonfiguration angewendet. Die hierbei angewendete Methode wird als JSON Merge Patch bezeichnet. Die baseConfig muss ein GitHub <org>/<repository> sein.
Siehe CONTRIBUTING.md
