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.
In diesem Artikel werden die Empfehlungen aufgeführt, die in Microsoft Defender for Cloud angezeigt werden, wenn Sie eine Verbindung zwischen Azure DevOps, GitHub oder GitLab-Umgebung mithilfe der Seite "Umgebungseinstellungen" herstellen.
Die Empfehlungen, die in Ihrer Umgebung angezeigt werden, basieren auf den Ressourcen, die Sie schützen und auf Ihrer angepassten Konfiguration. Sie können die Empfehlungen im Portal sehen, die für Ihre Ressourcen gelten.
Informationen zu Aktionen, die Sie als Reaktion auf diese Empfehlungen ausführen können, finden Sie unter "Korrekturempfehlungen" in Defender für Cloud.
Erfahren Sie mehr über die Sicherheitsvorteile und -features von DevOps.
DevOps-Empfehlungen wirken sich nicht auf Ihre Sicherheitsbewertung aus. Um zu entscheiden, welche Empfehlungen zuerst behoben werden sollen, sehen Sie sich den Schweregrad jeder Empfehlung und die potenziellen Auswirkungen auf Ihre Sicherheitsbewertung an.
empfehlungen für Azure DevOps
Azure DevOps Repositorys sollten GitHub Advanced Security for Azure DevOps (GHAzDO) aktiviert sein.
Beschreibung: DevOps-Sicherheit in Defender for Cloud verwendet eine zentrale Konsole, um Sicherheitsteams zu ermöglichen, Anwendungen und Ressourcen vor Code in der Cloud über Azure DevOps zu schützen. Mit der Aktivierung von GitHub Advanced Security for Azure DevOps (GHAzDO)-Repositorys, einschließlich GitHub Advanced Security for Azure DevOps, erhalten Sie Erkenntnisse zu geheimen Schlüsseln, Abhängigkeiten und Coderisiken in Ihren Azure DevOps-Repositorys, die in Microsoft Defender for Cloud.
Schweregrad: Hoch
Azure DevOps Repositorys sollten geheime Überprüfungsergebnisse aufgelöst haben
Beschreibung: Geheime Schlüssel wurden in Coderepositorys gefunden. Beheben Sie sofort, um eine Sicherheitsverletzung zu verhindern. Geheime Schlüssel, die in Repositorys gefunden werden, können durch Angreifer durchlecken oder entdeckt werden, was zu einer Kompromittierung einer Anwendung oder eines Diensts führt. Das Microsoft Security DevOps-Überprüfungstool für Anmeldeinformationen überprüft nur Builds, auf denen sie für die Ausführung konfiguriert ist. Daher spiegeln die Ergebnisse möglicherweise nicht den vollständigen Status von Geheimnissen in Ihren Repositorys wider.
Schweregrad: Hoch
Azure DevOps Repositories sollten Ergebnisse der Codeüberprüfung behoben haben
Beschreibung: Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Azure DevOps-Repositorien sollten Ergebnisse der Sicherheitslückenüberprüfung von Abhängigkeiten beheben
Beschreibung: Abhängigkeitsrisiken, die in Coderepositorys gefunden wurden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Azure DevOps-Repositories sollten behobene Befunde aus der Infrastructure-as-Code-Überprüfung aufweisen
Beschreibung: Infrastruktur als Codesicherheitskonfigurationsprobleme in Repositorys. Die Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben.
Schweregrad: Mittel
Azure DevOps Pipelines sollten keine geheimen Schlüssel für Builds von Forks zur Verfügung haben
Beschreibung: In öffentlichen Repositorys ist es möglich, dass Personen von außerhalb der Organisation Forks erstellen und auf dem Verzweigungsrepository ausführen. Wenn diese Einstellung aktiviert ist, können Außenstehende Zugriff auf geheime Pipelineschlüssel erhalten, die intern sein sollen.
Schweregrad: Hoch
Azure DevOps Dienstverbindungen sollten nicht allen Pipelines Zugriff gewähren
Beschreibung: Dienstverbindungen werden verwendet, um Verbindungen von Azure Pipelines zu externen und Remotediensten zum Ausführen von Aufgaben in einem Auftrag zu erstellen. Pipelineberechtigungen steuern, welche Pipelines für die Verwendung der Dienstverbindung autorisiert sind. Um die Sicherheit der Pipelinevorgänge zu unterstützen, sollten Dienstverbindungen nicht zugriff auf alle YAML-Pipelines gewährt werden. Dies trägt dazu bei, das Prinzip der geringsten Rechte beizubehalten, da eine Sicherheitsanfälligkeit in Komponenten, die von einer Pipeline verwendet werden, von einem Angreifer verwendet werden kann, um andere Pipelines mit Zugriff auf kritische Ressourcen anzugreifen.
Schweregrad: Hoch
Azure DevOps sichere Dateien sollten nicht allen Pipelines Zugriff gewähren
Beschreibung: Mit sicheren Dateien können Entwickler Dateien speichern, die über Pipelines hinweg freigegeben werden können. Diese Dateien werden in der Regel verwendet, um geheime Schlüssel wie Signaturzertifikate und SSH-Schlüssel zu speichern. Wenn einer sicheren Datei Zugriff auf alle YAML-Pipelines gewährt wird, kann ein nicht autorisierter Benutzer Informationen aus den sicheren Dateien stehlen, indem er eine YAML-Pipeline erstellt und auf die sichere Datei zugreift.
Schweregrad: Hoch
Azure DevOps Variablengruppen mit geheimen Variablen sollten nicht allen Pipelines Zugriff gewähren
Beschreibung: Variable Gruppen speichern Werte und geheime Schlüssel, die Sie möglicherweise an eine YAML-Pipeline übergeben oder in mehreren Pipelines verfügbar machen möchten. Sie können variable Gruppen in mehreren Pipelines im selben Projekt freigeben und verwenden. Wenn eine variable Gruppe, die geheime Schlüssel enthält, als barrierefrei für alle YAML-Pipelines markiert ist, kann ein Angreifer die Objekte ausnutzen, die die geheimen Variablen betreffen, indem eine neue Pipeline erstellt wird.
Schweregrad: Hoch
Azure DevOps klassischen Azure Dienstverbindungen sollten nicht für den Zugriff auf ein Abonnement verwendet werden
Beschreibung: Verwenden Sie den Azure Resource Manager (ARM)-Typ von Dienstverbindungen anstelle von Azure klassischen Dienstverbindungen, um eine Verbindung mit Azure Abonnements herzustellen. Das ARM-Modell bietet mehrere Sicherheitsverbesserungen, darunter eine stärkere Zugriffssteuerung, verbesserte Überwachung, ARM-basierte Bereitstellung/Governance, Zugriff auf verwaltete Identitäten und Schlüsseltresor für geheime Schlüssel, entra Permissions-basierte Authentifizierung und Unterstützung für Tags und Ressourcengruppen für eine optimierte Verwaltung.
Schweregrad: Mittel
(Vorschau) Azure DevOps Repositorys sollten API-Sicherheitstestergebnisse gelöst haben
Beschreibung: API-Sicherheitsrisiken, die in Coderepositorys gefunden wurden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
(Vorschau) Azure DevOps Repositorys sollten mindestens zwei Prüfergenehmigungen für Code-Pushs erfordern
Beschreibung: Um zu verhindern, dass unbeabsichtigte oder böswillige Änderungen direkt übernommen werden, ist es wichtig, Schutzrichtlinien für den Standardzweig in Azure DevOps Repositorys zu implementieren. Es wird empfohlen, dass mindestens zwei Codeprüfer Pullanforderungen genehmigen müssen, bevor der Code mit der Standardverzweigung zusammengeführt wird. Durch die Genehmigung von mindestens zwei Prüfern können Sie das Risiko nicht autorisierter Änderungen verringern, was zu Systeminstabilität oder Sicherheitsrisiken führen kann.
Diese Empfehlung wird in Defender for Cloud grundlegenden Sicherheitsstatus bereitgestellt, wenn Sie Azure DevOps mit Defender for Cloud verbunden haben.
Schweregrad: Hoch
(Vorschau) Azure DevOps Repositorys sollten nicht zulassen, dass Anforderer ihre eigenen Pull-Anforderungen genehmigen.
Beschreibung: Um zu verhindern, dass unbeabsichtigte oder böswillige Änderungen direkt übernommen werden, ist es wichtig, Schutzrichtlinien für den Standardzweig in Azure DevOps Repositorys zu implementieren. Es wird empfohlen, die Ersteller von Pull-Anforderungen daran zu hindern, ihre eigenen Übermittlungen zu genehmigen, um sicherzustellen, dass jede Änderung einer objektiven Überprüfung durch eine andere Person als den Autor unterzogen wird. Dadurch können Sie das Risiko nicht autorisierter Änderungen verringern, was zu Systeminstabilität oder Sicherheitsrisiken führen kann.
Diese Empfehlung wird in Defender for Cloud grundlegenden Sicherheitsstatus bereitgestellt, wenn Sie Azure DevOps mit Defender for Cloud verbunden haben.
Schweregrad: Hoch
(Vorschau) Azure DevOps Projekte sollten die Erstellung klassischer Pipelines deaktiviert haben
Beschreibung: Das Deaktivieren der Erstellung von klassischen Build- und Releasepipelines verhindert ein Sicherheitsproblem, das von YAML und klassischen Pipelines stammt, die dieselben Ressourcen gemeinsam nutzen, z. B. die gleichen Dienstverbindungen. Potenzielle Angreifer können klassische Pipelines nutzen, um Prozesse zu erstellen, die typische Abwehrmechanismen umgehen, die sich um moderne YAML-Pipelines richten.
Schweregrad: Hoch
empfehlungen für GitHub
GitHub Organisationen sollten keine geheimen Aktionsgeheimnisse für alle Repositorys zugänglich machen
Beschreibung: Für geheime Schlüssel, die in GitHub Aktionsworkflows verwendet werden, die auf GitHub organisationsebene gespeichert sind, können Sie Zugriffsrichtlinien verwenden, um zu steuern, welche Repositorys Organisationsgeheimnisse verwenden können. Mit geheimen Schlüsseln auf Organisationsebene können Sie geheime Schlüssel zwischen mehreren Repositorys teilen. Dadurch wird die Notwendigkeit reduziert, doppelte geheime Schlüssel zu erstellen. Sobald jedoch ein Geheimschlüssel für ein Repository zugänglich gemacht wurde, kann jeder, der Schreibzugriff auf das Repository hat, von jeder Verzweigung in einem Workflow aus auf den geheimen Schlüssel zugreifen. Um die Angriffsfläche zu reduzieren, stellen Sie sicher, dass der geheime Schlüssel nur aus ausgewählten Repositorys zugänglich ist.
Diese Empfehlung wird in Defender for Cloud grundlegenden Sicherheitsstatus bereitgestellt, wenn Sie Azure DevOps mit Defender for Cloud verbunden haben.
Schweregrad: Hoch
GitHub Repositorys sollten die geheime Überprüfung aktiviert haben
Description: GitHub überprüft Repositorys nach bekannten Arten von geheimen Schlüsseln, um betrügerische Verwendung von Geheimschlüsseln zu verhindern, die versehentlich an Repositorys begangen wurden. Die überprüfung des geheimen Schlüssels überprüft den gesamten Git-Verlauf auf allen Filialen, die im GitHub Repository vorhanden sind, nach geheimen Schlüsseln. Beispiele für Geheimnisse sind Token und private Schlüssel, die ein Dienstanbieter für die Authentifizierung ausstellen kann. Wenn ein Geheimnis in ein Repository eingefügt wird, kann jeder, der über Lesezugriff auf das Repository verfügt, das Geheimnis verwenden, um mit diesen Berechtigungen auf den externen Dienst zuzugreifen. Geheimnisse sollten in einem dedizierten, sicheren Speicherort außerhalb des Repositorys für das Projekt gespeichert werden.
Schweregrad: Hoch
GitHub Repositorys sollten die Codeüberprüfung aktiviert sein
Description: GitHub verwendet Codeüberprüfung, um Code zu analysieren, um Sicherheitsrisiken und Fehler im Code zu finden. Mit dem Codescannen können Sie Korrekturen für vorhandene Probleme in Ihrem Code suchen, selektieren und priorisieren. Durch das Codescannen wird außerdem verhindert, dass Entwickler neue Probleme einführen. Für Überprüfungen können bestimmte Tage und Uhrzeiten festgelegt werden, oder Überprüfungen können ausgelöst werden, wenn im Repository ein bestimmtes Ereignis auftritt, z. B. ein Push. Wenn die Codeüberprüfung eine potenzielle Sicherheitsanfälligkeit oder einen Fehler im Code findet, zeigt GitHub eine Warnung im Repository an. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts zu beeinträchtigen.
Schweregrad: Mittel
GitHub Repositorys sollten die Überprüfung von Dependabot aktiviert sein.
Description: GitHub sendet Dependabot-Benachrichtigungen, wenn Sicherheitsrisiken in Codeabhängigkeiten erkannt werden, die sich auf Repositorys auswirken. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts oder anderer Projekte, die seinen Code verwenden, zu beeinträchtigen. Sicherheitsrisiken variieren im Hinblick auf Typ, Schweregrad und Angriffsmethode. Wenn Code von einem Paket abhängt, das eine Sicherheitslücke aufweist, kann diese anfällige Abhängigkeit eine Reihe von Problemen verursachen.
Schweregrad: Mittel
GitHub Repositorys sollten geheime Überprüfungsergebnisse aufgelöst haben
Beschreibung: Geheime Schlüssel in Coderepositorys. Dies sollte sofort behoben werden, um eine Sicherheitsverletzung zu verhindern. In Repositorys gefundene Geheimnisse können nach außen dringen oder von Angreifern entdeckt werden, was zur Kompromittierung einer Anwendung oder eines Dienstes führen kann.
Schweregrad: Hoch
GitHub Repositories sollten die Ergebnisse der Codeüberprüfung behoben haben
Beschreibung: Sicherheitsrisiken in Coderepositorys. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
GitHub-Repositories sollten die Erkenntnisse aus Abhängigkeits-Schwachstellen-Scans behoben haben
Beschreibung: GitHub Repositorys sollten Abhängigkeitsüberprüfungsergebnisse behoben haben.
Schweregrad: Mittel
GitHub Repositorys sollten Infrastruktur aufweisen, da Codescanergebnisse gelöst wurden
Beschreibung: Infrastruktur als Codesicherheitskonfigurationsprobleme wurden in Repositorys gefunden. Die Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben.
Schweregrad: Mittel
GitHub-Repositorys sollten Schutzrichtlinien für standardmäßige Verzweigung aktiviert haben
Beschreibung: Die Standardverzweigung des Repositorys sollte über Branch-Schutzrichtlinien geschützt werden, um zu verhindern, dass unbeabsichtigte/böswillige Änderungen direkt an das Repository gebunden werden.
Schweregrad: Hoch
GitHub Repositorys sollten Pushes auf standardmäßig deaktivierte Verzweigung erzwingen
Beschreibung: Da die Standardverzweigung in der Regel für die Bereitstellung und andere privilegierte Aktivitäten verwendet wird, sollten alle Änderungen daran vorsichtig behandelt werden. Das Aktivieren von Force-Pushs kann unbeabsichtigte oder böswillige Änderungen an der Standardverzweigung verursachen.
Schweregrad: Mittel
GitHub Organisationen sollten den Pushschutz für geheime Scans aktiviert haben
Beschreibung: Der Pushschutz blockiert Commits, die geheime Schlüssel enthalten, wodurch versehentliche Expositionen von Geheimschlüsseln verhindert werden. Um das Risiko einer Gefährdung von Anmeldeinformationen zu vermeiden, sollte der Pushschutz für jedes geheime Überprüfungsaktivierungs-Repository automatisch aktiviert sein.
Schweregrad: Hoch
GitHub Repositorys sollten keine selbst gehosteten Läufer verwenden
Beschreibung: Self-Hosted Runners auf GitHub fehlen Garantien für den Betrieb auf kurzlebigen virtuellen Computern und können dauerhaft durch nicht vertrauenswürdigen Code in einem Workflow kompromittiert werden. Daher sollten Self-Hosted Runners nicht für Aktionsworkflows verwendet werden.
Schweregrad: Hoch
GitHub Organisationen sollten über Workflowberechtigungen für Aktionen verfügen, die auf schreibgeschützt festgelegt sind.
Beschreibung: Standardmäßig sollten Aktionsworkflows schreibgeschützte Berechtigungen erteilt werden, um böswillige Benutzer daran zu hindern, überberechtigungierte Workflows für den Zugriff auf ressourcen zu nutzen und sie zu manipulieren.
Schweregrad: Hoch
GitHub Organisationen sollten über mehr als eine Person mit Administratorberechtigungen verfügen
Beschreibung: Wenn sie mindestens zwei Administratoren haben, verringert sich das Risiko, dass der Administratorzugriff verloren geht. Dies ist bei Break-Glass-Kontoszenarien nützlich.
Schweregrad: Hoch
GitHub Organisationen sollten über Basisberechtigungen verfügen, die auf keine Berechtigungen oder leseberechtigungen festgelegt sind.
Beschreibung: Basisberechtigungen sollten für eine Organisation nicht festgelegt oder gelesen werden, um dem Prinzip der geringsten Berechtigungen zu folgen und unnötigen Zugriff zu verhindern.
Schweregrad: Hoch
(Vorschau) GitHub Repositorys sollten API-Sicherheitstests behoben sein
Beschreibung: API-Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
(Vorschau) GitHub Organisationen sollten keine geheimen Aktionsgeheimnisse für alle Repositorys zugänglich machen
Beschreibung: Für geheime Schlüssel, die in GitHub Aktionsworkflows verwendet werden, die auf GitHub organisationsebene gespeichert sind, können Sie mithilfe von Zugriffsrichtlinien steuern, welche Repositorys Organisationsgeheimnisse verwenden können. Geheime Schlüssel auf Organisationsebene ermöglichen es Ihnen, geheime Schlüssel zwischen mehreren Repositorys freizugeben, wodurch die Notwendigkeit reduziert wird, doppelte geheime Schlüssel zu erstellen. Wenn jedoch ein Geheimschlüssel für ein Repository zugänglich gemacht wird, kann jeder, der Schreibzugriff auf das Repository hat, von jeder Verzweigung in einem Workflow aus auf den geheimen Schlüssel zugreifen. Um die Angriffsfläche zu reduzieren, stellen Sie sicher, dass der geheime Schlüssel nur aus ausgewählten Repositorys zugänglich ist.
Schweregrad: Hoch
(Vorschau) GitHub Organisationen sollten Copilot-Empfehlungen blockieren, die mit öffentlichem Code übereinstimmen
Beschreibung: Das Aktivieren des Filters von GitHub Copilot zum Blockieren von Codevorschlägen, die öffentlichem Code entsprechen, GitHub die Sicherheit und die Einhaltung gesetzlicher Vorschriften verbessern. Sie verhindert die unbeabsichtigte Einbindung von öffentlichem oder open-source-Code, verringert das Risiko von rechtlichen Problemen und stellt die Einhaltung von Lizenzbedingungen sicher. Darüber hinaus wird verhindert, dass potenzielle Sicherheitsrisiken aus dem öffentlichen Code in die Projekte der Organisation eingeführt werden, wodurch eine höhere Codequalität und -sicherheit gewährleistet wird. Wenn der Filter aktiviert ist, überprüft GitHub Copilot Codevorschläge mit ihrem umgebenden Code von ca. 150 Zeichen gegen öffentlichen Code auf GitHub. Wenn eine Übereinstimmung vorliegt oder eine Übereinstimmung in der Nähe vorhanden ist, wird der Vorschlag nicht angezeigt.
Schweregrad: Hoch
(Vorschau) GitHub Organisationen sollten die mehrstufige Authentifizierung für externe Mitarbeiter erzwingen
Beschreibung: Das Erzwingen der mehrstufigen Authentifizierung für externe Mitarbeiter in einer GitHub Organisation ist eine Sicherheitsmaßnahme, die mitarbeiter zur Verwendung einer zusätzlichen Identifikationsform neben ihrem Kennwort für den Zugriff auf die Repositorys und Ressourcen der Organisation benötigt. Dadurch wird die Sicherheit verbessert, indem sie vor unbefugtem Zugriff schützt, auch wenn ein Kennwort kompromittiert wird, und die Einhaltung der Branchenstandards gewährleistet. Es umfasst das Informieren von Mitarbeitern über die Anforderung und die Bereitstellung von Unterstützung für den Übergang, wodurch letztendlich das Risiko von Datenschutzverletzungen verringert wird.
Schweregrad: Hoch
(Vorschau) GitHub Repositorys sollten mindestens zwei Prüfergenehmigungen für Code-Pushs erfordern.
Beschreibung: Um zu verhindern, dass unbeabsichtigte oder böswillige Änderungen direkt übernommen werden, ist es wichtig, Schutzrichtlinien für die Standardverzweigung in GitHub Repositorys zu implementieren. Es wird empfohlen, dass mindestens zwei Codeprüfer Pullanforderungen genehmigen müssen, bevor der Code mit der Standardverzweigung zusammengeführt wird. Durch die Genehmigung von mindestens zwei Prüfern können Sie das Risiko nicht autorisierter Änderungen verringern, was zu Systeminstabilität oder Sicherheitsrisiken führen kann.
Schweregrad: Hoch
GitLab-Empfehlungen
GitLab-Projekte sollten geheime Überprüfungsergebnisse aufgelöst haben
Beschreibung: Geheime Schlüssel wurden in Coderepositorys gefunden. Dies sollte sofort behoben werden, um eine Sicherheitsverletzung zu verhindern. In Repositorys gefundene Geheimnisse können nach außen dringen oder von Angreifern entdeckt werden, was zur Kompromittierung einer Anwendung oder eines Dienstes führen kann.
Schweregrad: Hoch
GitLab-Projekte sollten Ergebnisse der Codeanalyse behoben haben
Beschreibung: Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
GitLab-Projekte sollten Abhängigkeitsüberprüfungsergebnisse behoben haben
Beschreibung: GitHub Repositorys sollten Abhängigkeitsüberprüfungsergebnisse behoben haben.
Schweregrad: Mittel
GitLab-Projekte sollten erkannte Probleme aus der Infrastructure-as-Code-Überprüfung beheben
Beschreibung: Infrastruktur als Codesicherheitskonfigurationsprobleme wurden in Repositorys gefunden. Die angezeigten Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben.
Schweregrad: Mittel
Veraltete DevOps-Sicherheitsempfehlungen
Für Coderepositorys müssen Ergebnisse des Codescannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender for Cloud hat Sicherheitsrisiken in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
Für Coderepositorys müssen Ergebnisse des Geheimnisscannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender for Cloud hat in Coderepositorys einen geheimen Schlüssel gefunden. Dies sollte sofort behoben werden, um eine Sicherheitsverletzung zu verhindern. In Repositorys gefundene Geheimnisse können nach außen dringen oder von Angreifern entdeckt werden, was zur Kompromittierung einer Anwendung oder eines Dienstes führen kann. Für Azure DevOps überprüft das Microsoft Security DevOps CredScan-Tool nur Builds, auf denen sie für die Ausführung konfiguriert wurde. Daher spiegeln die Ergebnisse möglicherweise nicht den vollständigen Status von Geheimnissen in Ihren Repositorys wider. (Keine zugehörige Richtlinie)
Schweregrad: Hoch
Für Coderepositorys müssen Ergebnisse des Dependabot-Scannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender for Cloud hat Sicherheitsrisiken in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
Für Coderepositorys müssen Ergebnisse des Infrastructure-as-Code-Scannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender for Cloud hat Infrastruktur als Codesicherheitskonfigurationsprobleme in Repositorys gefunden. Die angezeigten Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
GitHub Repositorys sollten die Codeüberprüfung aktiviert sein
Description: GitHub verwendet Codeüberprüfung, um Code zu analysieren, um Sicherheitsrisiken und Fehler im Code zu finden. Mit dem Codescannen können Sie Korrekturen für vorhandene Probleme in Ihrem Code suchen, selektieren und priorisieren. Durch das Codescannen wird außerdem verhindert, dass Entwickler neue Probleme einführen. Für Überprüfungen können bestimmte Tage und Uhrzeiten festgelegt werden, oder Überprüfungen können ausgelöst werden, wenn im Repository ein bestimmtes Ereignis auftritt, z. B. ein Push. Wenn die Codeüberprüfung eine potenzielle Sicherheitsanfälligkeit oder einen Fehler im Code findet, zeigt GitHub eine Warnung im Repository an. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts zu beeinträchtigen. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
GitHub Repositorys sollten die geheime Überprüfung aktiviert haben
Description: GitHub überprüft Repositorys nach bekannten Arten von geheimen Schlüsseln, um betrügerische Verwendung von Geheimschlüsseln zu verhindern, die versehentlich an Repositorys begangen wurden. Die überprüfung des geheimen Schlüssels überprüft den gesamten Git-Verlauf auf allen Filialen, die im GitHub Repository vorhanden sind, nach geheimen Schlüsseln. Beispiele für Geheimnisse sind Token und private Schlüssel, die ein Dienstanbieter für die Authentifizierung ausstellen kann. Wenn ein Geheimnis in ein Repository eingefügt wird, kann jeder, der über Lesezugriff auf das Repository verfügt, das Geheimnis verwenden, um mit diesen Berechtigungen auf den externen Dienst zuzugreifen. Geheimnisse sollten in einem dedizierten, sicheren Speicherort außerhalb des Repositorys für das Projekt gespeichert werden. (Keine zugehörige Richtlinie)
Schweregrad: Hoch
GitHub Repositorys sollten die Überprüfung von Dependabot aktiviert sein.
Description: GitHub sendet Dependabot-Benachrichtigungen, wenn Sicherheitsrisiken in Codeabhängigkeiten erkannt werden, die sich auf Repositorys auswirken. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts oder anderer Projekte, die seinen Code verwenden, zu beeinträchtigen. Sicherheitsrisiken variieren im Hinblick auf Typ, Schweregrad und Angriffsmethode. Wenn Code von einem Paket abhängt, das eine Sicherheitslücke aufweist, kann diese anfällige Abhängigkeit eine Reihe von Problemen verursachen. (Keine zugehörige Richtlinie)
Schweregrad: Mittel