SecDevOps vs DevSecOps: Transformieren

SecDevOps gegen DevSecOps. Es mag nach Semantik klingen, aber die Reihenfolge der Wörter hat das ganze Gewicht. Wie verändern wir kulturell die Art und Weise, wie wir mit Sicherheit umgehen? Wir beginnen damit, es mit der Schwerkraft zu behandeln, die es verdient, und bauen es gleich zu Beginn 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 funktioniert DevSecOps. Das Ergebnis der Integration von Sicherheit in DevOps wurde als SecDevOps und DevSecOps geprägt.

Obwohl es austauschbar verwendet wird, vergleicht SecDevOps mit DevSecOps tatsächlich zwei radikal unterschiedliche Dinge. Warum? Weil die Reihenfolge der Wörter wichtig ist. In den meisten Fällen wird die Sicherheit am Ende des Bereitstellungsprozesses immer noch "angegangen".

In diesem Beitrag werde ich erläutern, warum die Unterscheidung zwischen DevSecOps und SecDevOps für die Sicherheit Ihrer Anwendungen von entscheidender Bedeutung ist. Ich werde auch darauf eingehen, wie die Bereitstellung sicherer Software einfacher zu erreichen ist, wenn Sicherheit ein wesentlicher 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 knapp ist und auf wenige Personen in einer Organisation beschränkt ist, werden diese Personen häufig zu einem zentralen Sicherheitsteam zusammengefasst. Das Sicherheitsteam hat die Aufgabe, das Produkt mithilfe seiner „Zauberkiste mit Tricks“ zu testen, um vor der Bereitstellung Schwachstellen im Release Candidate zu finden. Wenn das Team unvermeidlich eine Sicherheitslücke findet, gibt es die „schlechten Nachrichten“ an das Entwicklungsteam zurück. Da das Entwicklungsteam jedoch nicht über die Sicherheitsschulung oder das Wissen über die Verwendung der vom Sicherheitsteam verwendeten Tools verfügt Das Sicherheitsteam wird oft als "böse Jungs" angesehen, weil sie die Veröffentlichung jetzt wegen "einiger Sicherheitslücken" aufhalten. Wie ist die typische Reaktion des Teams?

Der traditionelle Ansatz führt zu verzögerten Freigaben und / oder Sicherheitslücken in der Produktion

Seien wir ehrlich, es ist schwierig, wichtige Sicherheitsupdates, Kontrollen und Codierungsstandards in ein Projekt zu integrieren, das für das Entwicklungsteam „erledigt und entstaubt“ ist. Was passiert also? Das Produkt geht mit bekannten und unbekannten Sicherheitslücken aus der Tür und verspricht möglicherweise, sie in der nächsten Version zu beheben oder zu ändern. Dies erhalten Sie, wenn Sie die Sicherheit nach der Entwicklung festlegen - "Dev", dann "Sec" und dann "Ops". Während dies nicht die Absicht ist, ist dies in vielen Organisationen die Realität. Betrachten Sie einen besseren Ansatz, der unten beschrieben wird.

Wie Sicherheit mit SecDevOps aussieht

Sicherheitskontrollen, Richtlinien, Codierungsstandards und Best Practices müssen vollständig in den Softwareentwicklungsprozess integriert werden. Dies geschieht, indem die Sicherheit von Anfang an einbezogen wird - "Sec", dann "Dev", dann "Ops". Das Sicherheitsteam (oder möglicherweise eine auf Sicherheit spezialisierte Architektur oder ein leitender Entwickler) definiert die erforderlichen Richtlinien im Voraus für das Team.

Diese Richtlinien können aus sicheren Codierungsstandards, Regeln zur Vermeidung unsicherer APIs und schlechter Verschlüsselung, Anweisungen zur Verwendung statischer und dynamischer Analysen sowie Testrichtlinien bestehen. Ziel ist es, dass die Entwickler im Rahmen ihrer täglichen Routine auf sicherere Software hinarbeiten. Die Automatisierung trägt dazu bei, dass dies Realität wird.

Mit der Automatisierung können Sie Ihren Sicherheitsansatz für eine Strategie von aSecDevOps, die ungefähr so ​​aussieht, nach links verschieben:

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 des späten Zyklus und sieht folgendermaßen 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 setzen Sie das um?

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.

Sicherheit zu einem Teil der Qualität machen mit einem sicherheitsorientierten Workflow

Der Workflow beginnt mit der Richtlinie für sichere Codierung. Der Architekt oder Lead 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 zur Quellcodeverwaltung verpflichtet. Dabei werden Sicherheitsverletzungen abgefangen und behoben, wo und wann dies billiger und einfacher ist.

Dieselbe Konfiguration wird dann durch eine Analyse genutzt, die im Rahmen des Erstellungsprozesses ausgeführt wird. Diese umfassende Analyse geht über den Umfang des lokal geänderten Codes des Entwicklers hinaus und bietet ein Sicherheitsnetz, um die Bereitstellungspipeline zu steuern und sicherzustellen, dass unsicherer Code nicht in spätere Phasen befördert wird.

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

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

Manager und Sicherheitsverantwortliche können jetzt Projekte, die auf Sicherheitsstandards wie CWE basieren, im zentralen Dashboard wie folgt bewerten:

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

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

DevSecOps vs. SecDevOpsZusammenfassung

Trotz der austauschbaren Verwendung von DevSecOps und SecDevOps ist die Reihenfolge der Wörter genauso wichtig wie die Auswirkungen der Werkzeuge, Techniken und Prozesse, die das Wort impliziert. Sicherheit wird häufig als Add-On oder Gating-Prozess vor der Freigabe eines Produkts belassen. Es ist jedoch schwierig, Sicherheitsprobleme zu beheben, wenn sich ein Produkt auf halbem Weg befindet. Die Verlagerung der Sicherheit nach links wie in SecDevOps ist der Schlüssel zum Erfolg. Sicherheit muss Teil des täglichen Workflows jedes Entwicklers sein und in die Software-Pipeline integriert sein. Die automatisierten Sicherheitskontrollen und -richtlinien von Parasoft integrieren Sicherheit in die Pipeline und reduzieren gleichzeitig die Auswirkungen und das Risiko von SecDevOps oder DevSecOps.

Von Markus Lambert

Mark, Vice President of Products bei Parasoft, ist dafür verantwortlich, dass Parasoft-Lösungen den Unternehmen, die sie einsetzen, einen echten Mehrwert bieten. Mark ist seit 2004 bei Parasoft und arbeitet mit einem breiten Querschnitt von Global 2000-Kunden zusammen, von spezifischen Technologieimplementierungen bis hin zu umfassenderen Initiativen zur Verbesserung von SDLC-Prozessen.