DevSecOps

Dieser Partner-Blogpost wurde uns von unserem Partner Sonatype zur Verfügung gestellt.

Dev.Sec.Ops.

Haben Sie den Begriff schon einmal gehört? Wenn nicht, sind Sie nicht allein. Die Grundprämisse hinter DevSecOps kann sogar unter verschiedenen Namen laufen, je nachdem, wer das Gespräch führt (Rugged DevOps, SecDevOps, etc.) Und natürlich kann es auch schwierig genug sein, eine gemeinsam vereinbarte Definition von DevOps für sich zu finden.

Also, was bedeutet DevSecOps genau? Das Erste was Sie wahrscheinlich wissen müssen ist, dass das “Sec” in DevSecOps für Security, also Sicherheit steht.

Für viele Unternehmen bedeutet die Implementierung einer DevOps-Mentalität, die Lücke zwischen Softwareentwicklungs- und IT-Teams zu beseitigen, oft mit dem Ziel, Software schneller und stabiler veröffentlichen zu können.

DevSecOps ist also eine Erweiterung des DevOps-Mindsets und wird oft mit dem Slogan “Verschiebung der Sicherheit nach links” (d.h. früher) im Software Development Lifecycle (SDLC) dargestellt, anstatt Sicherheitsüberprüfungen/Inspektionen am Ende des Zyklus anzugehen, wenn alle Erkenntnisse, die eine Minderung erfordern, schwieriger und kostspieliger umzusetzen sind.

Tatsächlich ist das Prinzip von DevSecOps - die Qualität immer näher an die Quelle zu bringen - ein wichtiger Grundsatz von The Second Way of DevOps (Feedback), wie im DevOps Handbuch beschrieben:

“In complex systems, adding more inspection steps and approval processes actually increases the likelihood of future failures. The effectiveness of approval processes decreases as we push decision-making further away from where the work is performed. Doing so not only lowers the quality of decisions but also increases our cycle time, thus decreasing the strength of the feedback between cause and effect, and reducing our ability to learn from successes and failures.”

W. Edwards Deming, ein Ingenieur, Statistikprofessor und Unternehmensberater, dem oft die Lehren zugeschrieben werden, die zur Gründung des Total Quality Movement in den Vereinigten Staaten beigetragen haben, brachte die gleiche Idee (viel früher) in der dritten (von seinen 14) Schlüsselmanagement-Prinzipien zur Transformation der Unternehmenseffektivität hervor:

“Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.”

Prinzipien sind nicht notwendigerweise mit Praxis gleichzusetzen.

Diese Prinzipien sind nicht neu und sie scheinen in der Theorie ziemlich einfach zu sein, aber die Realität ist, dass in der Praxis viele Unternehmen nicht so arbeiten.

Wenn die Sicherheit von einem Unternehmen priorisiert wird, zielt sie oft darauf ab, die Mindestkriterien für eine Art von Compliance zu erreichen, in der Regel mit einem unterbesetzten Sicherheitsteam.

In seinem DZone Artikel 10 Tips for Integrating Security into DevOps beschreibt Gene Kim diese Herausforderung:

“The ratio of engineers in Development, Operations, and Infosec in a typical technology organization is 100:10:1. When Infosec is that outnumbered, without automation and integrating information security into the daily work of Dev and Ops, Infosec can only do compliance checking, which is the opposite of security engineering—and besides, it also makes everyone hate us.”

Ein anschauliches Beispiel für dieses Szenario ist The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win  in dem der weniger beliebte Chief Information Security Officer (CISO) John eine existenzielle Krise durchlebt, wenn sein Unternehmen ein SOX-404-Audit besteht, ohne sich jemals auf seine prozessintensiven Sicherheitskontrollen verlassen zu müssen.

Nach einer Zeit des Selbstmitleids und der Selbstanalyse, in der all seine harte Arbeit nicht wirklich einen Mehrwert für das Unternehmen brachte, steigt CISO John “aus der Asche” und beginnt zu verstehen, wie seine Rolle dem Unternehmen helfen kann seine Geschäftsziele zu erreichen und arbeitet kooperativer mit den Abteilungen für Softwareentwicklung und IT zusammen, um zu verstehen wie er dazu beitragen kann, ihre Arbeit zu erleichtern. Bald beginnt die Dev, Ops und Security Triade zusammenzuarbeiten, um diese gemeinsamen Geschäftsziele zu erreichen und werden dabei viel agiler, indem sie Automatisierungs-Prozesse hinzufügen, um den Aufwand und die Sicherheitsrisiken möglichst zu reduzieren.

Ein kultureller Wandel in beide Richtungen

In einem Interview mit der Computer Business Review teilte Sonatype’s CTO, Brian Fox, seine Gedanken über die Veränderungen im DevOps- und DevSecOps-Bereich mit:

“What we see in the market is that our customer’s greatest challenge today is often the cultural change required to get all of the process owners to think outside the legacy process box they find themselves in.”

Einer der Gründer von DevSecOps, Shannon Lietz von Intuit, schreibt über diesen Wandel in ihrem Blogpost  What is DevSecOps? auf devsecops.org und erklärt: “…with the change of DevOps afoot, traditional security is no longer an option.” Laut Lietz:

“The purpose and intent of DevSecOps is to build on the mindset that ‘everyone is responsible for security’ with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.”

Wenn man DevSecOps als eine kollaborative Disziplin betrachtet wird klar, dass das ganze Unternehmen an diesem Prozess beteiligt werden muss.

Die Autoren des DevOps Handbook stimmen zu:

“By doing this, we truly make quality everyone’s responsibility as opposed to it being the sole responsibility of a separate department. Information security is not just Information Security’s job, just as availability isn’t merely the job of operations.”

Bei Sonatype beinhaltet der Ansatz für DevSecOps “building quality in”, indem Sicherheitsmaßnahmen in alle Phasen der DevOps-Pipeline integriert werden - eine Verschiebung nach links und rechts - von der ersten Open-Source-Komponentenauswahl bis hin zur Erstellung, Bereitstellung und Freigabe einer Anwendung.

Um Sicherheit in alle Phasen einer SDLC zu integrieren, müssen folgende Punkte beachtet werden:

  • Scannen und Bewerten der Risiken von Open-Source-Komponenten in neuen und bestehenden Legacy-Anwendungen.
  • Verhindern, dass “schlechte” OSS-Komponenten überhaupt in ein Ökosystem gelangen.
  • Kontinuierliche Überwachung aller Anwendungen in der Produktion, automatische Benachrichtigung der Entwicklerteams bei auftretenden Schwachstellen, die eine Anwendungen betreffen.

Im folgenden ein Auszug aus dem DevSecOps-Manifest von devsecops.org, das im Mittelpunkt der Mission bei Sonatype steht:

“By developing security as code, we will strive to create awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment. We will operate like developers to make security and compliance available to be consumed as services. We will unlock and unblock new paths to help others see their ideas become a reality.”

Für mehr Informationen:

👉🏻
Zum Original Blogpost
Wer wissen will, was wir sonst noch so machen:
Scandiolife auf Instagram.
Connecte dich auf LinkedIn mit uns.
Hier zwitschert die Scandio auf Twitter.