Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieses Handbuch enthält Setupschritte und andere Aktionen, mit denen Sie GitHub Advanced Security (GHAS) und Microsoft Defender for Cloud integrieren und dann das Ende der Integration überprüfen können. Die Integration trägt dazu bei, die cloudeigene Anwendungssicherheit Microsoft zu maximieren, indem Laufzeitrisiken und Kontext mit dem ursprünglichen Code korreliert werden, um eine schnellere KI-basierte Behebung zu ermöglichen.
Wenn Sie diesem Leitfaden folgen, führen Sie folgende Schritte aus:
- Richten Sie Ihr GitHub-Repository für Defender for Cloud-Unterstützung ein.
- Erstellen Sie einen Laufzeitrisikofaktor.
- Testen Sie echte Anwendungsfälle in Defender für Cloud.
- Verknüpfen Sie Code mit Laufzeitressourcen.
- Starten Sie eine Sicherheitskampagne auf GitHub. Diese Kampagne verwendet Laufzeitkontext, um GHAS-Sicherheitswarnungen zu priorisieren.
- Erstellen Sie GitHub-Issues von Defender for Cloud, um die Behebung zu starten.
- Schließen Sie die Schleife zwischen Engineering- und Sicherheitsteams.
Voraussetzungen
| Aspect | Details |
|---|---|
| Umweltanforderungen | - GitHub-Konto mit einem Connector, der in Defender für Cloud erstellt wurde - GitHub Advanced Security(GHAS)-Lizenz für verbundene Repositorys – Defender Cloud Security Posture Management (DCSPM)-Plan für das Abonnement aktiviert - Microsoft Security Copilot (optional für KI-gestützte automatisierte Wartung) |
| Rollen und Berechtigungen | – Berechtigungen für Sicherheitsadministratoren – Sicherheitsadministrator für das Azure-Abonnement (zum Anzeigen von Ergebnissen in Defender for Cloud) - GitHub Organisationsbesitzer (zum Verbinden von Repositorys und Konfigurieren von Sicherheitskampagnen) |
| Cloudumgebungen | – Nur in kommerziellen Clouds verfügbar (nicht in Azure Government, Azure, betrieben von 21Vianet oder anderen souveränen Clouds) |
Vorbereiten der Umgebung
Schritt 1: Einrichten des GitHub-Repositorys und Ausführen des Workflows
Verwenden Sie zum Testen der Integration Ihre eigenen Repositorys oder ein example Sandbox-Projekt mit einem Test-GitHub Repository mit allen Inhalten, um ein anfälliges Containerimage zu erstellen.
Melden Sie sich im Azure-Portal an.
Wechseln Sie zu Microsoft Defender for Cloud>DevOps Security.
Geben Sie Ihren Code-Repositorynamen in die Suchleiste ein (Beispiel: zava-webshop).
Überprüfen Sie, ob sie zu der Organisation gehört, die Sie überwachen, z. B. die Zava-Corporation-Organisation .
Überprüfen Sie, ob es Ergebnisse für das Repository gibt.
Stellen Sie sicher , dass der Status "Erweiterter Sicherheitsstatusaktiviert" ist. Dies gibt an, dass GitHub Advanced Security im überwachten Repository aktiviert ist.
Wenn Ihr Repository nicht gefunden wird, lesen Sie in der Microsoft Defender for Cloud-Dokumentation zur Problembehandlung und zum Onboarding für den GitHub-Connector nach.
Stellen Sie sicher, dass die agentlose Überprüfung für Ihren GitHub Connector aktiviert ist.
Schritt 2: Überprüfen, ob Ihre Umgebung bereit ist
Die Überprüfung bestätigt, dass Ihre Umgebung ordnungsgemäß konfiguriert ist, um Code für Laufzeitempfehlungen anzuzeigen und umsetzbare Ergebnisse zu generieren. Während dieses Schritts überprüft Defender folgendes:
Vollständiger Code zur Laufzeitsicht
- Microsoft Defender for Cloud überwacht kontinuierlich Quellcoderepositorys auf Sicherheitsrisiken.
- Build-Artefakte, wie z. B. Container-Images, werden vor der Bereitstellung in Container-Registries gescannt.
- Laufzeitarbeitslasten, die in Kubernetes-Clustern bereitgestellt werden, werden auf Sicherheitsrisiken überwacht.
- Defender for Cloud korreliert und verfolgt jedes Artefakt vom Code über Build und Bereitstellung bis hin zur Laufzeit und zurück.
Note
Es kann bis zu 24 Stunden dauern, nachdem die vorherigen Schritte angewendet wurden, bis die folgenden Ergebnisse angezeigt werden.
Testen Sie, dass GitHub agentloses Scannen das Repository erfasst.
Wechseln Sie zu Microsoft Defender for Cloud>Cloud Security Explorer und führen Sie die Abfrage aus. Die Überprüfungsabfragen testen, ob Defender Artefakte identifizieren können, die von Ihren Pipelines und Workloads erstellt wurden. Wenn die Abfragen Ergebnisse zurückgeben, gibt sie an, dass Scan und Korrelation erwartungsgemäß funktionieren.
Note
Wenn keine Ergebnisse zurückgegeben werden, kann es darauf hindeuten, dass Artefakte noch nicht erstellt wurden, das Scannen nicht konfiguriert ist oder Berechtigungen fehlen. Weitere Informationen finden Sie unter Benutzerrollen und Berechtigungen .
Überprüfen Sie, ob Defender für Cloud (in Azure Container Registry) das Containerimage gescannt und zum Erstellen eines Containers verwendet hat.
Fügen Sie in Ihrer Abfrage die Bedingungen für Ihre spezifische Bereitstellung hinzu.
Überprüfen Sie, ob der Container ausgeführt wird und dass Defender für Cloud den AKS-Cluster gescannt hat.
Überprüfen Sie, ob die Risikofaktoren auf der Defender für Cloud-Seite ordnungsgemäß konfiguriert sind. Suchen Sie in der Defender for Cloud-Bestandsübersicht nach Ihrem Containernamen, und er sollte als kritisch markiert sein.
Note
Dieser Schritt ist nur erforderlich, wenn Risikofaktoren nicht bereits in Ihrer Umgebung konfiguriert sind. Wenn Sie bereits Risikofaktoren verwenden, können Sie deren Konfiguration unter "Ressourcenkritische > Einstellungen" überprüfen.
Durch eine erfolgreiche Validierung wird sichergestellt, dass die nächsten Schritte, z. B. Empfehlungen, Kampagnen und GitHub Problemgenerierung, aussagekräftige Ergebnisse erzielen.
Note
Nachdem Sie Ihre Ressource als kritisch klassifiziert haben, kann es bis zu 12 Stunden dauern, bis Defender for Cloud die Daten an GitHub sendet. Weitere Informationen.
Schritt 3: Erstellen einer GitHub Kampagne
Um eine Scankampagne zu erstellen, müssen Sie auf GitHub Organisationsebene arbeiten. Diese Erfahrung steht nicht auf der ebene der einzelnen Repositorys zur Verfügung.
Wechseln Sie in GitHub zur GitHub-Organisation, die Sie für die Setuptests verwendet haben.
Wählen Sie Sicherheit>Kampagnen>Erstelle Kampagne>aus Code-Scan-Filtern.
Diese Kampagne hilft bei der Priorisierung von GHAS-Ergebnissen, die zu Code gehören, der wirklich bereitgestellt und ausgeführt wird.
Wählen Sie "Laufzeitrisiken"- Filter für die Kampagne aus.
Wählen Sie Speichern>Als Kampagne veröffentlichen aus. Geben Sie die erforderlichen Informationen ein, und veröffentlichen Sie dann die Kampagne.
Schritt 4: Empfehlungen mobilisierung
Verwenden Sie die Empfehlungen für laufende Container-VA, die Code-zu-Laufzeit-Funktionalität sowie die Korrelation der identifizierten CVEs mit Dependabot-Sicherheitswarnungen, um den Status von Sicherheitsproblemen zu verstehen. Anschließend können Sie dem relevanten Entwicklungsteam basierend auf der Code-zu-Laufzeit-Zuordnung die Empfehlung für die Lösung zuweisen.
Wechseln Sie im Defender für Cloud-Portal zur Registerkarte "Empfehlungen ".
Suchen Sie nach dem Namen des Containers, den Sie aus Dem Code-Repository erstellt haben.
Öffnen Sie eine der Updatesoftwareempfehlungen ; der Empfehlungsname beginnt mit "Update".
Wählen Sie die Registerkarte Zugeordnete CVEs. Sicherheitswarnungen erscheinen als Teil des Bewertungslaufs für Empfehlungen. Diese Warnungen enthalten Hinweise auf GitHub Advanced Security-Erkenntnisse, die bereits für das Engineering bekannt sind. Beachten Sie, dass einige CVE-IDs über eine 'View on GitHub'-Verknüpfung in der Spalte "Verwandte GitHub-Warnungen" verfügen.
Wählen Sie den Link aus, um die relevante GHAS-Sicherheitswarnung zu öffnen. (Um den GHAS-Warnungsinhalt in GitHub anzuzeigen, müssen Sie über Zugriffsberechtigungen für das relevante GitHub Repository verfügen. Wenn Sie nicht über Zugriffsberechtigungen verfügen, können Sie den Link für die nächste Verwendung jederzeit kopieren oder sich an Ihren GitHub-Administrator wenden.)
Wenn eine Warnmeldung erweitert wurde, gibt es eine entsprechende Dependabot-Warnmeldung, die dem Entwicklungsteam bereits bekannt ist. Wenn der Status "Aktiv" lautet, wurde er noch nicht behoben, und das Problem muss für einen Fix priorisiert werden.
Wenn keine Anreicherung gefunden wird, gibt dies ein Laufzeitrisiko an, das dem Engineering unbekannt ist, das für einen Fix priorisiert werden muss.
Wie geht es weiter? Wie würde ich wissen, wer das relevante Team für die Lösung ist? Wie würde ich wissen, welcher Kontext dem Engineering bei der Lösung helfen kann?
Erstellen eines GitHub Problems
Um die Schleife zwischen Sicherheits- und Entwicklungsteams zu schließen, können Sie ein GitHub-Problem erstellen, das die Sicherheitsprobleme priorisiert, auf die sich das Entwicklungsteam konzentrieren sollte. Diese Priorisierung kann die Einbeziehung von Ergebnissen umfassen, die GHAS nicht erkannt hat, die jedoch von Defender für Cloud für CVE-IDs identifiziert wurden, welche nicht Teil direkter Abhängigkeiten sind. Zu diesen Ergebnissen können Sicherheitsrisiken im Basisimage, Betriebssystem oder Software wie NGINX gehören.
Das GitHub Problem wird automatisch im Quellcode-Repository mit allen CVE-IDs generiert, die im Rahmen der Empfehlung zu finden sind, einschließlich anderer Laufzeit- und Container-SDLC-bezogene Kontexte, die beim Beheben und Testen hilfreich sind.
Aus der Empfehlungsansicht können Sie explizit ein GitHub Problem generieren, um Korrekturarbeiten nachzuverfolgen.
Wechseln Sie zur Registerkarte "Korrektureinblicke ", und zeigen Sie das Code-zu-Laufzeit-Diagramm an. Das Diagramm ordnet Ihren laufenden Container dem Containerimage im Code-Repository und dem ursprünglichen Code-Repository in GitHub zu.
Überprüfen Sie auf der Registerkarte Erkenntnisse zur Problembehebung den betroffenen Runtime-Kasten.
Validate, ob bereits ein GitHub Problem vorhanden ist. Wenn bereits ein GitHub Problem vorhanden ist, wird im Feld ein GitHub-Symbol angezeigt. Zeigen Sie mit der Maus auf das Symbol, um Problemdetails anzuzeigen.
Wenn kein Problem vorhanden ist und Sie über die erforderlichen Berechtigungen verfügen, können Sie ein neues GitHub Problem generieren. Wählen Sie "Aktion ausführen" aus.
Wählen Sie im Popup die Option Generate GitHub Problem aus.
Wenn das Problem erfolgreich erstellt wurde, wird eine Popupbenachrichtigung mit einem Link zum Problem angezeigt. Das Problem wird im ursprünglichen Code-Repository erstellt.
Note
Wenn die Problemoption Generieren GitHub nicht verfügbar ist, fehlen möglicherweise erforderliche GitHub- oder Repositoryberechtigungen. Wenden Sie sich an Ihren GitHub oder Repositoryadministrator, um den Zugriff anzufordern.
Nachverfolgung von Zuständigkeiten und Statusaktualisierungen – Änderungen am Issue-Status oder an der Zuweisung, die in GitHub vorgenommen werden, werden in Microsoft Defender for Cloud widergespiegelt, sodass Sie in der Ansicht Recommendations die Zuständigkeit und den Behebungsfortschritt nachverfolgen können.
Nehmen Sie Agent-Korrekturen vor
Auf der GitHub-Seite können Sie das Problem mit Hilfe des GitHub-Codierungs-Agents beheben, wenn Sie über eine GitHub Copilot-Lizenz verfügen:
- Weisen Sie dem Problem einen GitHub-Codierungs-Agent zu.
- Überprüfen Sie die generierte Korrektur.
- Wenn die Lösung angemessen erscheint, wenden Sie sie an.
- Beachten Sie, dass Defender für Cloud den Problemstatus auf "Geschlossen" aktualisiert.