In diesem Leitfaden wird davon ausgegangen, dass du eine Testversion von GitHub Advanced Security für ein vorhandenes GitHub-Unternehmenskonto geplant und gestartet hast. Weitere Informationen findest du unter Planen einer Testversion von GitHub Advanced Security.
Einführung
Code scannings und die Abhängigkeitsanalyse funktionieren in öffentlichen Repositorys sowie in privaten und internen Repositorys bei Aktivierung von GitHub Advanced Security auf die gleiche Weise. Darüber hinaus kannst du mit GitHub Advanced Security Sicherheitskampagnen erstellen, in denen Fachkräfte für Sicherheit und Entwickelnde zusammenarbeiten können, um technische Schulden zu reduzieren.
In diesem Artikel wird erläutert, wie du diese Features mit Steuerelementen auf Unternehmensebene kombinieren kannst, um deinen Entwicklungsprozess zu standardisieren und zu erzwingen.
Optimieren deiner Sicherheitskonfigurationen
Im Gegensatz zum secret scanning, bei dem normalerweise eine einzelne Sicherheitskonfiguration auf alle Repositorys angewendet wird, musst du die code scanning-Konfiguration für verschiedene Repositorytypen optimieren. Beispielsweise musst du möglicherweise zusätzliche Konfigurationen erstellen, damit Folgendes zutrifft:
- Der Code scanning verwendet Runner mit einer bestimmten Bezeichnung, um die Anwendung auf Repositorys sicherzustellen, die eine spezielle Umgebung erfordern oder private Register verwenden.
- Für den Code scanning ist die Anwendung auf Repositorys, die ein erweitertes Setup verwenden müssen oder ein Drittanbietertool erfordern, nicht festgelegt.
Für deine Testversion ist es am einfachsten, eine primäre Sicherheitskonfiguration auf Unternehmensebene zu erstellen und du auf deine Testrepositorys anzuwenden. Anschließend kannst du alle zusätzlichen Sicherheitskonfigurationen erstellen, die du benötigst, und sie auf eine Teilmenge der Repositorys anwenden, die mit Codesprache, benutzerdefinierten Eigenschaften, Sichtbarkeit und anderen Filteroptionen ausgewählt wurden. Weitere Informationen findest du unter Aktivieren von Sicherheitsfeatures in deinem Testunternehmen und Anwenden einer benutzerdefinierten Sicherheitskonfiguration.
Gewähren des Zugriffs auf die Ergebnisse des code scanning
Standardmäßig können nur Repositoryadministrierende und Organisationsbesitzende alle code scanning-Warnungen in ihrem Bereich einsehen. Du solltest allen Organisationsteams und Benutzenden, die während der Testversion auf die Benachrichtigungen zugreifen möchten, die vordefinierte Sicherheitsmanager-Rolle zuweisen. Auch dem Besitzer des Enterprise-Kontos solltest du diese Rolle für jede Organisation in der Testversion zuweisen. Weitere Informationen findest du unter Verwalten von Sicherheitsmanagern in deiner Organisation und Verwenden von Organisationsrollen.
Auswerten und Optimieren von Ergebnissen des Standardsetups
Das Standardsetup für den code scanning führt eine Reihe von Abfragen mit hoher Konfidenz aus. Diese wurden ausgewählt, um sicherzustellen, dass den Entwickelnden beim Rollout des code scanning in deiner gesamten Codebasis nur eine begrenzte Anzahl qualitativ hochwertiger Ergebnisse mit wenigen falsch positiven Ergebnissen angezeigt wird.
Auf der Registerkarte Code security für das Unternehmen findest du eine Zusammenfassung aller Ergebnisse, die in den Organisationen in deinem Testunternehmen gefunden wurden. Es gibt auch separate Ansichten für jeden Sicherheitswarnungstyp. Weitere Informationen findest du unter Einblicke in die Sicherheit anzeigen.
Wenn die erwarteten Ergebnisse für den code scanning nicht angezeigt werden, kannst du das Standardsetup updaten, um eine erweiterte Abfragesuite für Repositorys auszuführen, bei denen du mehr Ergebnisse erwartet hast. Dies wird auf Repositoryebene gesteuert (siehe Bearbeiten der Konfiguration des Standardsetups).
Tip
Wenn die Bearbeitung der Repositoryeinstellungen für code scanning für dich gesperrt ist, bearbeite die vom Repository verwendete Sicherheitskonfiguration, sodass die Einstellungen nicht erzwungen werden.
Wenn die erweiterte Suite die erwarteten Ergebnisse immer noch nicht finden kann, musst du möglicherweise das erweiterte Setup aktivieren, damit du die Analyse vollständig anpassen kannst. Weitere Informationen findest du unter Informationen zur Toolstatusseite für die Codeüberprüfung und Konfigurieren des erweiterten Setups für das Codescanning.
Erzwingen der automatisierten Analyse von Pull Requests
Es gibt drei verschiedene Arten der automatisierten Analyse von Pull Requests, die in GitHub integriert sind:
- Die Code scanning-Analyse verwendet Abfragen, um bekannte fehlerhafte Programmiermuster und Sicherheitsrisiken hervorzuheben. Copilot Autofix schlägt Lösungen für Probleme vor, die über den code scanning identifiziert wurden.
- Die Abhängigkeitsüberprüfung fasst die vom Pull Request vorgenommen Abhängigkeitsänderungen zusammen und hebt alle Abhängigkeiten hervor, die bekannte Sicherheitsrisiken aufweisen oder die Entwicklungsstandards nicht erfüllen.
- Copilot-Code-Reviews verwenden KI, um Feedback mit vorgeschlagenen Korrekturen zu deinen Änderungen bereitzustellen (sofern möglich).
Diese automatisierten Reviews sind eine wertvolle Erweiterung für die selbstständige Überprüfung und bieten Entwickelnden die Möglichkeit, vollständigere und sicherere Pull Requests für Peer Reviews bereitzustellen. Darüber hinaus können code scannings und Abhängigkeitsüberprüfungen erzwungen werden, um die Sicherheit und Compliance deines Codes zu gewährleisten.
Note
GitHub Copilot Autofix ist in der Lizenz für GitHub Advanced Security enthalten. Copilot-Code-Reviews erfordern einen kostenpflichtigen Copilot-Plan.
Code scanning-Analyse
Wenn code scannings aktiviert sind, kannst du Merges in wichtige Branches blockieren (es sei denn, der Pull Request erfüllt deine Anforderungen), indem du Coderegelsätze für das Unternehmen oder die Organisation erstellst. In der Regel ist es erforderlich, dass Ergebnisse des code scanning vorhanden sind und wichtige Warnungen berücksichtigt werden.
- Regelsatztyp: Branch
- code scanning-Ergebnisse erfolgreich: Aktiviere diese Option, um Mergevorgänge zu blockieren, bis erfolgreich Ergebnisse für den Commit und die Referenz generiert wurden, die das Ziel des Pull Requests ist.
- Erforderliche Tools und Warnungsgrenzwerte: Definiere für jedes verwendete code scanning-Tool die Warnungsstufe, die behoben werden muss, bevor ein Pull Request gemergt werden kann.
Wie bei allen Regelsätzen kannst du genau steuern, für welche Organisationen (Unternehmensebene), Repositorys und Branches der Regelsatz angewendet werden soll. Zudem kannst du Rollen oder Teams definieren, die die Regel umgehen können. Weitere Informationen finden Sie unter Informationen zu Regelsätzen.
Abhängigkeitsüberprüfung
Wenn GitHub Advanced Security und das Abhängigkeitsdiagramm für ein Repository aktiviert ist, weisen Manifestdateien eine umfassende diff-Ansicht auf, die eine Zusammenfassung der hinzugefügten oder aktualisierten Abhängigkeiten bietet. Dies ist eine nützliche Zusammenfassung für menschliche Prüfer des Pull Requests, bietet jedoch keine Kontrolle darüber, welche Abhängigkeiten der Codebasis hinzugefügt werden.
Die meisten Unternehmen setzen automatische Prüfungen ein, um die Verwendung von Abhängigkeiten mit bekannten Sicherheitsrisiken oder nicht unterstützten Lizenzbedingungen zu blockieren.
- Erstelle ein privates Repository, das als zentrales Element dient, in dem du wiederverwendbare Workflows für das Unternehmen speichern kannst.
- Bearbeite die Aktionseinstellungen für das Repository, damit alle privaten Repositorys im Unternehmen auf Workflows in diesem zentralen Repository zugreifen können (siehe Gewähren des Zugriffs auf Komponenten in einem privaten Repository).
- Erstelle im zentralen Repository einen wiederverwendbaren Workflow zum Ausführen der Abhängigkeitsüberprüfungsaktion, um die Aktion so zu konfigurieren, dass sie deinen geschäftlichen Anforderungen entspricht (siehe Konfigurieren der Abhängigkeitsüberprüfungsaktion).
- Erstelle oder aktualisiere in jeder Organisation Branchregelsätze, um den neuen Workflow zu den erforderlichen Statusprüfungen hinzuzufügen (siehe Erzwingen der Abhängigkeitsüberprüfung in einer Organisation).
Auf diese Weise kannst du die Konfiguration an einem einzigen Speicherort aktualisieren, aber den Workflow in vielen Repositorys verwenden. Du musst dieses zentrale Repository verwenden, um andere Workflows zu verwalten. Weitere Informationen finden Sie unter Wiederverwenden von Workflows.
Copilot-Review
Note
- GitHub Copilot-Code Review is in public preview and subject to change.
- To participate in the public preview, an administrator of your organization must opt in to the use of previews of Copilot features. See Verwalten von Richtlinien für Copilot in Ihrer Organisation.
- Some functionality is available to all enabled Copilot subscribers, but other functionality is only available to a limited number of users. To join the waitlist for additional functionality, see Join the Copilot Code Review waitlist.
- The Lizenzbestimmungen für die Vorabversion von GitHub apply to your use of this product.
Standardmäßig fordern Benutzende Reviews von Copilot auf die gleiche Weise wie bei menschlichen Prüfern an. Du kannst jedoch einen Branchregelsatz auf Organisationsebene aktualisieren oder erstellen, um Copilot automatisch als Reviewer für alle Pull Requests hinzuzufügen, die für ausgewählte Branches oder in allen ausgewählten Repositorys verfügbar sind. Weitere Informationen finden Sie unter Verwenden des GitHub Copilot-Code-Reviews.
Copilot hinterlässt einen Reviewkommentar für jeden geprüften Pull Request, ohne den Pull Request zu genehmigen oder Änderungen anzufordern. Dadurch wird sichergestellt, dass Reviews konsultativ sind und die Entwicklungsarbeit nicht blockieren. Ebenso solltest du die Durchsetzung von Vorschlägen durch Copilot nicht erzwingen, da KI-Vorschläge bekannte Einschränkungen aufweisen (siehe Verantwortungsvolle Nutzung des GitHub Copilot-Reviews).
Definieren, wo Copilot Autofix zulässig und aktiviert ist
Copilot Autofix hilft Entwickelnden dabei, code scanning-Warnungen aus Pull Requests zu verstehen und zu berücksichtigen. Es wird empfohlen, dieses Feature für alle Repositorys zu aktivieren, damit Entwickelnde Warnungen effizient implementieren und ihr Verständnis für sicheres Programmieren erhöhen können.
Es gibt zwei Steuerungsebenen:
- Unternehmen können die Verwendung von Copilot Autofix im gesamten Unternehmen mithilfe der Richtlinie für Codesicherheit zulassen oder blockieren (siehe Erzwingen von Richtlinien für die Codesicherheit und -analyse für Unternehmen).
- Organisationen können Copilot Autofix für alle Repositorys im Besitz der Organisation in den globalen Einstellungen für die Organisation aktivieren oder deaktivieren (siehe Konfigurieren globaler Sicherheitseinstellungen für Ihre Organisation).
Einbinden von Entwickelnden in Vorgänge zur Gewährleistung der Sicherheit
Sicherheitskampagnen bieten eine Möglichkeit für Sicherheitsteams, mit Entwickelnden in Kontakt zu treten, um technische Schulden im Sicherheitsbereich zu reduzieren. Sie bieten auch eine praktische Möglichkeit, Schulungen für sicheres Programmieren mit Beispielen für anfälligen Code in Codebeispielen zu kombinieren, mit denen die Entwickelnden in deiner Organisation vertraut sind. Weitere Informationen findest du unter Informationen zu Sicherheitskampagnen und Bewährte Methoden zum Beheben von Sicherheitswarnungen im großen Stil.
Bereitstellen einer sicheren Entwicklungsumgebung
Die Entwicklungsumgebung umfasst viele Komponenten. Dies sind einige der nützlichsten Features für die Skalierung und Standardisierung einer sicheren Entwicklungsumgebung in GitHub:
- Sicherheitskonfigurationen: Definieren der Einrichtung von Sicherheitsfeatures für das Unternehmen, eine Organisation, eine Teilmenge von Organisationsrepositorys oder neue Repositorys (siehe Optimieren deiner Sicherheitskonfigurationen)
- Richtlinien: Schützen und Steuern der Verwendung von Ressourcen für das Unternehmen oder eine Organisation (siehe Erzwingen von Richtlinien für dein Unternehmen)
- Regelsätze: Schützen und Steuern von Branches, Tags und Pushes für eine Organisation, eine Teilmenge von Organisationsrepositorys oder ein Repository (siehe Erstellen von Regelsätzen für Repositorys in deiner Organisation)
- Repositoryvorlagen: Definieren der Sicherheitsworkflows und Prozesse, die für die verschiedenen Umgebungstypen erforderlich sind (siehe Eine Repository-Vorlage erstellen). Jede Vorlage kann beispielsweise eine spezielle Vorlage enthalten:
- Sicherheitsrichtliniendatei, die die Sicherheitsposition des Unternehmens definiert und vorgibt, wie Sicherheitsbedenken gemeldet werden
- Workflow zum Aktivieren von Dependabot version updates für Paket-Manager, die vom Unternehmen verwendet werden
- Workflow zum Definieren des erweiterten Setups für code scannings für unterstützte Entwicklungssprachen, bei denen die Standardsetupergebnisse nicht ausreichen
Wenn Entwickelnde ein Repository über eine Vorlage erstellen, müssen sie zudem den Wert aller erforderlichen benutzerdefinierten Eigenschaften definieren. Benutzerdefinierte Eigenschaften sind sehr nützlich, um eine Teilmenge von Repositorys auszuwählen, auf die du Konfigurationen, Richtlinien oder Regelsätze anwenden möchtest (siehe Verwalten von benutzerdefinierten Eigenschaften für Repositorys in deinem Unternehmen).
Nächste Schritte
Wenn du diese Optionen und secret scanning-Features erkundet hast, kannst du deine Erkenntnisse anhand deiner geschäftlichen Anforderungen testen und weitere Untersuchungen anstellen.