DevOps in DevSecOps verschieben

Während Sie eine Entwicklungssicherheitsdisziplin erstellen oder modernisieren, beschreibt dieser Artikel, wie die Integration von Sicherheit in Entwicklungsmethoden die Umstellung von Entwicklervorgängen (DevOps) auf Entwicklersicherheitsvorgänge (DevSecOps) ermöglicht und die Bereitstellung von Anwendungen sichert.

Moderne Organisationen verlassen sich auf eine schnelle Softwareentwicklung, um Innovationen zu liefern, auf sich ändernde Geschäftsanforderungen zu reagieren und den Wettbewerbsvorteil aufrechtzuerhalten. DevOps ermöglicht diese Flexibilität durch kontinuierliche Integration und Bereitstellung. Höhere Geschwindigkeit führt jedoch auch zu neuen Sicherheitsrisiken.

Kontinuierliche Veröffentlichungszyklen verringern die Zeit zwischen Entwurfsentscheidungen und Produktionsbereitstellung, wodurch die Wahrscheinlichkeit erhöht wird, dass Schwachstellen in Produktionsumgebungen eingeführt werden, darunter:

• Schwächen des Anwendungsdesigns
• Anfällige Abhängigkeiten
• Konfigurationsfehler
• Fehler bei der Infrastrukturautomatisierung
• Schlechte Verwaltung von Geheimnissen oder Hygiene.

DevOps-Risiko

Moderne DevOps-Umgebungen erweitern die Angriffsfläche über Entwicklungs-, Pipeline- und Produktionssysteme hinweg. DevOps-Tools wie Quellcoderepositorys, Pipelines und Automatisierungssysteme sind hochwertige Ziele für Angreifer.

Wenn bösartiger Code frühzeitig eingeführt wird, kann er vorhandene Sicherheitskontrollen durchlaufen und Produktionssysteme erreichen.

Zu den allgemeinen Angriffszielen gehören:

• Einfügen von bösartigem Code in Buildartefakte.
• Kompromittierung von Identitäten von Entwicklern oder Dienstkonten.
• Zugreifen auf oder Exfiltrieren von Produktionsdaten.

Angreifer zielen häufig auf benutzerdefinierte Anwendungen und Entwicklungsumgebungen ab, um Zugriff auf:

• Vertrauliche Organisations- oder Kundendaten.
• Proprietäre Geschäftslogik und geistiges Eigentum.
• Produktionsinfrastruktur durch kompromittierte Entwicklungssysteme.
• Nachgeschaltete Kunden durch Software-Lieferkettenkompromittierung.

Mögliche Sicherheitsrisiken werden im folgenden Diagramm zusammengefasst:

Anwendungs- und Entwicklungsrisiko

Anwendungsarbeitslasten können durch Schwachstellen beeinträchtigt werden, die während der Entwicklung oder durch Kompromittierung der zum Erstellen und Bereitstellen verwendeten Infrastruktur eingeführt wurden.

Risiko	Ziel	Mögliches Ergebnis
App-Design/-Implementierung	Sicherheitsprobleme, die beim Entwurf oder bei der Entwicklung entstehen, können Workloads Angriffstechniken aussetzen, wie zum Beispiel: – Falsche Eingabeüberprüfung – Unsichere Authentifizierungs- oder Autorisierungslogik - Schwache oder unsachgemäß implementierte Kryptografie – Offenlegung vertraulicher Daten über Anwendungslogik	Diese Schwachstellen ermöglichen Angreifern u. U. Folgendes: – Zugreifen oder Bearbeiten von Anwendungsdaten - Nicht autorisierte Vorgänge ausführen - Beibehalten des dauerhaften Zugriffs durch implantierte Logikfehler.
Entwicklungsinfrastruktur/Automatisierung	Angriffe können auf Folgendes abzielen: - Quellcode-Repositorys - Erstellen von Pipelines – Bereitstellungsautomatisierung - Infrastructure-as-Code(IaC)-Vorlagen – Entwickeln von Endpunkten oder Dienstidentitäten	Eine Kompromittierung kann Angreifern Folgendes ermöglichen: - Einfügen von bösartigem Code in Buildartefakte – Ändern von Bereitstellungskonfigurationen - Aufrechterhalten des dauerhaften Zugriffs durch implantierte Logikfehler – Abrufen von Anmeldeinformationen oder geheimen Schlüsseln, die in Produktionsumgebungen verwendet werden.
Dev Software Supply Chain	Anwendungen basieren in der Regel auf: - Drittanbieterbibliotheken - Open-Source-Pakete - Containerimages - Plattformdienste	Sicherheitsrisiken oder bösartiger Code, der über diese Abhängigkeiten eingeführt wurde, können folgende Auswirkungen haben: - Produktionsworkloads in Organisationen – Kunden- oder Partnerumgebungen

Die Integration von Sicherheitsaspekten in Entwicklungsprozesse verringert die Wahrscheinlichkeit, dass diese Risiken bis in die Produktivfreigabe gelangen.

Verlagerung nach links

Shift left ist ein Sicherheitstechnikansatz, der die Sicherheit früher im Entwicklungslebenszyklus integriert.

Anstatt Sicherheit erst spät im Prozess zu prüfen, integrieren Organisationen sie in:

• Vergegenwärtigend
• Design
• Entwicklung
• Operations

Dies reduziert die Wartungskosten und die Risikogefährdung.

Um diesen Ansatz zu unterstützen, sollten Organisationen

• Verwenden Sie strukturierte bewährte Methoden wie den Security Development Lifecycle (SDL) frühzeitig im Prozess, anstatt zu spät, wenn Probleme teuer und schwierig zu beheben sind.
• Um diesen Ansatz aufrechtzuerhalten, integrieren Sie Governance, Risiko und Compliance (GRC) in die Entwicklungsstrategie.

Was ist DevSecOps?

DevSecOps bietet den Shift Left-Ansatz, indem DevOps erweitert und Sicherheit in jede Phase des Softwareentwicklungslebenszyklus eingebettet wird – von der Idee bis hin zu Design, Entwicklung und Betrieb.

• Bei herkömmlichen Entwicklungsansätzen wurde die Sicherheitsüberprüfung häufig vor der Veröffentlichung als endgültiges Qualitätsgate durchgeführt. Dadurch entstanden Verzögerungen, erhöhte Wartungskosten und erlaubten Sicherheitslücken, bis zum ende des Lebenszyklus fortbestehen zu können.

• DevSecOps verschiebt die Sicherheit früher und bettet sie kontinuierlich in Entwicklungs- und Betriebsprozesse ein.

• DevSecOps reduziert die Reibung zwischen Entwicklungs-, Betriebs- und Sicherheitsteams, richtet sie an gemeinsame Ziele von Innovationsgeschwindigkeit, Zuverlässigkeit und Sicherheitsresilienz aus und ermöglicht es Teams, die wichtigsten Probleme frühzeitig und kontinuierlich zu beheben.

• DevSecOps integriert Sicherheit in:

  • Architekturdesign
  • Anwendungsimplementierung
  • Infrastrukturautomatisierung
  • Bereitstellungs- und Betriebsprozesse

Benefits

DevSecOps ermöglicht Entwicklungs-, Sicherheits- und Betriebsteams:

• Identifizieren und Beheben von Problemen früher im Lebenszyklus.
• Reduzieren Sie die Exposition in der Produktion.
• Halten Sie die Liefergeschwindigkeit beim Verwalten von Risiken aufrecht.

Sicherheit wird Teil der Erstellung und Lieferung von Software statt eines Steuerelements, das nach der Lieferung angewendet wird.

Sicherer Innovationslebenszyklus

Innovation schreitet in der Regel durch zwei Lebenszyklusphasen voran:

Bühne	Details
Ideeninkubation	Eine Funktion ist für die anfängliche Produktionsverwendung konzipiert, implementiert und validiert. Es beginnt mit einer neuen Idee
Erstes Release	Eine erste Produktionsversion erfüllt die Mindestproduktkriterien für die sichere Produktverwendung. - Entwicklung: Funktionalität erfüllt die Mindestanforderungen für Unternehmen. - Sicherheit: Funktionen erfüllen die gesetzlichen Compliance-, Sicherheits- und Sicherheitsanforderungen für den Produktionseinsatz. - Operationen: Die Funktionalität erfüllt die Mindestanforderungen an Qualität, Leistung und Unterstützung als Produktionssystem.

Nach der Erstveröffentlichung erfolgt die Entwicklung iterativ, da sich die Workloads weiterentwickeln:

• Ändern der Risikotoleranz
• Anwendungsanforderungen und Reifegrad
• Regulatorische Verpflichtungen
• Bedrohungsbedingungen

Integrieren von Sicherheit in die Entwicklung

Herkömmliche Entwicklungsansätze validieren Sicherheitsaspekte erst spät im Lebenszyklus, als letzte Hürde vor der Veröffentlichung, nachdem Entwurf und Implementierung abgeschlossen sind. In modernen Entwicklungsumgebungen führt eine verzögerte Validierung zu Folgendem:

• Komplexität der Schwachstelle
• Wartungskosten
• Betriebsverzögerungen und Unterbrechungen
• Erhöhte Risikobelastung durch aktive Ausbeutung

DevSecOps integriert die Sicherheit kontinuierlich während der gesamten Entwicklung und des Betriebs, um Probleme früher zu beheben, Risiken zu reduzieren und die Konsistenz zu verbessern.

Wichtige Methoden

Sicherheit muss in bestehende Entwicklungsprozesse eingebettet werden, um effektiv, skalierbar und nachhaltig zu sein. Es sollte direkt in die Gestaltung, Erstellung, Bereitstellung und Bedienung von Apps integriert werden, die nicht in einem separaten oder parallelen Workflow implementiert werden. Es wird Folgendes empfohlen:

• Abbildung von End-to-End-Workflows von der Idee über Entwicklung und Bereitstellung bis hin zum laufenden Betrieb.
• Definieren klarer Rollen, Tools und Verantwortlichkeiten für die Sicherheit in jeder Phase des Lebenszyklus.
• Erstellen konsistenter Behebungspfade für Sicherheitsrisiken, Fehler und Entwurfsprobleme.

Passen Sie Sicherheitspraktiken basierend auf Arbeitsauslastungsrisiko an. Geschäftskritische Anwendungen erfordern eine höhere Strenge, während Szenarien mit niedrigeren Risiken optimierte Ansätze befolgen können.

Stellen Sie mindestens folgendes sicher:

• Identifizieren Sie die Phasen, Personen und Technologien, die an Ihrem Entwicklungslebenszyklus beteiligt sind.
• Definieren Sie, wie Sicherheitsaktivitäten in jede Phase integriert werden, anstatt sie als separate Prüfpunkte zu behandeln.
• Richten Sie Prozesse für die Behandlung wichtiger Änderungen und Routinefixes während des gesamten Lebenszyklus ein.

Automatisieren der Sicherheit in Entwicklung und Bereitstellung

Die Automatisierung ist unerlässlich, um die Sicherheit konsistent und in großem Umfang über Entwicklung und Betrieb hinweg zu erzwingen.

• Integrieren Sie Sicherheitskontrollen und Tools direkt in CI/CD-Pipelines.
• Automatisieren Sie wichtige Aktivitäten wie Bedrohungsmodellierung, Codeüberprüfung, Validierung und Richtlinienerzwingung.
• Verwenden Sie Infrastruktur als Code (IaC), um wiederholbare, sichere Bereitstellungen zu aktivieren.

Plattformgrundlagen wie Azure Landungszonen können diesen Ansatz unterstützen, indem

Plattformgrundlagen wie Azure Landing Zones können diesen Ansatz unterstützen, indem standardisierte Muster für Die Integration von Sicherheit, Governance und DevOps bereitgestellt werden.

Erwartete Ergebnisse

Organisationen, die von DevOps zu DevSecOps wechseln, können:

• Verringern der Wahrscheinlichkeit, dass Sicherheitsrisiken in Produktionsworkloads eingeführt werden
• Beschränken der Fähigkeit von Angreifern, Entwicklungsinfrastruktur oder Automatisierung auszunutzen
• Die Resilienz von Anwendungen gegenüber sich weiterentwickelnden Angriffstechniken verbessern
• Unterstützung gesetzlicher und organisatorischer Complianceanforderungen
• Aufrechterhalten der Innovationsgeschwindigkeit ohne Erhöhung des Betriebs- oder Sicherheitsrisikos

Tipps zum Navigieren auf der Reise

Die Einführung von DevSecOps erfordert organisatorische und kulturelle Veränderungen.

Veränderungen der Bildung und Kultur

Dies sind wichtige frühe Schritte. Das Team, das Sie haben, muss neue Fähigkeiten entwickeln und neue Perspektiven einführen, um das DevSecOps-Modell zu verstehen.

Der Wandel von Bildung und Kultur erfordert Zeit, Fokus, Unterstützung der Führungskräfte und regelmäßige Nachverfolgung, um Einzelpersonen dabei zu helfen, den Wert der Änderung vollständig zu verstehen und zu sehen.

Veränderungen von Kulturen und Fähigkeiten können manchmal auf die berufliche Identität einzelner Menschen eingehen und ein Potenzial für starken Widerstand schaffen. Es ist wichtig zu verstehen und auszudrücken, warum, was und wie sich die Veränderung für jede Person und ihre Situation ändert.

Die Änderung nimmt Zeit in Anspruch

Sie können sich nur so schnell bewegen, wie Sich Ihr Team an die Auswirkungen von Aufgaben auf neue Weise anpassen kann. Teams müssen ihre vorhandenen Aufgaben ausführen, während sie sich transformieren.

Es ist wichtig, sorgfältig zu priorisieren, was am wichtigsten ist, und die Erwartungen zu verwalten, wie schnell diese Änderung passieren kann.

Ein Fokus auf eine Schritt-für-Schritt-Strategie, bei der die wichtigsten und grundlegendsten Elemente zuerst kommen, kommt Ihrer Organisation zugute.

Änderung führt zu (temporären) Reibungen

Alle neuen Technologien, Methoden und andere Veränderungen führen zu Reibung und Verwirrung. Es ist wichtig, sich auf gesunde Reibung zu konzentrieren, die kritisches Denken antreibt, um Risiken zu reduzieren und ungesunde Reibung zu vermeiden, die Prozesse mit eingeschränktem Nutzen oder Risikoreduzierung verlangsamt.

Begrenzte Ressourcen

Eine Herausforderung, mit der Organisationen in der Regel frühzeitig konfrontiert sind, besteht darin, Talente und Fähigkeiten sowohl in der Sicherheits- als auch in der Anwendungsentwicklung zu finden.

Wenn Organisationen mit einer effektiveren Zusammenarbeit beginnen, finden sie möglicherweise versteckte Talente, z. B. Entwickler mit einer Sicherheits-Denkweise oder Sicherheitsexperten mit entwicklungsbezogenem Hintergrund.

Laufende Schichten

Apps ändern sich schnell. Neben neuen Features ändert sich die technische Definition und Zusammensetzung einer Anwendung grundlegend durch die Einführung von Technologien wie Cloud, Serverless und KI.

Dieser Wandel verändert Entwicklungspraktiken, die Sicherheit von Anwendungen und befähigt sogar Nicht-Entwickler, Anwendungen zu erstellen.

Ziehen Sie ein SRE-Modell in Betracht

Einige DevSecOps-Implementierungen kombinieren Vorgänge und Sicherheitsaufgaben in einer SRE-Rolle (Site Reliability Engineer ).

Während ein solches Modell funktionieren kann, ist es oft eine extreme Änderung von bestehender Unternehmenskultur und -praktiken.

Wenn Sie ein SRE-Modell in Betracht ziehen, empfehlen wir Ihnen, zunächst Sicherheit in DevOps einzubetten, indem Sie praktische schnelle Gewinne und inkrementelle Fortschritte verwenden, die in dieser Anleitung beschrieben sind, um sicherzustellen, dass Sie eine gute Rendite für Investitionen (ROI) erhalten und sofortige Anforderungen erfüllen.

Dadurch wird Ihren Betriebs- und Entwicklungsteams schrittweise mehr Sicherheitsverantwortung übertragen, wodurch die Teams näher an einen SRE-Zielzustand herangeführt werden.

Nächste Schritte

Erfahren Sie mehr über bewährte Methoden für sichere Entwicklung.