Empfehlungen für die Sicherung eines Entwicklungslebenszyklus

  • Artikel

Gilt für diese Empfehlung für die Sicherheit von Azure Well-Architected Framework:

SE:02 Verwalten Sie einen sicheren Entwicklungslebenszyklus mithilfe einer gehärteten, meist automatisierten und auditierbaren Software-Lieferkette. Integrieren Sie ein sicheres Design, indem Sie die Bedrohungsmodellierung verwenden, um vor Implementierungen mit Sicherheitsbedrohungen zu schützen.

Verwandter Leitfaden: Bedrohungsanalyse

In diesem Leitfaden werden die Empfehlungen für die Härtung ihres Codes, der Entwicklungsumgebung und der Software-Lieferkette beschrieben, indem bewährte Methoden für die Sicherheit im gesamten Entwicklungszyklus angewendet werden. Um diese Anleitung zu verstehen, sollten Sie über Kenntnisse von DevSecOps verfügen.

Diagramm des Sicherheitszyklus.

DevSecOps integriert Sicherheit in DevOps-Prozesse durch:

  • Automatisieren von Sicherheitstests und -validierungen.

  • Implementieren von Tools wie Sicherheitspipelinen zum Scannen von Code und Infrastruktur als Code (IaC) auf Sicherheitsrisiken.

Der Kern einer Workload ist der Anwendungscode, der Geschäftslogik implementiert. Der Code und der Prozess der Codeentwicklung müssen frei von Sicherheitsfehlern sein, um Vertraulichkeit, Integrität und Verfügbarkeit sicherzustellen.

Es reicht nicht aus, nur die Infrastrukturebene mithilfe von Steuerelementen für Identität und Netzwerk und andere Maßnahmen zu sichern. Verhindern Sie eine schlechte Implementierung von Code oder einen kompromittierten Codeblock , um Ihren gesamten Sicherheitsstatus zu stärken. Die Verwendungsebene, d. h. der Anwendungscode, muss ebenfalls gehärtet werden. Der Prozess der Integration von Sicherheit in Ihren Entwicklungslebenszyklus ist im Wesentlichen ein Härteprozess. Wie die Ressourcenhärtung ist auch die Straffung der Codeentwicklung kontextunabhängig. Der Fokus liegt auf der Verbesserung der Sicherheit und nicht auf den funktionalen Anforderungen der Anwendung. Informationen zum Härten finden Sie unter "Empfehlungen zum Härten von Ressourcen".

Definitionen

Begriff Definition
Security Development Lifecycle (SDL) Eine Reihe von Methoden, die von Microsoft bereitgestellt werden, die Sicherheitsüberprüfungs- und Complianceanforderungen unterstützen.
Lebenszyklus der Softwareentwicklung (SDLC) Ein mehrstufiger, systematischer Prozess für die Entwicklung von Softwaresystemen.

Wichtige Entwurfsstrategien

Sicherheitsmaßnahmen sollten an mehreren Punkten in Ihren vorhandenen Software Development Lifecycle (SDLC) integriert werden, um Folgendes sicherzustellen:

  • Designentscheidungen führen nicht zu Sicherheitslücken.

  • Anwendungscode und -konfiguration erstellen keine Sicherheitsrisiken aufgrund von ausnutzbaren Implementierungs- und unsachgemäßen Codierungsmethoden.

  • Software, die über die Lieferkette erworben wurde, führt nicht zu Sicherheitsbedrohungen.

  • Anwendungscode, Build- und Bereitstellungsprozesse werden nicht manipuliert.

  • Sicherheitsrisiken, die durch Vorfälle aufgedeckt werden, werden abgemildert.

  • Nicht verwendete Ressourcen werden ordnungsgemäß außer Betrieb genommen.

  • Complianceanforderungen werden nicht kompromittiert oder reduziert.

  • Die Überwachungsprotokollierung wird in Entwicklerumgebungen implementiert.

In den folgenden Abschnitten finden Sie Sicherheitsstrategien für die häufig praktizierten Phasen von SDLC.

Sammeln und Dokumentieren der Sicherheitsanforderungen

Das Ziel der Anforderungsphase besteht darin, die funktionalen und nicht funktionalen Anforderungen für eine Anwendung oder ein neues Feature einer Anwendung zu erfassen und zu analysieren. Diese Phase ist wichtig, da sie die Schaffung von Schutzschienen erleichtert, die auf die Ziele der Anwendung zugeschnitten sind. Der Schutz der Daten und Integrität Ihrer Anwendung sollte in jeder Phase des Entwicklungslebenszyklus eine zentrale Anforderung sein.

Betrachten Sie beispielsweise eine Anwendung, die kritische Benutzerflüsse unterstützen muss, die es dem Benutzer ermöglichen, Daten hochzuladen und zu bearbeiten. Die Auswahlmöglichkeiten für den Sicherheitsentwurf sollten Die Sicherheitsmaßnahmen für die Interaktion des Benutzers mit der Anwendung umfassen, z. B. die Authentifizierung und Autorisierung der Benutzeridentität, die nur zulässige Aktionen für die Daten zulassen und die SQL-Einfügung verhindern. Ebenso decken Sie nicht funktionale Anforderungen wie Verfügbarkeit, Skalierbarkeit und Wartung ab. Sicherheitsentscheidungen sollten Segmentierungsgrenzen, Firewall-Eingangs- und Ausgangsgrenzen und andere grenzüberschreitende Sicherheitsbedenken umfassen.

All diese Entscheidungen sollten zu einer guten Definition des Sicherheitsstatus der Anwendung führen. Dokumentieren Sie die Sicherheitsanforderungen in einer vereinbarten Spezifikation und spiegeln sie im Backlog wider. Es sollte explizit die Sicherheitsinvestitionen und die Kompromisse und Risiken angeben, die das Unternehmen übernehmen will, wenn die Investitionen nicht von den Geschäftsbeteiligten genehmigt werden. Sie können z. B. die Notwendigkeit dokumentieren, eine Webanwendungsfirewall (WAF) vor Ihrer Anwendung zu verwenden, z. B. Azure Front Door oder Azure-App lizenzierungsgateway. Wenn Unternehmensbeteiligte nicht bereit sind, die zusätzlichen Kosten für die Ausführung eines WAF zu akzeptieren, müssen sie das Risiko akzeptieren, dass Angriffe auf Anwendungsebene möglicherweise auf die Anwendung gerichtet sind.

Das Sammeln von Sicherheitsanforderungen ist ein wichtiger Bestandteil dieser Phase. Ohne diesen Aufwand basieren die Entwurfs- und Implementierungsphasen auf nicht definierten Entscheidungen, was zu Sicherheitslücken führen kann. Möglicherweise müssen Sie die Implementierung später ändern, um die Sicherheit zu berücksichtigen, was teuer sein kann.

Übersetzen von Sicherheitsanforderungen in technische Anforderungen

In der Entwurfsphase werden die Sicherheitsanforderungen in technische Anforderungen umgewandelt. Dokumentieren Sie in Ihrer technischen Spezifikation alle Entwurfsentscheidungen, um Mehrdeutigkeit während der Implementierung zu verhindern. Hier sind einige typische Aufgaben:

Definieren der Sicherheitsdimension der Systemarchitektur

Überlagern Sie die Architektur mit Sicherheitssteuerelementen. Steuerelemente, die für die Isolationsgrenzen pro Segmentierungsstrategie praktisch sind, die Typen von Identitäten, die für die Komponenten der Anwendung erforderlich sind, und die Art der zu verwendenden Verschlüsselungsmethoden. Einige Beispielarchitekturen finden Sie in den Abbildungen in den Beispielabschnitten der Artikel " Identitäts- und Zugriffsverwaltung und Netzwerk" .

Bewerten von plattformbezogenen Angeboten

Es ist wichtig, die Verantwortungsteilung zwischen Ihnen und dem Cloudanbieter zu verstehen. Vermeiden Sie Überlappungen mit systemeigenen Azure-Sicherheitssteuerelementen, z. B. Sie erhalten eine bessere Sicherheitsabdeckung und können Entwicklungsressourcen den Anforderungen der Anwendung zuordnen.

Wenn Ihr Design beispielsweise beim Eingang eine Webanwendungsfirewall aufruft, können Sie diese Verantwortung auf ein Lastenausgleichsmodul wie anwendungsgateway oder Azure Front Door auslagern. Vermeiden Sie das Replizieren von Features als benutzerdefinierter Code in Ihrer Anwendung.

Wählen Sie nur vertrauenswürdige Frameworks, Bibliotheken und Lieferkettensoftware aus. Ihr Design sollte auch die sichere Versionssteuerung angeben. Anwendungsabhängigkeiten sollten von vertrauenswürdigen Parteien stammen. Drittanbieter sollten in der Lage sein, Ihre Sicherheitsanforderungen zu erfüllen und ihren verantwortlichen Offenlegungsplan zu teilen. Jeder Sicherheitsvorfall sollte umgehend gemeldet werden, damit Sie erforderliche Maßnahmen ergreifen können. Darüber hinaus sind bestimmte Bibliotheken möglicherweise von Ihrer Organisation verboten. Software kann z. B. vor Sicherheitsrisiken geschützt sein, aufgrund von Lizenzierungseinschränkungen jedoch weiterhin nicht zulässig sein.

Um sicherzustellen, dass auf diese Anleitung alle Mitwirkenden an der Software folgen, verwalten Sie eine Liste der genehmigten und/oder nicht genehmigten Frameworks, Bibliotheken und Anbieter. Platzieren Sie nach Möglichkeit Schutzschienen in den Entwicklungspipelines, um die Liste zu unterstützen. Automatisieren Sie so viel wie möglich die Verwendung von Tools zum Scannen von Abhängigkeiten auf Sicherheitsrisiken.

Bestimmen Sie die Sicherheitsentwurfsmuster, die der Anwendungscode implementieren soll.

Muster können Sicherheitsbedenken wie Segmentierung und Isolierung, starke Autorisierung, einheitliche Anwendungssicherheit und moderne Protokolle unterstützen. Einige Betriebsmuster, z. B. das Quarantänemuster, können dazu beitragen, die Verwendung von Software zu überprüfen und zu blockieren, die potenziell Sicherheitsrisiken auslösen könnte.

Weitere Informationen finden Sie unter Clouddesignmuster, die Sicherheit unterstützen.

Sicheres Speichern von Anwendungsschlüsseln

Implementieren Sie sicher die Verwendung von geheimen Anwendungsschlüsseln und vorab freigegebenen Schlüsseln, die Ihre Anwendung verwendet. Anmeldeinformationen und Anwendungsgeheimnisse sollten niemals in der Quellcodestruktur gespeichert werden. Verwenden Sie externe Ressourcen wie Azure Key Vault, um sicherzustellen, dass, wenn Ihr Quellcode für einen potenziellen Angreifer verfügbar ist, kein weiterer Zugriff erhalten werden kann. Im Allgemeinen finden Sie Möglichkeiten, geheime Schlüssel zu vermeiden. Die Verwendung verwalteter Identitäten ist nach Möglichkeit eine Möglichkeit, dieses Ziel zu erreichen. Weitere Informationen finden Sie unter Empfehlungen zum Verwalten von Anwendungsgeheimnissen.

Definieren von Testplänen

Definieren Sie klare Testfälle für Sicherheitsanforderungen. Bewerten Sie, ob Sie diese Tests in Ihren Pipelines automatisieren können. Wenn Ihr Team Über Prozesse für manuelle Tests verfügt, schließen Sie Sicherheitsanforderungen für diese Tests ein.

Hinweis

Durchführen der Bedrohungsmodellierung während dieser Phase. Die Bedrohungsmodellierung kann bestätigen, dass die Designoptionen den Sicherheitsanforderungen entsprechen und Lücken verfügbar machen, die Sie mindern sollten. Wenn Ihre Arbeitsauslastung streng vertrauliche Daten verarbeitet, investieren Sie in Sicherheitsexperten, die Ihnen bei der Durchführung der Bedrohungsmodellierung helfen können.

Die anfängliche Übung zur Bedrohungsmodellierung sollte während der Entwurfsphase auftreten, wenn die Architektur und das allgemeine Design der Software definiert werden. Wenn Sie dies in dieser Phase tun, können Sie potenzielle Sicherheitsprobleme erkennen, bevor sie in die Struktur des Systems integriert werden. Diese Übung ist jedoch keine einmalige Aktivität. Es ist ein kontinuierlicher Prozess, der während der Entwicklung der Software fortgesetzt werden sollte.

Weitere Informationen finden Sie unter Empfehlungen für die Bedrohungsanalyse.

Sichere Entwicklungs- und Testpraktiken

Während der Entwicklungs- und Testphase besteht das Ziel darin, Sicherheitsfehler und Manipulationen in Code-, Build- und Bereitstellungspipelines zu verhindern.

Seien Sie gut geschult in sicheren Codepraktiken

Das Entwicklungsteam sollte über formale und spezialisierte Schulungen für sichere Codierungspraktiken verfügen. Web- und API-Entwickler benötigen beispielsweise spezifische Schulungen zum Schutz vor websiteübergreifenden Skriptangriffen, und Back-End-Entwickler können von fundierten Schulungen profitieren, um Angriffe auf Datenbankebene wie SQL-Einfügungsangriffe zu vermeiden.

Entwickler müssen diese Schulung abschließen, bevor sie Zugriff auf den Quellcode für die Produktion erhalten können.

Sie sollten auch interne Peercodeüberprüfungen durchführen, um kontinuierliches Lernen zu fördern.

Verwenden von Sicherheitstesttools

Führen Sie die Bedrohungsmodellierung aus, um die Sicherheit der Architektur der Anwendung zu bewerten.

Verwenden Sie statische Anwendungssicherheitstests (SAST), um Code für Sicherheitsrisiken zu analysieren. Integrieren Sie diese Methodik in die Entwicklerumgebung, um Sicherheitsrisiken in Echtzeit zu erkennen.

Verwenden Sie dynamische Anwendungssicherheitstests (DAST) während der Laufzeit. Diese Toolkette kann auf Fehler in Sicherheitsdomänen überprüfen und eine Reihe von Angriffen simulieren, um die Sicherheitsresilienz der Anwendung zu testen. Integrieren Sie dieses Tool nach Möglichkeit in Ihre Buildpipelines.

Befolgen Sie Branchenstandards für sichere Codierungsmethoden. Weitere Informationen finden Sie im Abschnitt "Communityressourcen " in diesem Artikel.

Verwenden Sie Linters und Codeanalysatoren, um zu verhindern, dass Anmeldeinformationen an das Quellcode-Repository übertragen werden. Beispielsweise untersuchen .NET Compiler Platform (Roslyn) Analyzer Ihren Anwendungscode.

Verwenden Sie während des Buildvorgangs Pipeline-Add-Ons, um Anmeldeinformationen im Quellcode abzufangen. Scannen Sie alle Abhängigkeiten, z. B. Bibliotheken und Frameworkkomponenten von Drittanbietern, im Rahmen des kontinuierlichen Integrationsprozesses. Untersuchen Sie anfällige Komponenten, die vom Tool gekennzeichnet werden. Kombinieren Sie diese Aufgabe mit anderen Codeüberprüfungsaufgaben, die Code-Churn, Testergebnisse und Abdeckung untersuchen.

Verwenden Sie eine Kombination aus Tests. Informationen zu Sicherheitstests im Allgemeinen finden Sie unter Empfehlungen für Sicherheitstests.

Schreiben Sie nur genügend Code

Wenn Sie den Codebedarf reduzieren, verringern Sie auch die Wahrscheinlichkeit von Sicherheitsfehlern. Verwenden Sie Code und Bibliotheken, die bereits verwendet werden, und haben sie durch Sicherheitsüberprüfungen anstelle von Duplizieren von Code verwendet.

Das Nutzen von Azure-Features ist eine weitere Möglichkeit, unnötigen Code zu verhindern. Eine Möglichkeit besteht darin, verwaltete Dienste zu verwenden. Weitere Informationen finden Sie unter Verwenden von PaaS-Optionen (Platform-as-a-Service)

Schreiben Sie Standardmäßig Code mit einem "Allen verweigern"-Ansatz. Erstellen Sie Zulassungslisten nur für Entitäten, die Zugriff benötigen. Wenn Sie z. B. Code haben, der bestimmen muss, ob ein privilegierter Vorgang zulässig sein soll, sollten Sie ihn so schreiben, dass das Verweigerungsergebnis der Standardfall ist und das Ergebnis zulassen nur auftritt, wenn der Code ausdrücklich zulässig ist.

Schützen von Entwicklerumgebungen

Entwicklerarbeitsstationen müssen mit starken Netzwerk- und Identitätssteuerelementen geschützt werden, um die Gefährdung zu verhindern. Stellen Sie sicher, dass Sicherheitsupdates sorgfältig angewendet werden.

Build-Agents sind hochgradig privilegierte Und haben Zugriff auf den Buildserver und den Code. Sie müssen mit demselben Rigor wie Ihre Workloadkomponenten geschützt werden. Dies bedeutet, dass der Zugriff auf Build-Agents authentifiziert und autorisiert werden muss, sie sollten mit Firewall-Steuerelementen segmentiert werden, sie sollten der Überprüfung von Sicherheitsrisiken unterliegen usw. Von Microsoft gehostete Build-Agents sollten gegenüber selbst gehosteten Build-Agents bevorzugt werden. Von Microsoft gehostete Agents bieten Vorteile wie saubere virtuelle Computer für jede Ausführung einer Pipeline.

Benutzerdefinierte Build-Agents erhöhen die Verwaltungskomplexität und können zu einem Angriffsvektor werden. Die Anmeldeinformationen des Buildcomputers müssen sicher gespeichert werden, und Sie müssen regelmäßig temporäre Buildartefakte aus dem Dateisystem entfernen. Sie können die Netzwerkisolation erreichen, indem Sie nur ausgehenden Datenverkehr vom Build-Agent zulassen, da es das Pullmodell der Kommunikation mit Azure DevOps verwendet.

Das Quellcode-Repository muss ebenfalls geschützt werden. Gewähren Sie zugriff auf Coderepositorys auf Bedarfsbasis und reduzieren Sie die Gefährdung von Sicherheitsrisiken so weit wie möglich, um Angriffe zu vermeiden. Führen Sie einen gründlichen Prozess aus, um Code für Sicherheitsrisiken zu überprüfen. Verwenden Sie Sicherheitsgruppen für diesen Zweck, und implementieren Sie einen Genehmigungsprozess, der auf geschäftlichen Begründungen basiert.

Schützen von Code in Bereitstellungspipelines

Es reicht nicht aus, nur Code zu sichern. Wenn sie in ausnutzbaren Pipelines ausgeführt wird, sind alle Sicherheitsanstrengungen vergeblich und unvollständig. Build- und Releaseumgebungen müssen auch geschützt werden, da Sie verhindern möchten, dass schlechte Akteure schädlichen Code in Ihrer Pipeline ausführen.

Verwalten eines aktuellen Inventars jeder Komponente, die in Ihre Anwendung integriert ist

Jede neue Komponente, die in eine Anwendung integriert ist, erhöht die Angriffsfläche. Um die ordnungsgemäße Verantwortlichkeit und Warnung sicherzustellen, wenn neue Komponenten hinzugefügt oder aktualisiert werden, sollten Sie über einen Bestand dieser Komponenten verfügen. Speichern Sie es außerhalb der Buildumgebung. Überprüfen Sie regelmäßig, ob Ihr Manifest dem entspricht, was in Ihrem Buildprozess enthalten ist. Dadurch wird sichergestellt, dass keine neuen Komponenten, die Hintertüren oder andere Schadsoftware enthalten, unerwartet hinzugefügt werden.

Pipelineaufgaben

  • Ziehen Sie Aufgaben in Ihrer Pipeline aus vertrauenswürdigen Quellen, z. B. Azure Marketplace. Führen Sie Aufgaben aus, die von Ihrem Pipelineanbieter geschrieben wurden. Wir empfehlen GitHub-Aufgaben oder GitHub-Aktionen. Wenn Sie GitHub-Workflows verwenden, bevorzugen Sie von Microsoft erstellte Aufgaben. Überprüfen Sie außerdem Aufgaben, da sie im Sicherheitskontext Ihrer Pipeline ausgeführt werden.

  • Geheime Pipelineschlüssel. Bereitstellungsressourcen, die in einer Pipeline ausgeführt werden, haben Zugriff auf alle geheimen Schlüssel in dieser Pipeline. Haben Sie für verschiedene Phasen der Pipeline eine ordnungsgemäße Segmentierung, um unnötige Gefährdungen zu vermeiden. Verwenden Sie geheime Speicher, die in die Pipeline integriert sind. Denken Sie daran, dass Sie geheime Schlüssel in einigen Situationen vermeiden können. Erkunden Sie die Verwendung von Workloadidentitäten (für die Pipelineauthentifizierung) und verwaltete Identitäten (für die Dienst-zu-Dienst-Authentifizierung).

Trennen sie unterschiedliche Umgebungen

Daten, die in unterschiedlichen Umgebungen verwendet werden, müssen getrennt gehalten werden. Produktionsdaten sollten nicht in niedrigeren Umgebungen verwendet werden, da diese Umgebungen möglicherweise nicht über die strengen Sicherheitskontrollen verfügen, die die Produktion hat. Vermeiden Sie die Verbindung von einer Nicht-Produktionsanwendung mit einer Produktionsdatenbank, und vermeiden Sie das Verbinden von Nichtproduktionskomponenten mit Produktionsnetzwerken.

Progressive Belichtung

Verwenden Sie die progressive Gefährdung, um Features für eine Teilmenge von Benutzern basierend auf ausgewählten Kriterien freizugeben. Wenn Probleme auftreten, wird die Auswirkung für diese Benutzer minimiert. Dieser Ansatz ist eine gängige Risikominderungsstrategie, da sie die Fläche reduziert. Wenn das Feature reift und Sie mehr Vertrauen in Sicherheitsüberprüfungen haben, können Sie es schrittweise für eine breitere Gruppe von Benutzern freigeben.

Schützen von Code in der Produktion

Die Produktionsphase stellt die letzte verantwortungsvolle Möglichkeit dar, Sicherheitslücken zu beheben. Bewahren Sie eine Aufzeichnung des goldenen Bilds auf, das in der Produktion veröffentlicht wird.

Beibehalten von Versionsartefakten

Bewahren Sie einen Katalog aller bereitgestellten Ressourcen und deren Versionen auf. Diese Informationen sind während der Vorfallstriage hilfreich, wenn Sie Probleme beheben und das System wieder in den Arbeitszustand zurückverwenden. Versionsverwaltungsressourcen können auch mit veröffentlichten CVE-Benachrichtigungen verglichen werden. Sie sollten diese Vergleiche automatisiert durchführen.

Notfallkorrekturen

Ihr automatisiertes Pipelinedesign sollte die Flexibilität haben, regelmäßige und Notfallbereitstellungen zu unterstützen. Diese Flexibilität ist wichtig, um schnelle und verantwortungsvolle Sicherheitsfixes zu unterstützen.

Eine Freigabe ist in der Regel mehreren Genehmigungsgaten zugeordnet. Erwägen Sie das Erstellen eines Notfallprozesses, um Sicherheitsupdates zu beschleunigen. Der Prozess kann die Kommunikation zwischen Teams umfassen. Die Pipeline sollte schnelle Roll-Forward- und Rollbackbereitstellungen ermöglichen, die Sicherheitsfixes, kritische Fehler und Codeupdates behandeln, die außerhalb des regulären Bereitstellungslebenszyklus auftreten.

Hinweis

Priorisieren Sie immer Sicherheitsfixes über den Komfort. Eine Sicherheitskorrektur sollte keine Regression oder einen Fehler einführen. Wenn Sie den Fix über eine Notfallpipeline beschleunigen möchten, überlegen Sie sorgfältig, welche automatisierten Tests umgangen werden können. Bewerten Sie den Wert der einzelnen Tests anhand der Ausführungszeit. Zum Beispiel sind Komponententests in der Regel schnell abgeschlossen. Integrations- oder End-to-End-Tests können sehr lange laufen.

Verwalten der Codesicherheit während des gesamten Lebenszyklus

Ziel dieser Phase ist es, sicherzustellen, dass der Sicherheitsstatus im Laufe der Zeit nicht abfällt. SDLC ist ein fortlaufender agiler Prozess. Konzepte, die in den vorherigen Phasen behandelt werden, gelten für diese Phase, da sich die Anforderungen im Laufe der Zeit ändern.

Patchverwaltung: Halten Sie Software-, Bibliotheken- und Infrastrukturkomponenten mit Sicherheitspatches und Updates auf dem neuesten Stand.

Kontinuierliche Verbesserung. Bewerten und verbessern Sie die Sicherheit des Softwareentwicklungsprozesses kontinuierlich, indem Sie Codeüberprüfungen, Feedback, gelernte Erkenntnisse und sich entwickelnde Bedrohungen berücksichtigen.

Veraltete Objekte , die veraltet oder nicht mehr verwendet werden, werden außer Betrieb genommen. Dadurch wird die Fläche der Anwendung reduziert.

Wartung umfasst auch Vorfallbehebungen. Wenn Probleme in der Produktion gefunden werden, müssen sie umgehend wieder in den Prozess integriert werden, damit sie nicht wieder auftreten.

Verbessern Sie kontinuierlich Ihre sicheren Codierungsmethoden, um mit der Bedrohungslandschaft schritt zu halten.

Azure-Erleichterung

Microsoft Security Development Lifecycle (SDL) empfiehlt sichere Methoden, die Sie auf Ihren Entwicklungslebenszyklus anwenden können. Weitere Informationen finden Sie unter Microsoft Security Development Lifecycle.

Defender für DevOps und die SAST-Tools sind bestandteil von GitHub Advanced Security oder Azure DevOps. Diese Tools können Ihnen helfen, eine Sicherheitsbewertung für Ihre Organisation nachzuverfolgen.

Folgen Sie den Azure-Sicherheitsempfehlungen, die in diesen Ressourcen beschrieben werden:

Um Anmeldeinformationen im Quellcode zu finden, sollten Sie Tools wie GitHub Advanced Security und OWASP-Quellcodeanalysetools verwenden.

Überprüfen Sie die Sicherheit von Open-Source-Code in Ihrer Anwendung. Diese kostenlosen Tools und Ressourcen können Ihnen bei Ihrer Bewertung helfen:

Checkliste für die Sicherheit

Lesen Sie den vollständigen Satz von Empfehlungen.

Checkliste für die Sicherheit