Anwendungssicherheit: Entwickler ins Boot holen, aber nicht überfordern

Stellen Sie sich einen Autobauer vor, der einen Sportwagen auf den Markt bringen will. Aufgrund eines Konstruktionsfehlers funktionieren bei dem neuen Fahrzeug die Bremsen nicht richtig. Im besten Fall beseitigt der Hersteller diesen Defekt bereits in der Entwicklungsphase. Die Behebung kostet somit zwar Zeit und Geld, aber der Schaden hält sich in Grenzen.

Was jedoch, wenn der Fehler erst zu einem Zeitpunkt auffällt, an dem bereits einige tausend Autos produziert oder gar ausgeliefert sind? Dann explodieren die Kosten. Ähnlich verhält es sich in der Anwendungssicherheit. Je früher im Software-Development-Lifecycle (SDLC) Sicherheitslücken gefunden und geschlossen werden, desto geringer der finanzielle Aufwand.

Nicht am falschen Ende sparen

Die Anwendungsentwicklung und Unternehmens-IT haben in den vergangenen Jahren einen kulturellen Wandel erfahren – wesentlich ausgelöst durch DevOps. Softwareentwicklung und Systemadministration sind zusammengewachsen, Reibungen bleiben jedoch nicht aus.

In der Regel entstehen sie dadurch, dass die einzelnen Teams abweichenden Qualitätsmaßstäben unterliegen: Entwickler werden daran gemessen, wie schnell sie neue Features und Funktionalitäten umsetzen können. Security-Verantwortliche müssen Sicherheitslücken zuverlässig erkennen und schließen. Das Betriebsteam schließlich sorgt für Uptime und Stabilität.

Alle Beteiligten sehen sich zudem dem Druck ausgesetzt, Deadlines einzuhalten und Abweichungen von der Roadmap zu vermeiden. Entwickler stellt das vor die Herausforderung, ihren Code in möglichst kurzer Zeit zu produzieren. Noch schwieriger ist es für Security-Verantwortliche, die mitunter unter dem Generalverdacht stehen, Projekte mit ihren ständigen Einwänden unnötig zu verzögern.

Wenn Deadlines aber wichtiger werden als die Einhaltung grundlegender Sicherheitsstandards, entstehen für das Unternehmen große Risiken – und zusätzliche Kosten, da Schwachstellen nachträglich beseitigt werden müssen. Eine kürzlich veröffentlichte Studie von Veracode (PDF) hat gezeigt, dass 63 Prozent aller intern entwickelten Anwendungen zum Zeitpunkt ihrer ersten formalen Überprüfung nicht den Standards des Open Web Application Security Projects (OWASP) entsprechen.

Wie passt Anwendungssicherheit in den SDLC?

Je früher Schwachstellen im Code entdeckt werden, desto besser. Diese Tatsache wurde zu Beginn bereits angesprochen. Es ist aus diesem Grund sinnvoll, Anwendungen nicht erst am Ende des Entwicklungszyklus auf Fehler und Schwachstellen hin zu überprüfen. Im Umkehrschluss sollten Unternehmen aber auch nicht den Fehler begehen, ihre Verantwortung für Anwendungssicherheit vollständig auf die Entwickler abzuladen.

Der diesjährige “State-of-DevOps”-Report von Puppet kommt zu dem Ergebnis, dass der Zeitaufwand für die Behebung von Sicherheitslücken um 50 Prozent reduziert werden kann, wenn Aspekte der Anwendungssicherheit im gesamten SDLC berücksichtigt werden – und nicht erst an dessen Ende. Eine automatisierte Integration in den SDLC und in die Continuous-Integration- (CI) oder Continuous-Deployment-Pipeline (CD) ist deshalb der optimale Mittelweg.

Über die Integration in die Pipeline lässt sich sicherstellen, dass Sicherheitstests im Rahmen neuer Releases routinemäßig durchgeführt werden. Entwickler stehen somit nicht mehr alleine in der Verantwortung, außerdem führt die Einführung automatisierter Prozesse zu einer Effizienzsteigerung. Diese Form der Integration ist jedoch nur die halbe Miete. Die unmittelbarste Methode, um Fehler in der Software zu finden, ist nach wie vor die Analyse des Programmcodes. Diese muss in möglichst kurzem Abstand nach Entstehen des Codes erfolgen.

Entwickler sollten also in die Anwendungssicherheit eingebunden, aber nicht überfordert werden. Vor allem benötigen sie die richtigen Features, um ihre Aufgabe zu erfüllen. Diese können direkt in die Entwicklungsumgebung integriert werden. Eine Developer Sandbox etwa ermöglicht es ihnen, komplette Anwendungen oder einzelne Komponenten bereits im Stadium ihrer Entstehung zu überprüfen und zu verbessern. Die Wahrscheinlichkeit, dass kritische Sicherheitslücken erst am Ende des Entwicklungsprozesses entdeckt werden, sinkt somit – und Unternehmen sparen bares Geld.