Traditionell ist der Software-Entwicklungsprozess in zwei verschiedene Phasen und zugehörige Teams unterteilt: Entwickler schreiben Code und geben diesen an das Operations-Team weiter. Die IT-Sicherheit sorgt dafür, dass bei Freigabe der Software keine Sicherheitsprobleme bestehen. In den letzten Jahren hat sich aber die Art und Weise der Software-Entwicklung grundlegend verändert. Heute muss Sicherheit in alle Phasen des Software-Development-Prozesses integriert werden.

Die Entwicklung von Anwendungen mit Open-Source-Komponenten bietet viele Vorteile. Dazu gehören die Möglichkeiten, Fachkenntnisse sowie Expertise größerer Entwickler-Teams wirksam einzusetzen, erstklassige Implementierungen einzubinden und natürlich die Kosten zu senken. Um dies auf eine sichere Art und Weise zu tun, benötigen Unternehmen jedoch Transparenz darüber, welche Open-Source-Komponenten sie verwenden, woher diese stammen und welches Sicherheitsrisiko mit ihnen verbunden ist. In die National-Vulnerability-Database wurden allein im Jahr 2017 täglich mehr als 30 neue Schwachstellen aufgenommen. Um diese Schwachstellen finden zu können, ist ein vollständiger Einblick in die verwendete Open-Source notwendig.
Meist wird Open-Source ohne Unterstützung eines Herstellers verwendet. Der Anbieter forciert aber weder Fixes noch benachrichtigt er bei Sicherheitsproblemen. Dies bedeutet, dass Unternehmen die genutzten Open-Source-Komponenten selbst auf Updates und Patches hin überwachen müssen. Allerdings gibt es oft nur wenig interne Dokumentation darüber, welche Version einer bestimmten Open-Source-Komponente von welchem bestimmten Anbieter übernommen wurde. Hinzu kommt das Problem des Software-Verfalls: Ältere, zuvor als sicher geltende Open-Source-Komponenten weisen neue Sicherheitsprobleme auf. Und schon wird die Aufgabe des Sicherheits-Teams noch ein bisschen schwieriger.
DevOps-Grundsätze
DevOps ist in erster Linie ein Konzept. Es kombiniert kulturelle Philosophien, technische Praktiken und Tools, um Entwicklungs- und IT-Betriebs-Teams bei der Zusammenarbeit zu unterstützen, mit dem Ziel, Software schneller und zuverlässiger zu erstellen, zu testen und schließlich freizugeben. DevOps wird langfristig verfolgt und schließlich Teil der Unternehmenskultur. Letztendlich besteht das Ziel von DevOps darin, Organisationen in die Lage zu versetzen, ihre Kunden effektiver zu bedienen und ihre Wettbewerbsfähigkeit zu erhöhen. Einige Unternehmen führen dazu Entwicklung und Betrieb in einem DevOps-Team zusammen, welches für den gesamten Anwendungslebenszyklus verantwortlich ist.
Die Three-Ways sind Prinzipien, von denen alle DevOps-Muster abgeleitet sind. Sie beschreiben jene Philosophien, die die Prozesse, Verfahren und Praktiken von DevOps einrahmen. Jeder dieser Three-Ways trägt zum Gesamtkonzept DevOps bei und beinhaltet festgelegte Schritte, um Teams dabei zu helfen, DevOps in ihrer Organisation zu erreichen. Sie sollen an dieser Stelle nur kurz zusammengefasst werden:
  • Flow: Systemdenken. Die Leistungsfähigkeit des Gesamtsystems ist entscheidend.
  • Feedback-Loops: Feedback-Schleifen verstärken in allen Phasen. Gemeinsame Ziele für Dev und Ops definieren.
  • Experimentation and Learning: Fortgesetztes Experimentieren und Lernen. Risiken zulassen, damit aus Erfolgen und Fehlern gelernt werden kann.

Der letzte Schritt zum Erreichen von DevOps ist die Integration von Sicherheits-, Änderungs-Management- und Compliance-Kontrollen in die täglichen Aufgaben von Entwicklungs- und Betriebs-Teams. Dadurch wird Sicherheit zu einem Teil jeder Rolle im Software-Entwicklungszyklus, anstatt diese Verantwortung auf das Sicherheits-Team zu beschränken. Der Aufbau von automatischen Sicherheitskontrollen in die DevOps-Prozesse und -Tools, die bereits von Entwicklungs- und Betriebs-Teams verwendet werden, kann viel dazu beitragen, den schnellen Feedback-Flow zu erzeugen, der für eine erfolgreiche DevOps-Implementierung erforderlich ist.

Und was ist jetzt DevSecOps?

Sichere DevOps oder DevSecOps beschreibt die Integration von Sicherheit in alle Phasen des Software-Development-Lifecycle (SDLC). Diese Praxis erfordert allerdings kulturelle und praktische Veränderungen, zum Beispiel:

  • Integration von Sicherheit in das Defect-Tracking: Sicherheitsprobleme sollten mit den gleichen Tools verfolgt werden, die bereits von den Entwicklungs- und Betriebs-Teams genutzt werden. Das gebräuchlichste Tool hierzu ist sicherlich Jira,eine speziell für agile Teams entwickelte Planungs- und Verfolgungs-Software. Nach jedem gelösten Sicherheitsproblem sollte es zudem eine Art Manöverkritik geben, die verhindert, dass der gleiche Fehler vom Team wiederholt wird.
  • Integration von Sicherheitskontrollen in gemeinsame Code-Repositories und Services: Alle Teams sollten ein Quellcode-Repository mit sicherheitszertifizierten Bibliotheken teilen. Dieses Repository kann zusätzlich zu Toolchains, der Deployment-Pipeline und Standards auch solche Pakete und Builds enthalten, die für die Entwicklung freigegeben wurden (z.B. sichere Versionen von OpenSSL mit korrekten Konfigurationen). Üblicherweise nutzen Teams Verwaltungs-Tools wie Git, Bitbucket und Mercurial sowie binäre Repositories
    wie Artefactory und Nexus.
  • Integration von Sicherheit in die Deployment-Pipeline: Sicherheitstests sollten so weit wie möglich automatisiert ablaufen, so dass sie neben anderen automatisierten Tests in der Pipeline ausgeführt werden können. Die Sicherheitstests sollten bei jedem Commit durch Entwicklung oder Betrieb, selbst in frühen Phasen, durchgeführt werden. Ziel sollten kurze Feedback-Loops sein, so dass alle Teams über mögliche Sicherheitsprobleme bei Code-Commits informiert sind. Nur so können Sicherheitsprobleme schnell erkannt und als Teil
    der täglichen Arbeit behoben werden. Wartet man damit bis zum Ende des SDLC, sind Fixes in der Regel komplex, zeitraubend und damit teuer. Am einfachsten erreicht man diesen Schritt mit Continuous-Integration-Tools wie Jenkins, Travis und TeamCity sowie Continuous-Delivery-Tools wie Jenkins, XebiaLabs und GoCD.
  • Gewährleistung der Sicherheit der Anwendung: Zur Qualitätssicherung sollten statische und dynamische Analysen (SAST, DAST), Software-Zusammensetzungsanalysen (SCA), Container-Scans und interaktive Anwendungssicherheitstests (IAST) durchgeführt werden. Viele dieser Verfahren können Teil einer CI/CD-Pipeline sein.

Anders wie DevOps und CI/CD dürfte Software-Composition-Analysis (SCA) ein Begriff sein, der denjenigen vielleicht nicht so vertraut ist, die sich direkt mit der Software-Zusammensetzung befassen – also Entwicklern und Technikern. SCA-Tools analysieren speziell Quell-Code, Module, Frameworks und Bibliotheken, um Open-Source-Komponenten zu identifizieren und zu inventarisieren sowie bekannte Sicherheitslücken oder Lizenzprobleme auszumachen, bevor die Anwendung für die Produktion freigegeben wird. Hinsichtlich der operativen Seite kann SCA schnell Probleme identifizieren, die in Implementierungsumgebungen wie Container-Images vorhanden sind; eine Situation, die außerhalb des traditionellen technischen Sicherheitsmodells liegt.

Der Weg zur DevOps-kompatiblen SCA-Lösung

Eine DevOps-kompatible SCA-Lösung lässt sich in Teams sowie in weitere Tools integrieren, um den Prozess der Identifizierung, Kommunikation von Open-Source-Schwachstellen und Lizenzrisiken als Teil des Entwicklungs- und Bereitstellungs-Workflows zu automatisieren.

Eine vollständige SCA-Lösung muss folgende Funktionen umfassen:

  • Inventar der verwendeten Open-Source-Software: Ein vollständiges und genaues Inventar des Open-Source-Codes, der in Anwendungen verwendet wird, ist von wesentlicher Bedeutung.
  • Übersicht der bekannten Open-Source-Schwachstellen: DevOps-Teams müssen auf öffentliche Quellen zurückgreifen, um festzustellen welche der von ihnen verwendeten Open-Source-Komponenten angreifbar sind.
  • Identifikation von Lizenz- und Qualitätsrisiken: Die Nichteinhaltung von Open-Source-Lizenzen kann für Unternehmen ein erhebliches Risiko an Rechtsstreitigkeiten und eine Gefährdung des geistigen Eigentums bedeuten.
  • Richtlinien für Open-Source durchsetzen: Die Automatisierung der Software-Entwicklung nimmt zu, dementsprechend sollte es auch die Verwaltung der Open-Source-Richtlinien.
  • Warnung zu neuen Sicherheitsbedrohungen: Angesichts der neuen Open-Source-Schwachstellen die jedes Jahr entdeckt werden, müssen Unternehmen kontinuierlich nach neuen Bedrohungen suchen, solange ihre Anwendungen im Einsatz sind.

Fazit

Ein Team, das mit einer solchen SCA-Lösung arbeitet, wird sich schnell von dem gängigen Gedanken verabschieden, dass Sicherheit die Entwicklungsarbeit lediglich behindert. Stattdessen wird Sicherheit schnell als ein wertvoller Teil des CI/CD-Prozesses wahrgenommen, in dem Sicherheitslücken und Lizenzprobleme in Open-Source gefunden und proaktiv behoben werden.
Wenn sowohl benutzerdefinierter als auch Open-Source-Code in der Entwicklung und der Bereitstellung kontinuierlich überprüft werden, haben Unternehmen eine sehr gute Grundlage für die Sicherung ihrer Anwendungen. Die DevOps-Teams sollten eine automatisierte Software-Composition-Analysis für Open-Source- und Drittanbieter-Bibliotheken verwenden, die in automatisierte Builds und als Teil des Code-Check-In integriert sind.


Tim Mackey ist in technischen Communities gut vernetzt, und erfährt so aus erster Hand wie Black Duck by Synopsys den Kunden am besten unterstützen kann. Er kennt die aktuellsten Applikationssicherheitsprobleme und gibt diese an die Entwicklerteams weiter. Seine Spezialgebiete sind Open-Source-Sicherheit, Rechenzentrumssicherheit, Container, Virtualisierung und Cloud-Technologien. Tim Mackey hat weltweit bereits zu verschiedenen Themen und auf bekannten Veranstaltungen wie OSCON, CloudOpen, Interop, CA World, Cloud Connect und der CloudStack Collaboration Conference gesprochen.

Carolyn Molski


Leave a Reply