I would like to view this page in
DevSecOps integriert Sicherheitsmethoden in jede Phase der Softwareentwicklung und sorgt dafür, dass Sicherheitslücken frühzeitig behoben werden, ohne Ihre CI/CD-Pipeline zu verlangsamen.
DevSecOps unterstreicht die Bedeutung von integrierten Sicherheitstests und -verfahren im Entwicklungsprozess. Der sogenannte „Linksshift“ der Sicherheit trägt dazu bei, dass eine schnelle Softwareauslieferung nicht um den Preis von Sicherheitslücken erfolgt.
DevSecOps ist ein auf der DevOps-Methodik basierender Ansatz für die Softwareentwicklung. Während der Begriff „DevOps“ die Konzepte „Entwicklung“ (development) und „Betrieb“ (operations) kombiniert, steht der Begriff „DevSecOps“ für die Kombination von Entwicklung, Sicherheit und Betrieb. Der Zusatz „Sicherheit“ unterstreicht, wie wichtig es ist, Sicherheitsüberlegungen in jede Phase des Softwareentwicklungszyklus zu integrieren.
DevSecOps soll Teams in die Lage versetzen, Software schneller und effizienter auszuliefern und gleichzeitig den Code frei von Sicherheitslücken zu halten. Diese Strategie schützt sowohl Ihr Unternehmen als auch Ihre Benutzer*innen vor Cyberangriffen.
Die DevOps-Methodik wurde konzipiert, um die Auslieferung von Software zu beschleunigen und gleichzeitig die Qualität zu verbessern und Fehler zu reduzieren. DevOps hat seine Wurzeln in der Agile-Bewegung und wurde entwickelt, um bei der Softwareentwicklung und -bereitstellung die Probleme des traditionellen Wasserfallansatzes zu lösen.
Anstatt eines linearen und oft mehrjährigen Prozesses von Design, Entwicklung, Integration, Testen und Veröffentlichen ermutigt DevOps Teams, mit ihrer Arbeit diese Zyklen schnell und häufig zu durchlaufen. Um dies zu erreichen, setzt sich DevOps für robuste, automatisierte CI/CD-Prozesse ein, um die Bereitstellungszeiten zu verkürzen, schnelles Feedback zu geben und dadurch einen Kreislauf kontinuierlicher Verbesserungen zu ermöglichen.
Was unterscheidet DevSecOps von DevOps? Eigentlich ging es auch bei DevOps ging es nie darum, die Sicherheit außen vor zu lassen. Doch während die DevOps-Bewegung dazu beigetragen hat, die Grenzen zwischen Entwicklungs- und Operations-Teams zu überwinden, blieben die Informationssicherheitsteams in der Regel isoliert. Der Begriff DevSecOps sowie verschiedene andere Begriffsvarianten wie SecDevOps, DevOpsSec und Rugged DevOps wurden geprägt, um dieses Problem anzugehen.
Die Verwendung des Begriffs „DevSecOps“ erinnert Teams daran, die Sicherheit beim Prozess der Softwareentwicklung und -bereitstellung zu berücksichtigen. Dies beinhaltet:
Genauso wie „Linksshift“-Testmethoden das Auffinden und Beheben von Fehlern erleichtern und beschleunigen, lassen sich Sicherheitsverfahren leichter und effektiver integrieren, wenn sie früher im Entwicklungsprozess angegangen werden.
Die potenziellen Auswirkungen von Sicherheitslücken in Ihrer Software können gar nicht hoch genug eingeschätzt werden.
Neben finanziellen und Reputationschäden haben Software-Sicherheitsvorfälle dazu geführt, dass große Mengen an sensiblen Daten, darunter interne Dokumente und persönliche Kundendaten, in unbefugte Hände gelangt sind. Je nach Rechtsgebiet kann der Verlust von Benutzerdaten schwerwiegende finanzielle Sanktionen und sogar strafrechtliche Folgen nach sich ziehen.
Trotz alledem hat die traditionelle Herangehensweise an die Softwaresicherheit bisweilen die Folge, dass sie eher als Belastung denn als Vorteil empfunden wird. Sicherheitsprüfungen und -berichte bremsen den Arbeitsfortschritt und hindern Sie daran, Ihre neuesten Funktionen für Ihre Benutzer*innen bereitzustellen. Wenn Sie jedoch die Bedeutung der Sicherheit im Software-Entwicklungszyklus ignorieren, besteht die Gefahr, dass bald der nächste Cyberangriff in den Schlagzeilen stehen wird.
Diese Exploits schafften es weltweit in die Schlagzeilen – doch ihre Ursprünge waren weitaus banaler. Sicherheitslücken entstehen, weil Programme von Menschen geschrieben werden und Menschen Fehler machen. Manchmal wurden diese Fehler bereits von anderen gemacht und sind daher leichter zu erkennen (wenn wir wissen, wo wir suchen müssen). Manchmal sind sie jedoch auch neu – vielleicht in Folge einer Kombination von Faktoren, die bisher nicht in dieser Form aufgetreten sind.
Noch komplizierter wird es dadurch, dass fast jede Software Abhängigkeiten enthält. Unabhängig davon, ob es sich bei diesen Abhängigkeiten um Open-Source- oder proprietäre Software handelt, gibt es keine Garantie dafür, dass Fremdcode frei von Sicherheitslücken ist. Daher ist die Sicherung Ihrer Software-Lieferkette ebenso wichtig wie die Überprüfung der Sicherheit Ihres eigenen Quellcodes.
Wie kann also die Sicherheit in den Software-Entwicklungszyklus integriert werden? Der DevSecOps-Ansatz wendet die gleichen Prinzipien an, die in der Vergangenheit schnellere und stabilere Releases ermöglicht haben: Durch einen „Linksshift“ kümmert man sich früh und oft um die Sicherheit.
Auf den ersten Blick mag „Linksshift der Sicherheit“ so klingen, als ob Sie Ihrem CI/CD-Prozess lediglich eine weitere Phase hinzufügen müssten, um Ihre Software dem Sicherheitsteam für Tests und Überprüfungen bereitzustellen.
Zwar haben manuelle Sicherheitstests durchaus ihre Berechtigung (wie wir später noch sehen werden), aber wenn Sie sich erst in einem letzten Schritt Ihres CI/CD-Prozesses mit den Sicherheitsanforderungen beschäftigen, entgehen Ihnen aus mehreren Gründen die Vorteile eines schnellen, regelmäßigen Feedbacks:
Was bedeutet also in der Praxis ein Linksshift-Ansatz für die Sicherheit? Es gibt zwar keine Patentlösung, die in jeder Situation hilft, aber die folgenden Tools und Techniken können dazu beitragen, die Sicherheit in den gesamten Software-Entwicklungszyklus zu integrieren.
Eine Kultur der gemeinsamen Verantwortung ist zwar wichtig, aber es genügt nicht, Ihrem Entwicklungsteam zu sagen, dass sie ab sofort gemeinschaftlich für die Softwaresicherheit verantwortlich sind. Mit den neuesten Entwicklungen bei Angriffsmethoden und Malware Schritt zu halten ist ein Vollzeitjob, und Sie können nicht erwarten, dass jeder das gleiche Maß an Fachwissen zu diesem Thema erwirbt.
Wenn Sie hingegen einen Sicherheitschampion in ein multidisziplinäres Team holen, der die anderen Teammitglieder coacht und Best Practices weitergibt, können Sie das Verständnis für Sicherheit stärken und eine Kultur der Zusammenarbeit mit den Sicherheitsexperten fördern.
Im Idealfall sollte die Sicherheit berücksichtigt werden, bevor die erste Codezeile geschrieben wird. Sie sollten in User Stories eingebunden, in Backlog-Review-Meetings thematisiert und bei der Planung jedes Sprints angesprochen werden. Nehmen Sie sich bei der Planung eines neuen Features die Zeit, das damit verbundene Risikopotenzial zu erörtern und zu minimieren.
Eine Strategie zur Bedrohungsmodellierung wie STRIDE oder ein Tool wie das OWASP-Cheatsheet können helfen, sich beim Einarbeiten in dieses neue Gebiet nicht zu verzetteln. Durch die Berücksichtigung der Sicherheit in der Designphase werden zwar nicht gleich alle Probleme beseitigt, aber es ist ein guter Start, der zur Förderung einer DevSecOps-Kultur beiträgt.
Die Automatisierung ist ein zentrales DevOps-Prinzip. Sie stellt eine einheitliche Ausführung sicher und beschleunigt die Erledigung von Aufgaben, sodass die Mitarbeitenden mehr Zeit für kreative Tätigkeiten haben. Wenn Sie Ihre Software regelmäßig und häufig bereitstellen möchten, sollten Sie Ihrer Pipeline unbedingt automatisierte Sicherheitstests hinzufügen.
Beim Schreiben automatisierter Unit-, Integrations- und End-to-End-Tests sollten Sicherheitsmerkmale die gleiche Relevanz haben wie alle anderen Funktionen. Wenn Ihr Team Sicherheitsanforderungen bereits in User Stories integriert und Bedrohungsmodelle im Rahmen des Designprozesses besprochen hat, sind Tests zum Abdecken der Sicherheitsfunktionen eine natürliche Fortsetzung dieser Arbeit.
Zusätzlich zu selbst geschriebenen Tests können Sie verschiedene Sicherheitstest-Tools nutzen, um das Vertrauen in die Qualität Ihres Codes zu stärken. Traditionelle Sicherheitsscanner-Tools waren zwar für eine automatisierte CI/CD-Pipeline weniger geeignet, heute gibt es jedoch Sicherheitstest-Tools für CI/CD-Systeme, die auf Automatisierung ausgelegt sind. Diese lassen sich in Ihre CI/CD-Pipeline integrieren und können ihre Ergebnisse an Dashboards melden oder direkt an Bug-Tracker übermitteln. Wie bei allen automatisierten Tests sollte durch entsprechende Strukturierung für ein möglichst schnelles Feedback gesorgt werden.
Tools für statische Anwendungssicherheitstests (Static Application Security Testing, SAST) prüfen den Quellcode mittels statischer Codeanalysen auf bekannte Sicherheitslücken wie Pufferüberläufe und SQL-Injection-Gefahren. Da die statische Analyse auf den Quellcode angewendet wird, kann sie an einem sehr frühen Punkt der CI/CD-Pipeline – direkt nach einem Commit – erfolgen.
SAST-Tools sind sprachspezifisch und zum Teil in die IDE integriert, um beim Schreiben kontinuierliches Feedback zu geben oder Tests bei Bedarf auszuführen. Indem sie auf die konkrete Codezeile hinweisen, in der das Sicherheitsproblem gefunden wurde, bieten die SAST-Tools gezielte Unterstützung, die das Beheben von Problemen beschleunigt. Fehlalarme können jedoch ein Problem darstellen, und es ist wichtig, einzelne Warnungen stummschalten oder verwerfen zu können, da ansonsten die Gefahr besteht, dass alle SAST-Ergebnisse im Grundrauschen untergehen.
Dynamische Anwendungssicherheitstests (dynamic application security test, DAST) sind das Pendant zu SAST. Dabei wird die ausgeführte Anwendung als „Blackbox“ betrachtet und auf bekannte Schwachstellen überprüft – etwa Cross-Site-Scripting, Befehls- und SQL-Injection und unsichere Serverkonfigurationen. Da für die Anwendung von DAST-Tools ein Build der Anwendung erstellt und in einer Testumgebung bereitgestellt werden muss, erfolgt ihr Einsatz normalerweise erst später in der CI/CD-Pipeline.
Das Potenzial für Cyberangriffe ist enorm. Böswillige Akteure sind oft in der Lage, eine Sicherheitslücke in einer weit verbreiteten Softwareanwendung zu finden. Diese und ähnliche Angriffe haben die Bedeutung einer sicheren Software-Lieferkette in den Vordergrund gerückt.
Was verstehen wir unter „Software-Lieferkette“? Vereinfacht ausgedrückt umfasst sie alles, was mit der Entwicklung und Bereitstellung Ihrer Software zu tun hat. Bei der Softwareentwicklung bauen wir immer auf andere Software auf, von wiederverwendbaren Komponenten und Bibliotheken bis hin zu IDEs, Frameworks und Build-Tools. Die Sicherheit der Software-Lieferkette erfordert eine Sicherheitsüberprüfung der verwendeten Softwarekomponenten und die Sicherung Ihrer Entwicklungsprozesse.
Ersteres wird durch Tools für Software-Kompositionsanalyse (SCA) ermöglicht. SCA-Tools sollten nicht nur die Abhängigkeiten prüfen, die Sie unmittelbar eingefügt haben, sondern in rekursiver Weise auch deren Abhängigkeiten – ein perfektes Beispiel für eine Aufgabe, die am besten Computern überlassen wird, insbesondere wenn wir bedenken, wie oft neue Abhängigkeiten zu einem Projekt hinzugefügt werden.
Neben der automatisierten Ausführung in der CI/CD-Pipeline sind einige SCA-Tools auch als IDE-Plugins verfügbar, um kontinuierliches Feedback geben zu können. Wie bei statischen und dynamischen Sicherheitstests sind auch SCA-Tests auf Schwachstellen begrenzt, die den Tools bekannt sind. Daher sollten Sie sicherstellen, dass Ihre Tools regelmäßig mit Daten zu neuen Exploits aktualisiert werden und die Bereiche abdecken, die für Ihr Produkt und Ihre Organisation relevant sind.
Das Konzept eines „roten Teams“ geht auf Kriegssimulationen zurück, in denen Mitglieder der eigenen Seite bei einem simulierten Angriff die Rolle des Feindes übernehmen, um Schwachstellen in der eigenen Verteidigung und Strategie zu identifizieren. Der gleiche Ansatz wird auch in der Softwareentwicklung mit großer Wirkung eingesetzt, etwa bei Penetrationstests oder „ethischem“ Hacking, um neue und unerwartete Exploits zu finden.
Damit ein rotes Team effektiv eingesetzt werden kann, darf es nicht an der Entwicklung des getesteten Systems teilgenommen haben. Wie beim explorativen Testen muss das rote Team unkonventionell denken und die Software anders als beabsichtigt verwenden.
Rote Teams können entweder in einer Staging-Umgebung (die möglichst weitgehend mit der Produktionsumgebung übereinstimmen sollte) oder „live“ in einem Produktivsystem eingesetzt werden. Wenn Sie sich für Letzteres entscheiden, benötigen Sie allerdings entweder Vertrauen in die Fehlermodi Ihres Produkts – oder eine hohe Toleranz seitens der Benutzergemeinde (und der Geschäftsführung).
Bei einem DevSecOps-Ansatz teilen sich alle die Verantwortung für die Sicherheit der Software. Daher ist es an der Zeit, Sicherheitsprobleme nicht mehr separat von „regulären“ Bugs zu betrachten. Alle sicherheitsbezogenen Fehler oder Schwachstellen, die in Ihrem System aufgedeckt werden, gehören in dasselbe Backlog wie alle anderen Probleme und sollten gemeinsam mit diesen priorisiert werden.
Für die Behebung von Sicherheitslücken sollte das gesamte Team zuständig sein, nicht nur der Sicherheitschampion. Auf diese Weise kann jeder sein Wissen und seine Erfahrung in Bezug auf die Sicherheit ausbauen, um diese Fähigkeiten sowohl im aktuellen Codebestand als auch bei künftigen Projekten einzusetzen.
Trotz aller Bemühungen in den vorangegangenen Phasen des Software-Entwicklungszyklus besteht auch beim Live-System das Risiko, dass Hacker eine Schwachstelle finden. Es lohnt sich daher weiterhin, in Firewalls und Überwachungstools zu investieren, um sowohl Ihr Unternehmen als auch Ihre Benutzer*innen zu schützen. Eine neue Variante dieser Abwehrmechanismen sind RASP-Tools (Runtime Application Self Protection), die verdächtiges Verhalten automatisch erkennen und blockieren.
Hier finden Sie einige zusätzliche Schritte, mit denen Sie die Sicherheit Ihrer Pipelines erhöhen können.
Durch Release-Orchestrierung werden automatisierte Aufgaben auf mehreren Systemen koordiniert, um Software-Updates bereitzustellen.
Mit der Funktion „Pre-tested Commit“ von TeamCity können Sie Ihre Änderungen remote überprüfen, BEVOR Sie sie in die Versionsverwaltung übernehmen.