Wie können wir unseren Ansatz zur Softwaresicherheit ändern und Schwachstellen begrenzen? Sicherheit von Beginn unserer Projekte an zu einem integralen Bestandteil unserer Softwareentwicklung zu machen, ist ein guter Anfang. Erfahren Sie, wie SecDevOps und DevSecOps bei der Unterstützung der Softwaresicherheit zusammenwirken.

Was ist SecDevOps?

SecDevOps vs. DevSecOps. Es mag nach Semantik klingen, aber die Reihenfolge der Wörter hat das ganze Gewicht. Wie können wir die Art und Weise, wie wir mit Sicherheit umgehen, kulturell verändern? Wir behandeln es zunächst mit der Ernsthaftigkeit, die es verdient, und bauen es von Anfang an ein.

Es besteht kein Zweifel, dass DevOps und Sicherheit für Software- und Business-IT-Organisationen oberste Priorität haben. Das Ergebnis der Integration von Sicherheit in DevOps war die Einführung der Begriffe SecDevOps und DevSecOps. Das Ergebnis der Integration von Sicherheit in DevOps wurde als SecDevOps und DevSecOps geprägt.

Obwohl die Begriffe SecDevOps und DevSecOps synonym verwendet werden, handelt es sich um einen Vergleich zweier grundlegend unterschiedlicher Dinge. Warum? Weil die Reihenfolge der Wörter wichtig ist. In den meisten Fällen wird die Sicherheit erst am Ende des Bereitstellungsprozesses „angehängt“.

In diesem Beitrag werde ich diskutieren, warum der Unterschied zwischen DevSecOps vs. SecDevOps ist entscheidend für die Sicherheit Ihrer Anwendungen. Ich werde auch darauf eingehen, wie die Bereitstellung sicherer Software einfacher zu erreichen ist, wenn Sicherheit ein integraler Bestandteil der Entwicklung ist, und zwar vom Beginn des Softwareentwicklungsprozesses an und nicht als Tor am Ende der Bereitstellungspipeline.

Wie Sicherheit in DevSecOps aussieht

Trotz des verstärkten Fokus auf Sicherheit ist es für Softwareteams eine Herausforderung, Sicherheit in einen Prozess und eine Pipeline einzubauen. Der Druck, Projekte pünktlich und innerhalb des Budgets abzuschließen, setzt häufig andere Überlegungen außer Kraft. Infolgedessen wird die Sicherheitsintegration in der Regel als letzter Gating-Schritt für einen Release-Kandidaten angesehen, wie unten dargestellt:

Da Sicherheitswissen in der Regel rar und auf wenige Personen in einer Organisation beschränkt ist, werden diese oft in einem zentralen Sicherheitsteam zusammengefasst. Das Sicherheitsteam hat die Aufgabe, das Produkt mit seiner „Trickkiste“ zu testen, um Schwachstellen im Release Candidate vor der Veröffentlichung zu finden. Findet das Team zwangsläufig eine Schwachstelle, gibt es die „schlechte Nachricht“ an das Entwicklungsteam weiter. Da das Entwicklungsteam jedoch weder über die Sicherheitsschulung noch über das Wissen im Umgang mit den Tools des Sicherheitsteams verfügt, wird das Sicherheitsteam oft als „böse Jungs“ angesehen, weil es die Veröffentlichung aufgrund einiger Sicherheitslücken verzögert. Wie reagiert das Team also typischerweise?

Der traditionelle Ansatz führt zu verzögerter Veröffentlichung und/oder Sicherheitslücken in der Produktion.

Seien wir ehrlich: Es ist schwierig, wichtige Sicherheitsfixes, Kontrollen und Codestandards in ein Projekt zu integrieren, das für das Entwicklungsteam bereits abgeschlossen ist. Was passiert also? Das Produkt wird mit bekannten und unbekannten Sicherheitslücken ausgeliefert, möglicherweise mit dem Versprechen, diese in der nächsten Version zu beheben oder zu ändern. Das passiert, wenn Sicherheit erst nach der Entwicklung ansteht – erst „Entwicklung“, dann „Sicherheit“, dann „Betrieb“. Das ist zwar nicht beabsichtigt, aber in vielen Unternehmen Realität. Betrachten wir einen besseren Ansatz, der unten beschrieben wird.

Wie Sicherheit mit SecDevOps aussieht

Sicherheitskontrollen, Richtlinien, Programmierstandards und Best Practices müssen vollständig in den Softwareentwicklungsprozess integriert werden. Dies geschieht, indem die Sicherheit von Anfang an berücksichtigt wird: „Sicherheit“, dann „Entwicklung“, dann „Betrieb“. Das Sicherheitsteam (oder ggf. ein auf Sicherheit spezialisierter Architekt oder Senior-Entwickler) definiert die notwendigen Richtlinien im Vorfeld für das Team.

Diese Richtlinien können aus sicheren Codierungsstandards, Regeln zur Vermeidung unsicherer APIs und schlechter Verschlüsselung sowie Anweisungen zur Verwendung bestehen statische und dynamische Analyseund Prüfrichtlinien. Das Ziel besteht darin, dass die Entwickler im Alltag an sichererer Software arbeiten, und die Automatisierung trägt dazu bei, dass dies Wirklichkeit wird.

Mit der Automatisierung können Sie Ihren Sicherheitsansatz für eine SecDevOps-Strategie nach links verschieben, die etwa so aussieht:

Da die Sicherheit jetzt zu Beginn der Entwicklung festgelegt ist, wird das Team natürlich die Sicherheit besser beherrschen und am Ende der Pipeline werden weniger Sicherheitslücken gefunden.

Die Schwachstellen, die es schaffen, können dann untersucht und die Ergebnisse der Ursachenanalyse verwendet werden, um die Sicherheitsrichtlinien und -richtlinien zu verbessern - und das Ergebnis im Verlauf jedes Zyklus wesentlich zu verbessern.

Das Vorantreiben iterativer Verbesserungen der Richtlinie führt zu weniger störenden Eskalationen am Ende des Zyklus und sieht wie folgt aus:

Wenn Sie SecDevOps mit DevSecOps vergleichen, funktioniert der inkrementelle und integrierte Ansatz des ersteren viel besser als der Versuch, am Ende des Projekts ein Sicherheitsaudit durchzuführen.

Wie transformiert man DevSecOps in SecDevOps?

Es führt kein Weg an der Tatsache vorbei, dass die Sicherheit eine zusätzliche Anforderung für Entwickler darstellt, aber wie Sie die Auswirkungen dieser Arbeit verwalten, macht den Unterschied zwischen einem pünktlich, sicher Produkt und a spät, unsicher einer. Eine wichtige Anforderung ist die Integration der Sicherheit in den vorhandenen Entwicklungsprozess. Dies können Sie tun, indem Sie die CWE-kompatiblen Testtools von Parasoft integrieren, um die Sicherheit zu einem Teil der Qualität und des gesamten Arbeitsablaufs zu machen.

Machen Sie Sicherheit zu einem Teil der Qualität mit einem sicherheitsorientierten Workflow

Der Workflow beginnt mit der sicheren Codierungsrichtlinie. Der Architekt oder Leiter erstellt eine Konfiguration (möglicherweise basierend auf Codierungsrichtlinien wie CERT, CWE, OWASP, UL-2900 oder PCI DSS), die der Rest des Teams direkt in seiner IDE nutzen kann. Dies gibt dem Entwickler die Möglichkeit, den Code lokal auf seinem Computer zu überprüfen, bevor er sich der Quellcodeverwaltung zuwendet – und so Sicherheitsverstöße zu erkennen und zu beheben, wo und wann dies kostengünstiger und einfacher ist.

Dieselbe Konfiguration wird dann durch eine Analyse genutzt, die im Rahmen des Build-Prozesses durchgeführt wird. Diese umfassende Analyse geht über den Rahmen des lokal geänderten Codes des Entwicklers hinaus und bietet ein Sicherheitsnetz zum Sperren der Lieferpipeline, um sicherzustellen, dass unsicherer Code nicht in spätere Phasen befördert wird.

Abschließend werden die Ergebnisse der Analyse über das zentrale Berichts- und Analyse-Dashboard an die IDE des Entwicklers zurückgesendet, wo Fortschritte verfolgt, Kurskorrekturen vorgenommen und Prüfberichte in Echtzeit erstellt werden können.

Der vollständige SecDevOps-Workflow sieht folgendermaßen aus:

Manager und Sicherheitsleiter können Projekte jetzt anhand von Sicherheitsstandards bewerten, z CWE, im zentralen Dashboard wie unten gezeigt:

Diese Dashboards ermöglichen eine umfassende Überwachung und können Trendinformationen anzeigen, um Fragen wie „Verbessert oder verschlechtert sich das Projekt?“ oder „Welche Bereiche des Codes verursachen die meisten Probleme?“ zu beantworten.

Die Fähigkeit, diese und andere Fragen zu beantworten und Maßnahmen zu ergreifen, verwandelt das Entwicklungsteam von DevSecOps zu SecDevOps.

DevSecOps vs. SecDevOps: Priorisierung der Sicherheit in der Entwicklung

Trotz der austauschbaren Verwendung von DevSecOps und SecDevOps ist die Reihenfolge der Wörter genauso wichtig wie die Auswirkungen der Tools, Techniken und Prozesse, die das Wort impliziert. Sicherheit bleibt oft ein Add-on oder ein Gating-Prozess vor der Veröffentlichung eines Produkts, aber es ist schwierig, Sicherheitsprobleme zu beheben, wenn ein Produkt schon zur Hälfte fertig ist.

Die Verlagerung der Sicherheit nach links, wie bei SecDevOps, ist der Schlüssel zum Erfolg. Sicherheit muss Teil des täglichen Arbeitsablaufs jedes Entwicklers sein und in die Software-Pipeline integriert sein. Die automatisierten Sicherheitskontrollen und -richtlinien von Parasoft sorgen für Sicherheit in der Pipeline und reduzieren gleichzeitig die Auswirkungen und Risiken von SecDevOps oder DevSecOps.