Sicherheitsempfehlungen für DevOps-Ressourcen
In diesem Artikel werden die Empfehlungen aufgeführt, die in Microsoft Defender für Cloud angezeigt werden, wenn Sie eine Azure DevOps-, GitHub- oder GitLab-Umgebung mithilfe der Seite "Umgebungseinstellungen " verbinden. Die Empfehlungen, die in Ihrer Umgebung angezeigt werden, basieren auf den Ressourcen, die Sie schützen und auf Ihrer angepassten Konfiguration.
Informationen zu Aktionen, die Sie als Reaktion auf diese Empfehlungen ausführen können, finden Sie unter "Korrekturempfehlungen" in Defender für Cloud.
Weitere Informationen den Vorteilen und Features von DevOps-Sicherheit finden Sie hier.
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.
Azure DevOps-Empfehlungen
In Azure DevOps-Repositorys sollte GitHub Advanced Security für Azure DevOps (GHAzDO) aktiviert sein.
Beschreibung: Die DevOps-Sicherheit in Defender für Cloud verwendet eine zentrale Konsole, um Sicherheitsteams mit der Möglichkeit zu unterstützen, Anwendungen und Ressourcen vor Code in der Cloud in Azure DevOps zu schützen. Mit der Aktivierung von GitHub Advanced Security for Azure DevOps (GHAzDO)-Repositorys, einschließlich GitHub Advanced Security für Azure DevOps, erhalten Sie Erkenntnisse zu geheimen Schlüsseln, Abhängigkeiten und Coderisiken in Ihren Azure DevOps-Repositorys, die in Microsoft Defender für Cloud angezeigt werden.
Schweregrad: hoch
Für Azure DevOps-Repositorys sollten Ergebnisse des Geheimnisscannens behandelt werden.
Beschreibung: Geheime Schlüssel wurden in Coderepositorys gefunden. Beheben Sie dies umgehend, 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
Für Azure DevOps-Repositorys müssen Ergebnisse des Codescannens aufgelöst werden.
Beschreibung: Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Für Azure DevOps-Repositorys sollten Ergebnisse der Scans auf Abhängigkeitssicherheitsrisiken behoben sein.
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-Repositorys sollten über „Infrastruktur als Code“-Scans verfügen, deren Ergebnisse behandelt wurden.
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 Buildpipeline-Geheimnisse 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
Sichere Azure DevOps-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 Variablengruppen in mehreren Pipelines im selben Projekt gemeinsam 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: Klassische 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 Classic-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-Sicherheitstests behoben 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 die Standardbranch in Azure DevOps-Repositorys zu implementieren. Es wird empfohlen, dass mindestens zwei Codeprüfer Pullanforderungen genehmigen müssen, bevor der Code mit dem Standardbranch 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 foundational security posture bereitgestellt, wenn Sie Azure DevOps mit Defender für 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 die Standardbranch 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 foundational security posture bereitgestellt, wenn Sie Azure DevOps mit Defender für 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
GitHub-Empfehlungen
GitHub-Organisationen sollten Aktionsgeheimnisse nicht 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 Geheimnissen auf Organisationsebene können Sie Geheimnisse 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 foundational security posture bereitgestellt, wenn Sie Azure DevOps mit Defender für Cloud verbunden haben.
Schweregrad: hoch
Für GitHub-Repositorys muss das Geheimnisscannen aktiviert sein.
Beschreibung: GitHub durchsucht Repositorys nach bekannten Arten von Geheimschlüsseln, um betrügerische Verwendung von Geheimschlüsseln zu verhindern, die versehentlich an Repositorys begangen wurden. Beim Geheimnisscannen wird der gesamte Git-Verlauf für alle Branches in Ihrem GitHub-Repository nach Geheimnissen durchsucht. 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
Für GitHub-Repositorys muss das Codescannen aktiviert sein.
Beschreibung: 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 beim Codescannen ein potenzielles Sicherheitsrisiko oder ein Fehler im Code gefunden wird, 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
Für GitHub-Repositorys muss das Dependabot-Scannen aktiviert sein
Beschreibung: GitHub sendet Dependabot-Warnungen, wenn sie Sicherheitsrisiken in Codeabhängigkeiten erkennt, 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
Für GitHub-Repositorys müssen Ergebnisse des Geheimnisscannens aufgelöst werden.
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
Für GitHub-Repositorys müssen Ergebnisse des Codescannens aufgelöst werden.
Beschreibung: Sicherheitsrisiken in Coderepositorys. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Für GitHub-Repositorys sollten Ergebnisse der Scans auf Abhängigkeitssicherheitsrisiken behoben sein.
Beschreibung: GitHub-Repositorys sollten Abhängigkeitsüberprüfungsergebnisse behoben haben.
Schweregrad: Mittel
GitHub-Repositorys sollten über „Infrastruktur als Code“-Scans verfügen, deren Ergebnisse behandelt 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
Für GitHub-Repositorys sollten Schutzrichtlinien für den Standardbranch aktiviert sein.
Beschreibung: Die Standardbranch 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
Für GitHub-Repositorys sollten erzwungene Pushvorgänge an den Standardbranch deaktiviert sein.
Beschreibung: Da die Standardbranch 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-Pushes kann unbeabsichtigte oder böswillige Änderungen an den Standardbranches verursachen.
Schweregrad: Mittel
Für GitHub-Organisationen sollte der Pushschutz für das Geheimnisscannen aktiviert sein.
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 Repository mit Unterstützung für Geheimnisüberprüfungen automatisch aktiviert sein.
Schweregrad: hoch
GitHub-Repositorys sollten keine selbstgehosteten Runner verwenden.
Beschreibung: Self-Hosted Runners auf GitHub fehlen Garantien für den Betrieb in ephemeren, sauberen virtuellen Computern und können dauerhaft durch nicht vertrauenswürdigen Code in einem Workflow kompromittiert werden. Selbstgehostete Runner sollten daher 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 Notfall-Kontoszenarien nützlich.
Schweregrad: hoch
GitHub-Organisationen sollten über Basisberechtigungen verfügen, die auf „keine Berechtigungen“ oder „Lesen“ 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) Für GitHub-Repositorys müssen beim API-Sicherheitstest festgestellte Probleme behoben werden.
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 Zugriffsrichtlinien verwenden, um zu 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-Vorschläge blockieren, die mit öffentlichem Code übereinstimmen
Beschreibung: Die Aktivierung des GitHub Copilot-Filters zum Blockieren von Codevorschlägen, die mit öffentlichem Code auf GitHub übereinstimmen, verbessert sicherheit und rechtliche Compliance. 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 es eine Übereinstimmung oder Beinahe-Übereinstimmung gibt, wird der Vorschlag nicht angezeigt.
Schweregrad: hoch
(Vorschau) GitHub-Organisationen sollten die mehrstufige Authentifizierung für externer Projektmitarbeiter erzwingen
Beschreibung: Das Erzwingen der mehrstufigen Authentifizierung für externer Projektmitarbeiter s in einer GitHub-Organisation ist eine Sicherheitsmaßnahme, die Mitarbeiter benötigt, um neben ihrem Kennwort auf die Repositorys und Ressourcen der Organisation zuzugreifen. 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 Standardbranch in GitHub-Repositorys zu implementieren. Es wird empfohlen, dass mindestens zwei Codeprüfer Pullanforderungen genehmigen müssen, bevor der Code mit dem Standardbranch 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
Für GitLab-Projekte müssen Ergebnisse des Geheimnisscannens aufgelöst werden.
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
Für GitLab-Projekte müssen Ergebnisse des Codescannens aufgelöst werden.
Beschreibung: Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Für GitLab-Projekte sollten Ergebnisse der Scans auf Abhängigkeitssicherheitsrisiken behoben sein.
Beschreibung: GitHub-Repositorys sollten Abhängigkeitsüberprüfungsergebnisse behoben haben.
Schweregrad: Mittel
GitLab-Projekte sollten über „Infrastruktur als Code“-Scans verfügen, deren Ergebnisse behandelt wurden.
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 für 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 für 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, in denen es 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 für 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 für 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
Für GitHub-Repositorys muss das Codescannen aktiviert sein.
Beschreibung: 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 beim Codescannen ein potenzielles Sicherheitsrisiko oder ein Fehler im Code gefunden wird, 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
Für GitHub-Repositorys muss das Geheimnisscannen aktiviert sein.
Beschreibung: GitHub durchsucht Repositorys nach bekannten Arten von Geheimschlüsseln, um betrügerische Verwendung von Geheimschlüsseln zu verhindern, die versehentlich an Repositorys begangen wurden. Beim Geheimnisscannen wird der gesamte Git-Verlauf für alle Branches in Ihrem GitHub-Repository nach Geheimnissen durchsucht. 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
Für GitHub-Repositorys muss das Dependabot-Scannen aktiviert sein
Beschreibung: GitHub sendet Dependabot-Warnungen, wenn sie Sicherheitsrisiken in Codeabhängigkeiten erkennt, 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