Shift Left - Secure by Design und agile Entwicklung
Der sogenannte Shift Left ist eine zunehmend populäre Forderung für die Entwicklung sicherer Software. Gemeint ist die möglichst frühe Beachtung und Überprüfung von Sicherheitsaspekten innerhalb des Software Development Life Cycle.
- Kim Hartmann
Die Frage nach der Vereinbarkeit sicherer und agiler Entwicklungsmethoden ist nicht nur für sicherheitskritische Software relevant, sondern sie gewinnt mit der voranschreitenden Digitalisierung und Vernetzung insgesamt an Bedeutung. Ehemals als nicht sicherheitskritisch eingestufte Software wird im Kontext zeitgemäßer Anwendungsszenarien sicherheitsrelevant.
Ein einfaches Beispiel hierfür sind Infotainment-Systeme in Fahrzeugen: Sie galten lange Zeit als nicht sicherheitskritisch, obwohl sie eine Schnittstelle zum eingebetteten System und der Fahrzeugtechnik bieten. Die Annahme basierte darauf, dass die Vernetzung mit externen Geräten, die wiederum an öffentliche Netzwerke angeschlossen sein können, nicht gegeben war. In ihrem Forschungsbericht "Under The Hood: Cybercriminals Exploit Automotive Industry's Software Features" wagt die Cybersicherheitsfirma IntSight die Prognose, dass in der Zukunft vermehrt mit Angriffen gegen Softwarekomponenten wie dem Infotainmentsystem, mobilen Applikationen oder Ladestationen zu rechnen sei.
Die Bewertung der Sicherheit von Softwarekomponenten erfolgt nicht mehr nur unter dem Aspekt, ob sie und die von ihnen verarbeiteten Daten geschützt sind. Zunehmend wichtig ist, inwiefern sie ein Sicherheitsrisiko für den Anwender, dessen System oder weitere verknüpfte Komponenten darstellen. Dabei geraten neben den vielzitierten Milliardenschäden, verursacht durch fehlerhafte Software, zusätzlich Sach- und PR-Schäden durch unsichere Software in den Fokus der Entscheidungsträger. Die Einführung der Datenschutzgrundverordnung (DSGVO) im vergangenen Jahr hat das Thema weiter angeheizt, zumal Unternehmen nun verpflichtet sind nachzuweisen, dass sie Datenschutz und Datensicherheit proaktiv angehen. Das ist insbesondere für Firmen, die Software zur Datenverarbeitung entwickeln, aber ebenso für Service-Provider eine Herausforderung und eine Chance zur Abgrenzung gegenüber Konkurrenzprodukten.
Diverse Tools und Prozesse sollen den Shift Left auch in der agilen Entwicklung unterstützen und versprechen eine vereinfachte Entwicklung und erhöhte Sicherheit. Unter anderem lassen sich CI-/CD-Pipelines zur Verbesserung der Softwarequalität umsetzen – eine denkbare Pipeline ist Git, Bamboo/Jenkins, Ant/Maven/Gradle, SonarQube und Docker. Dennoch besteht weiterhin eine Divergenz zwischen Realität und Ideal der sicheren Softwareentwicklung. Wodurch entsteht diese Divergenz und wie müssten agile Prozesse gestaltet werden, um eine inhärente Sicherheit des Codes zu erlauben?
Nicht im Fokus
Stolze 15 bis 50 Fehler je 1000 Lines of Code ("Defects/KLOC") gab Steve McConnell 2004 in seinem Buch "Code Complete" [1] als "Industry Average" für ausgelieferte Software an. Neuere Untersuchungen zeigen zwar ein deutlich positiveres Bild, sprechen jedoch noch immer von einem Fehler je 1000 LOC im ausgelieferten Produkt. Obwohl Defects/KLOC als Metrik mit Schwächen gilt, verdeutlicht sie eine simple Erkenntnis: Menschen machen Fehler. In der Softwareentwicklung dienen Fehler, die nicht entdeckt und behoben werden, jedoch als Einstiegshilfen für Angreifer.
Trotz der Verbesserung der Defects/KLOC stellen vor allem Sicherheitsexperten und Senior Developer immer wieder gleichermaßen fest, dass Entwickler sogar einfache Coding Guidelines nicht einhalten. Die OWASP Top 10 ergaben sich aus den kritischsten – im Sinne von "fatal" und "häufig auftretend" – Fehlern der Webentwicklung, die zu Sicherheitsproblemen führen. Sie haben zwei Jahre nach ihrer letzten Aktualisierung wenig an Brisanz verloren.
Die mangelhafte Umsetzung von Secure Coding Guidelines und fehlende Achtsamkeit gegenüber Sicherheitsaspekten der entwickelten Module ist jedoch nicht einfach auf fehlendes Pflichtbewusstsein und Desinteresse der Entwickler oder gar auf den agilen Workflow als solches zurückzuführen. Es bedarf vielmehr einer gezielten Integration sicherheitsfördernder Maßnahmen und Prozesse in den Entwickleralltag.
Produktverantwortliche setzen häufig voraus, dass sicherer Code ein direktes, kostenloses Nebenprodukt von funktionalem Code sei. Folglich sehen sie keine oder zu wenig zusätzliche Zeit zur Absicherung des geschriebenen Codes beziehungsweise zur Gesamteinschätzung des Softwareprodukts vor. Letzteres erfolgt häufig – wenn überhaupt – durch Security-Überprüfungen im Rahmen des nachgelagerten Testings. Dabei sollen sich die gewünschten Sicherheitsanforderungen oft aus impliziten oder technisch unkonkreten Produktanforderungen ergeben ("Die Komponente soll gegenüber allen gängigen Sicherheitsschwachstellen abgesichert sein").
Die Einbindung von Entwicklern in die Umsetzung sicherer Software soll weder das Security-Testing noch die Spezifikation von Sicherheitsanforderungen ablösen, sondern stellt eine sinnvolle Ergänzung dar. "Security Sandwich" ist eine passende Bezeichnung für das Umgeben des eigentlichen Entwicklungsprozesses durch vor- und nachgelagerte Sicherheitsmaßnahmen. Es steht für eine weitgehende Entkoppelung der Entwicklungsarbeit von Sicherheitsüberlegungen: Entwickler verkommen zu "Code-Monkeys", die lediglich die gewünschte Funktionsweise umsetzen sollen, mit dem Ziel die Funktionalität rasch bereitzustellen. Globale oder tiefgreifende Sicherheitsüberlegungen verschwinden hierbei oft vollständig aus dem Prozess. Es gilt jedoch, das Entwickeln von Sicherheit als Bestandteil der Entwicklungsarbeit zu verstehen.
Softwaresicherheit ist weder allein durch extern vorgegebene Checklisten noch als beiläufiges Nebenprodukt erzielbar. Der Ausschluss des Code- und Domänen-spezifischen Fachwissens der Entwickler vom Prozess des Security Engineering ist fatal. Echte Schwachstellen, die jenseits der "Low-Hanging Fruits" anzusiedeln sind, lassen sich mit den Methoden nicht verhindern.
