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.
- 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.
