Empfehlungen zum Sichern eines Entwicklungslebenszyklus

  • Artikel

Gilt für die folgende Empfehlung der Sicherheitsprüfliste für Azure Well-Architected Framework:

SE:02 Sorgen Sie für einen sicheren Entwicklungslebenszyklus, indem Sie eine gehärtete, größtenteils automatisierte und überprüfbare Softwarelieferkette verwenden. Integrieren Sie einen sicheren Entwurf, indem Sie die Bedrohungsmodellierung verwenden, um sich vor Implementierungen zu schützen, die die Sicherheit gefährden.

Verwandter Leitfaden: Bedrohungsanalyse

In diesem Leitfaden werden die Empfehlungen zum Härten Von Code, Entwicklungsumgebung und Softwarelieferkette beschrieben, indem bewährte Sicherheitsmethoden während des 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 wie folgt:

  • Automatisieren von Sicherheitstests und -validierungen.

  • Implementieren von Tools wie Sicherheitspipelines zum Überprüfen von Code und Infrastructure-as-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 Sicherheitsmängeln sein, um Vertraulichkeit, Integrität und Verfügbarkeit zu gewährleisten.

Es reicht nicht aus, nur die Infrastrukturebene mithilfe von Identitäts- und Netzwerksteuerungen und anderen Maßnahmen zu schützen. Verhindern Sie eine fehlerhafte Implementierung von Code oder einen kompromittierten Codeblock , um Ihren allgemeinen Sicherheitsstatus zu stärken. Die Nutzungsebene, d. h. der Anwendungscode, muss ebenfalls gehärtet werden. Der Prozess der Integration von Sicherheit in Ihren Entwicklungslebenszyklus ist im Wesentlichen ein Härtungsprozess. Ebenso wie die Ressourcenhärtung ist die Straffung der Codeentwicklung auch kontextunabhängig. Der Fokus liegt auf der Erhöhung der Sicherheit und nicht auf den funktionalen Anforderungen der Anwendung. Informationen zur Härtung 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- und Complianceanforderungen unterstützen.
Softwareentwicklungslebenszyklus (SDLC) Ein mehrstufiger, systematischer Prozess zur Entwicklung von Softwaresystemen.

Wichtige Entwurfsstrategien

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

  • Entwurfsentscheidungen führen nicht zu Sicherheitslücken.

  • Anwendungscode und Konfiguration schaffen keine Sicherheitsrisiken aufgrund von ausnutzbaren Implementierungen und falschen Programmierpraktiken.

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

  • Anwendungscode, Build- und Bereitstellungsprozesse werden nicht manipuliert.

  • Durch Vorfälle aufgedeckte Sicherheitsrisiken werden entschärft.

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

  • Complianceanforderungen werden nicht kompromittiert oder reduziert.

  • Die Überwachungsprotokollierung wird in Entwicklerumgebungen implementiert.

Die folgenden Abschnitte enthalten Sicherheitsstrategien für die häufig praktizierten Phasen von SDLC.

Anforderungsphase

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

Betrachten Sie beispielsweise eine Anwendung, die kritische Benutzerflows unterstützen muss, die es dem Benutzer ermöglichen, Daten hochzuladen und zu bearbeiten. Die Sicherheitsentwurfsoptionen sollten Zusicherungen für die Interaktion des Benutzers mit der Anwendung umfassen, z. B. die Authentifizierung und Autorisierung der Benutzeridentität, das Zulassen von nur zulässigen Aktionen für die Daten und das Verhindern der SQL-Einschleusung. Ebenso decken Sie nicht funktionale Anforderungen wie Verfügbarkeit, Skalierbarkeit und Wartbarkeit ab. Sicherheitsoptionen sollten Segmentierungsgrenzen, ein- und ausgehende Firewall sowie andere übergreifende Sicherheitsbedenken umfassen.

Alle diese Entscheidungen sollten zu einer guten Definition des Sicherheitsstatus der Anwendung führen. Dokumentieren Sie die Sicherheitsanforderungen in einer vereinbarten Spezifikation und geben Sie sie im Backlog an. Es sollte explizit die Sicherheitsinvestitionen sowie die Kompromisse und Risiken angeben, die das Unternehmen zu übernehmen bereit ist, wenn die Investitionen nicht von den Geschäftsbeteiligten genehmigt werden. Sie können z. B. die Notwendigkeit dokumentieren, eine Web Application Firewall (WAF) vor Ihrer Anwendung zu verwenden, z. B. Azure Front Door oder Azure Application Gateway. Wenn Die Projektbeteiligten im Unternehmen nicht bereit sind, die zusätzlichen Kosten für die Ausführung einer WAF zu akzeptieren, müssen sie das Risiko akzeptieren, dass Angriffe auf Anwendungsebene auf die Anwendung gerichtet werden können.

Die Erfassung von Sicherheitsanforderungen ist ein wichtiger Bestandteil dieser Phase. Ohne diesen Aufwand basieren die Entwurfs- und Implementierungsphasen auf nicht ausgewählten 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.

Entwurfsphase

Während dieser Phase werden die Sicherheitsanforderungen auf technische Anforderungen umgestellt. Dokumentieren Sie in Ihrer technischen Spezifikation alle Entwurfsentscheidungen, um Mehrdeutigkeiten während der Implementierung zu vermeiden. Hier sind einige typische Aufgaben:

Definieren der Sicherheitsdimension der Systemarchitektur

Überlagern Sie die Architektur mit Sicherheitskontrollen. Beispielsweise Steuerelemente, die für die Isolationsgrenzen gemäß Ihrer Segmentierungsstrategie praktisch sind, die Typen von Identitäten, die für die Komponenten der Anwendung benötigt werden, und den Typ 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 plattformseitig bereitgestellten Angeboten

Es ist wichtig, die Aufteilung der Verantwortung zwischen Ihnen und dem Cloudanbieter zu verstehen. Vermeiden Sie beispielsweise Überschneidungen mit nativen Azure-Sicherheitskontrollen. Sie erhalten eine bessere Sicherheitsabdeckung und können Entwicklungsressourcen den Anforderungen der Anwendung neu zuweisen.

Wenn Ihr Entwurf beispielsweise eine Web Application Firewall für eingehenden Datenverkehr aufruft, können Sie diese Verantwortung an einen Lastenausgleich wie Application Gateway oder Azure Front Door auslagern. Vermeiden Sie die Replikation von Features als benutzerdefinierten Code in Ihrer Anwendung.

Wählen Sie nur vertrauenswürdige Frameworks, Bibliotheken und Supply Chain-Software aus. Ihr Entwurf sollte auch die sichere Versionskontrolle angeben. Anwendungsabhängigkeiten sollten von vertrauenswürdigen Parteien stammen. Drittanbieter sollten in der Lage sein, Ihre Sicherheitsanforderungen zu erfüllen und ihren Plan zur verantwortungsvollen Offenlegung zu teilen. Jeder Sicherheitsvorfall sollte umgehend gemeldet werden, damit Sie die erforderlichen Maßnahmen ergreifen können. Außerdem können bestimmte Bibliotheken von Ihrem organization verboten werden. Beispielsweise kann Software vor Sicherheitsrisiken geschützt sein, aber aufgrund von Lizenzierungseinschränkungen immer noch nicht zugelassen werden.

Um sicherzustellen, dass diese Anleitung von allen Mitwirkenden an der Software befolgt wird, führen Sie eine Liste genehmigter und/oder nicht genehmigter Frameworks, Bibliotheken und Anbieter. Platzieren Sie nach Möglichkeit Schutzplanken in den Entwicklungspipelines, um die Liste zu unterstützen. Automatisieren Sie so weit wie möglich die Verwendung von Tools, um Abhängigkeiten auf Sicherheitsrisiken zu überprüfen .

Bestimmen Sie die Sicherheitsentwurfsmuster, die der Anwendungscode implementieren soll.

Muster können Sicherheitsbedenken wie Segmentierung und Isolation, 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 zu Sicherheitsrisiken führen kann.

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

Sicheres Speichern von Anwendungsgeheimnissen

Implementieren Sie sicher die Verwendung von Anwendungsgeheimnissen und vorinstallierten 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 wird, kein weiterer Zugriff erhalten wird. Im Allgemeinen finden Sie Möglichkeiten, Geheimnisse 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

Führen Sie während dieser Phase eine Bedrohungsmodellierung durch. Die Bedrohungsmodellierung kann bestätigen, dass Entwurfsentscheidungen an Den Sicherheitsanforderungen ausgerichtet sind und Lücken offenlegen, die Sie beheben sollten. Wenn Ihre Workload hochsensible Daten verarbeitet, sollten Sie in Sicherheitsexperten investieren, die Ihnen bei der Bedrohungsmodellierung helfen können.

Die erste Übung zur Bedrohungsmodellierung sollte während der Entwurfsphase erfolgen, wenn die Architektur der Software und der allgemeine Entwurf definiert werden. Wenn Sie dies in dieser Phase tun, können Sie potenzielle Sicherheitsprobleme identifizieren, bevor sie in die Systemstruktur integriert werden. Diese Übung ist jedoch keine einmalige Aktivität. Es handelt sich um einen kontinuierlichen Prozess, der während der gesamten Entwicklung der Software fortgesetzt werden sollte.

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

Entwicklungs- und Testphase

Während dieser Phase besteht das Ziel darin, Sicherheitsfehler und Manipulationen von Code-, Build- und Bereitstellungspipelines zu verhindern.

Gut geschult in sicheren Codepraktiken sein

Das Entwicklungsteam sollte über eine formelle und spezialisierte Schulung in sicheren Programmierpraktiken verfügen. Web- und API-Entwickler benötigen z. B. möglicherweise spezifische Schulungen zum Schutz vor websiteübergreifenden Skriptangriffen, und Back-End-Entwickler können von fundierten Schulungen profitieren, um Angriffe auf Datenbankebene wie SQL-Einschleusungsangriffe zu vermeiden.

Entwickler sollten diese Schulung absolvieren müssen, bevor sie Zugriff auf Den Produktionsquellcode erhalten.

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

Verwenden von Sicherheitstesttools

Führen Sie eine Bedrohungsmodellierung durch, um die Sicherheit der Anwendungsarchitektur zu bewerten.

Verwenden Sie statische Anwendungssicherheitstests (SAST), um Code auf 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 in Sicherheitsdomänen nach Fehlern suchen 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 die Branchenstandards für sichere Codierungsmethoden. Weitere Informationen finden Sie im Abschnitt Communityressourcen dieses Artikels.

Verwenden Sie Linter und Codeanalysetools, um zu verhindern, dass Anmeldeinformationen in das Quellcoderepository gepusht werden. Beispielsweise untersuchen .NET Compiler Platform (Roslyn) Analyzer Ihren Anwendungscode.

Verwenden Sie während des Buildprozesses Pipeline-Add-Ons, um Anmeldeinformationen im Quellcode abzufangen. Überprüfen Sie alle Abhängigkeiten, z. B. Bibliotheken von Drittanbietern und Frameworkkomponenten, im Rahmen des Continuous Integration-Prozesses. 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 von Tests. Informationen zu Sicherheitstests im Allgemeinen finden Sie unter Empfehlungen für Sicherheitstests.

Schreiben von gerade genug Code

Wenn Sie Ihren Codebedarf reduzieren, verringern Sie auch die Wahrscheinlichkeit von Sicherheitsfehlern. Verwenden Sie Code und Bibliotheken, die bereits verwendet werden und sicherheitsvalidiert wurden , anstatt Code zu duplizieren.

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

Schreiben Sie Code standardmäßig mit einem Deny-All-Ansatz. Erstellen Sie Zulassungslisten nur für Entitäten, die Zugriff benötigen. Wenn Sie beispielsweise Code haben, der bestimmen muss, ob ein privilegierter Vorgang zulässig sein soll, sollten Sie ihn so schreiben, dass das Ablehnungsergebnis der Standardfall ist und das Allow-Ergebnis nur auftritt, wenn es vom Code ausdrücklich zugelassen wird.

Schützen von Entwicklerumgebungen

Entwicklerarbeitsstationen müssen mit starken Netzwerk- und Identitätskontrollen geschützt werden, um eine Offenlegung zu verhindern. Stellen Sie sicher, dass Sicherheitsupdates sorgfältig angewendet werden.

Build-Agents verfügen über hohe Berechtigungen und haben Zugriff auf den Buildserver und den Code. Sie müssen mit der gleichen Strenge wie Ihre Workloadkomponenten geschützt werden. Dies bedeutet, dass der Zugriff auf Build-Agents authentifiziert und autorisiert werden muss, dass sie mit Firewallsteuerelementen im Netzwerk segmentiert sein sollten, dass sie sicherheitsrelevanten Überprüfungen unterzogen werden müssen usw. Von Microsoft gehostete Build-Agents sollten gegenüber selbstgehosteten Build-Agents bevorzugt werden. Von Microsoft gehostete Agents bieten Vorteile wie sauber virtuellen Computern 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 alle temporären Buildartefakte aus dem Dateisystem entfernen. Sie können die Netzwerkisolation erreichen, indem Sie nur ausgehenden Datenverkehr vom Build-Agent zulassen, da er das Pullmodell der Kommunikation mit Azure DevOps verwendet.

Das Quellcoderepository muss ebenfalls geschützt werden . Gewähren Sie zugriff auf Coderepositorys nach Bedarf, und verringern Sie die Gefährdung von Sicherheitsrisiken so weit wie möglich, um Angriffe zu vermeiden. Verfügen Sie über einen gründlichen Prozess, um Code auf Sicherheitsrisiken zu überprüfen. Verwenden Sie zu diesem Zweck Sicherheitsgruppen, und implementieren Sie einen Genehmigungsprozess, der auf geschäftlichen Begründungen basiert.

Sichere Codebereitstellungen

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 ebenfalls geschützt werden , da Sie verhindern möchten, dass schlechte Akteure schädlichen Code in Ihrer Pipeline ausführen.

Verwalten eines aktuellen Inventars aller Komponenten, die in Ihre Anwendung integriert sind

Jede neue Komponente, die in eine Anwendung integriert ist, erhöht die Angriffsfläche. Um eine ordnungsgemäße Verantwortlichkeit und Warnungen beim Hinzufügen oder Aktualisieren neuer Komponenten sicherzustellen, sollten Sie über einen Bestand dieser Komponenten verfügen. Speichern Sie sie außerhalb der Buildumgebung. Überprüfen Sie in regelmäßigen Abständen, ob Ihr Manifest mit dem übereinstimmt, 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

  • Pulltasks 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 Actions. 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.

  • Pipelinegeheimnisse. Bereitstellungsressourcen, die innerhalb einer Pipeline ausgeführt werden, haben Zugriff auf alle Geheimnisse in dieser Pipeline. Verfügen Sie über eine ordnungsgemäße Segmentierung für verschiedene Phasen der Pipeline , um unnötige Offenlegungen zu vermeiden. Verwenden Sie geheime Speicher, die in die Pipeline integriert sind. Denken Sie daran, dass Sie in einigen Situationen die Verwendung von Geheimnissen vermeiden können. Erkunden Sie die Verwendung von Workloadidentitäten (für die Pipelineauthentifizierung) und verwalteten Identitäten (für die Dienst-zu-Dienst-Authentifizierung).

Trennen verschiedener Umgebungen

Daten, die in verschiedenen 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 für die Produktion verfügen. Vermeiden Sie eine Verbindung von einer Nichtproduktionsanwendung mit einer Produktionsdatenbank, und vermeiden Sie die Verbindung von Nichtproduktionskomponenten mit Produktionsnetzwerken.

Progressive Belichtung

Verwenden Sie die progressive Veröffentlichung von Features für eine Teilmenge von Benutzern basierend auf den ausgewählten Kriterien. Wenn Probleme auftreten, werden die Auswirkungen auf diese Benutzer minimiert. Dieser Ansatz ist eine gängige Strategie zur Risikominderung, da die Oberfläche reduziert wird. Wenn das Feature reift und Sie mehr Vertrauen in Sicherheitszusicherungen haben, können Sie es schrittweise für eine breitere Gruppe von Benutzern freigeben.

Produktionsphase

Die Produktionsphase bietet die letzte verantwortungsvolle Gelegenheit, Sicherheitslücken zu beheben. Führen Sie eine Aufzeichnung des goldenen Bilds, das in der Produktion veröffentlicht wird.

Beibehalten von Artefakten mit Versionsangabe

Bewahren Sie einen Katalog aller bereitgestellten Ressourcen und deren Versionen auf. Diese Informationen sind während der Incident-Selektierung nützlich, wenn Sie Probleme beheben und wenn Sie das System wieder in den Betriebszustand versetzen. Verwaltete Ressourcen können auch mit den veröffentlichten Hinweisen zu allgemeinen Sicherheitsrisiken (Common Vulnerabilities and Exposures, CVE) verglichen werden. Sie sollten die Automatisierung verwenden, um diese Vergleiche durchzuführen.

Notfallkorrekturen

Ihr automatisierter Pipelineentwurf sollte die Flexibilität haben, sowohl reguläre als auch Notfallbereitstellungen zu unterstützen. Diese Flexibilität ist wichtig, um schnelle und verantwortungsvolle Sicherheitskorrekturen zu unterstützen.

Ein Release ist in der Regel mehreren Genehmigungsgates zugeordnet. Erwägen Sie die Erstellung eines Notfallprozesses, um Sicherheitskorrekturen zu beschleunigen. Der Prozess kann die Kommunikation zwischen Teams umfassen. Die Pipeline sollte schnelle Rollforward- und Rollbackbereitstellungen ermöglichen, die Sicherheitskorrekturen, kritische Fehler und Codeupdates behandeln, die außerhalb des regulären Bereitstellungslebenszyklus auftreten.

Hinweis

Priorisieren Sie Immer Sicherheitsfixes vor Komfort. Ein Sicherheitsfix sollte keine Regression oder einen Fehler einführen. Wenn Sie die Behebung durch 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.

Wartungsphase

Das Ziel dieser Phase besteht darin , sicherzustellen, dass der Sicherheitsstatus im Laufe der Zeit nicht verfällt. SDLC ist ein fortlaufender agiler Prozess. In den vorherigen Phasen behandelte Konzepte 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. Kontinuierlich bewerten und verbessern Sie die Sicherheit des Softwareentwicklungsprozesses, indem Sie Codeüberprüfungen, Feedback, gelernte Erkenntnisse und sich entwickelnde Bedrohungen berücksichtigen.

Außerbetriebnahme von veralteten oder nicht mehr verwendeten Legacyressourcen. Dadurch wird die Oberfläche der Anwendung reduziert.

Die Wartung umfasst auch Incidentfixes. Wenn Probleme in der Produktion gefunden werden, müssen sie umgehend wieder in den Prozess integriert werden, damit sie nicht erneut 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 teil von GitHub Advanced Security oder Azure DevOps. Mit diesen Tools können Sie eine Sicherheitsbewertung für Ihre organization nachverfolgen.

Befolgen Sie die Azure-Sicherheitsempfehlungen, die in den folgenden Ressourcen beschrieben werden:

Um Anmeldeinformationen im Quellcode zu finden, erwägen Sie die Verwendung von Tools wie GitHub Advanced Security und OWASP-Quellcodeanalysetools.

Ü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

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Checkliste für die Sicherheit