Shifting Left reicht nicht aus: Warum der Start ganz links der Schlüssel zu exzellenter Softwaresicherheit ist

In einer digital geprägten Welt ist das Risiko von Datendiebstahl so hoch wie nie zuvor. Da große Organisationen als Hüter unserer wertvollen Informationen fungieren, erkennen viele die Notwendigkeit, strenge Sicherheitsstandards zu implementieren.

Ein Großteil der Initiativen rund um „Shifting Left“, also die Verlagerung der Sicherheit an den Anfang des Entwicklungsprozesses, greift schlichtweg zu kurz. Dies impliziert, dass wir den Prozess ohnehin falsch beginnen und letztlich nur zurückrudern, um sicherere Software zu erhalten. Wir müssen „Start Left“ praktizieren – einen kulturellen Wandel einleiten, der Entwicklungsteams aktiv einbindet und ihnen das Wissen vermittelt, das ihnen derzeit fehlt. Doch Training ist nicht gleich Training und Tools sind nicht gleich Tools.

In diesem Artikel untersuchen wir, wie Führungskräfte, wie etwa Manager für Security Awareness und Entwicklung, ihre Entwicklerteams wirklich stärken und sie zur ersten Verteidigungslinie gegen kostspielige Cyberangriffe machen können.

Shift Left vs. Start Left: Ein wichtiger Unterschied.

Im Zeitalter häufiger Datenpannen, von denen einige der weltweit vertrauenswürdigsten Organisationen betroffen sind, haben sich Unternehmensführer an die Sicherheitsbranche gewandt, um Anleitungen zur Vermeidung der finanziellen, rufschädigenden und existenzbedrohenden Katastrophen zu erhalten, die ein erfolgreicher Angriff mit sich bringt.

Lange Zeit haben AppSec-Spezialisten (mich eingeschlossen) dazu geraten, dass wir „Shift Left“ praktizieren müssen. Im Einklang mit DevOps-Best-Practices und im Sinne einer besseren Softwaresicherheit rieten viele von uns dazu, den Sicherheitsaspekt früher in den Softwareentwicklungslebenszyklus (SDLC) zu integrieren. Sicherheit sollte nicht der letzte, kostspielige Schritt sein, sondern näher an den Anfang des Prozesses rücken, indem AppSec-Teams bereits bei der Entstehung von Softwareprojekten eingebunden werden.

Das ist kein schlechter Rat, und er ist sicherlich besser als die alte Vorgehensweise (die – wenn man die Menge der gestohlenen Daten und das Alter der dafür genutzten Schwachstellen betrachtet – ohnehin nicht funktioniert). Wenn wir jedoch tatsächlich bei null anfangen würden, wären die Sicherheitsergebnisse weitaus positiver.

Shift Left, Start Left... wo liegt der Unterschied? Der Unterschied liegt darin, wie Sie Ihr Entwicklungsteam einbinden. Sie sind der Schlüssel zur Bereitstellung sichererer Software – und das weitaus kostengünstiger, als es Toolchains in späteren Phasen oder manuelle Code-Reviews jemals könnten. In einer idealen Welt hätte jeder Entwickler das Wissen und die Werkzeuge, um von Anfang an sicher zu programmieren. Sie würden potenzielle Schwachstellen erkennen und entschärfen, bevor sie in den Code gelangen (wo ihre Beseitigung weitaus teurer wäre). Dies würde die Sicherheitslücken, die wir seit Jahrzehnten sehen – und die immer noch Angreifern den Zugang durch die Hintertür ermöglichen – drastisch reduzieren. Die Einfallstore wie SQL-Injection, Cross-Site-Scripting und fehlerhafte Authentifizierung würden sich schließen.

Derzeit wird jedoch auf beruflicher Ebene zu wenig Wert auf Sicherheit gelegt, und die Qualität der Secure-Coding-Schulungen am Arbeitsplatz variiert stark. Infolgedessen fehlt Entwicklern oft das Rüstzeug, um „Start Left“ in einem Unternehmen zu ermöglichen. Es ist an der Zeit, dass Führungskräfte zusammenarbeiten und sich für ein breiteres Sicherheitsbewusstsein einsetzen. Ihr direktes Wissen und der Kontakt zu den Entwicklern sind entscheidend, um Programme voranzutreiben, die auch wirklich funktionieren. Schließlich saßen Entwicklungsleiter selbst einmal an dieser Stelle, arbeiteten mit den Tools und wussten, wie schwierig es ist, sich im Sicherheitsbereich zurechtzufinden.

Entwickler lieben Sicherheit (noch) nicht... aber Sie können das ändern.

Sie kennen das: Erwähnen Sie gegenüber einem typischen Entwickler das Wort „Sicherheit“, ernten Sie bestenfalls ein Augenrollen, schlimmstenfalls Ratlosigkeit. Im Allgemeinen wird das ganze Thema Sicherheit als Problem von jemand anderem betrachtet.

Die Hauptaufgabe eines Entwicklers besteht darin, funktionale Software zu erstellen, die vor innovativen Funktionen strotzt und innerhalb eines engen Zeitrahmens geliefert wird. Sicherheit hat auf Code-Ebene selten Priorität und wird oft sogar als lästiges Hindernis für schnelle Bereitstellung und Kreativität wahrgenommen. AppSec hat die Aufgabe, den Code akribisch zu prüfen, Penetrationstests durchzuführen und dann die schlechte Nachricht zu überbringen: Es gibt Sicherheitslücken in Code, der oft schon festgeschrieben ist und ansonsten einwandfrei funktioniert. Das ist ein teurer Prozess in einer Umgebung, die oft unter Ressourcen- und Zeitdruck steht – eine Konstellation, die zwangsläufig zu einem Zerwürfnis zwischen zwei Teams führt, die zwar das gleiche Ziel verfolgen, aber völlig unterschiedliche Sprachen sprechen.

In diesem Klima dürfte die Akzeptanz für verpflichtende Sicherheitsschulungen eher gering sein. Doch die Fähigkeit, bei jedem Entwickler ein Sicherheitsbewusstsein zu wecken, ist kein Wunschdenken. Mit der richtigen Art von Training und Unterstützung können sie beginnen, Sicherheit direkt in ihre Software zu integrieren und Verantwortung für die Sicherheitsergebnisse zu übernehmen, die sie selbst beeinflussen können. Wenn Entwickler sich um die gängigen Schwachstellen kümmern, haben die teuren Spezialisten den Kopf frei für wirklich komplexe Probleme. Und wenn Sie ein Entwicklungsteam leiten, können Sie maßgeblich dazu beitragen, diese Lücke zu schließen und Ihrem Team die Vorteile aufzuzeigen.

Training ist nicht gleich Training.

Wann haben Sie sich das letzte Mal wirklich für etwas Neues begeistert? Wenn Sie daran zurückdenken, kommen Ihnen Begriffe wie „verpflichtend“, „Compliance“ oder „siebzehn Stunden Videomaterial“ wahrscheinlich nicht in den Sinn.

Entwicklern geht es nicht anders. Sie sind klug, kreativ und lieben es, Probleme zu lösen. Es ist äußerst unwahrscheinlich, dass das Ansehen endloser Videos über Sicherheitslücken sie motiviert, die Inhalte einprägsam macht oder einen direkten Bezug zu ihrem Arbeitsalltag herstellt. Während meiner Zeit als SANS-Dozent wurde mir sehr schnell klar: Das beste Training ist praxisorientiert. Es zwingt die Teilnehmer dazu, zu analysieren und sich intellektuell herausfordern zu lassen – anhand von Beispielen aus der Praxis, die den Verstand fordern und auf vorhandenem Wissen aufbauen. Gamification und freundschaftlicher Wettbewerb sind ebenfalls wirkungsvolle Instrumente, um alle für neue Konzepte zu begeistern und gleichzeitig einen nützlichen, praktischen Mehrwert zu bieten.

Ein weiterer beängstigender Faktor ist, dass viele Sicherheitsschulungen nicht überwacht werden. Niemand hat das Gefühl gerne, dass „Big Brother“ zuschaut, aber was bringt es, Zeit, Geld und Mühe in Bildung zu investieren, wenn niemand prüft, ob sie überhaupt relevant ist?

Die richtige Lösung kann sicheres Programmieren unterhaltsam, relevant, motivierend und messbar machen. Fordern Sie Ihre Entwickler heraus, behandeln Sie sie gut und machen Sie daraus ein besonderes Ereignis. Gamified Training aktiviert die Belohnungszentren im Gehirn. Anreize zu schaffen, um weiterzulernen, Wissensgrenzen zu verschieben und schlichtweg Software auf einem höheren Standard zu bauen, ist eine Win-Win-Situation für alle.

Gesundheitscheck der Sicherheitskultur: Liegt Ihre auf der Intensivstation?

Sichere Software in einer Umgebung mit schlechter Sicherheitskultur zu entwickeln, ist wie der Versuch, einen Marathon mit einem Felsbrocken am Bein zu laufen: praktisch unmöglich und unnötig schwer.

Spielerische Trainings, direkte Wettbewerbe und die gezielte Förderung der Sicherheitskompetenz von Entwicklern tragen maßgeblich zu einer positiven Sicherheitskultur bei. AppSec- und Entwicklungsteams erhalten so tiefere Einblicke in ihre tägliche Arbeit. Dies stärkt die Zusammenarbeit und verhindert, dass das oft knappe Sicherheitsbudget immer wieder für dieselben lästigen Fehler verschwendet wird.

Ein weiterer positiver Nebeneffekt: Sie entdecken Sicherheitsexperten in Ihren eigenen Reihen, von denen Sie bisher nichts wussten. Durch fundierte Schulungen, die alle einbeziehen und eine gründliche Bewertung ermöglichen, kristallisieren sich Talente heraus, die nicht nur ein Gespür für Sicherheit haben, sondern sich auch leidenschaftlich dafür einsetzen. Diese Champions sind entscheidend, um den Schwung beizubehalten, als Schnittstelle zwischen den Teams zu fungieren und die Einhaltung von Best Practices zu überwachen. Ein starkes Champion-Programm mit Anerkennung und Rückhalt durch das Management ist ein Gewinn für das Unternehmen und wertet zudem den Lebenslauf der Mitarbeiter deutlich auf.

Wenn Sie sich für eine positive Sicherheitskultur entscheiden, wird Verantwortung geteilt und ein höheres Niveau an Software-Exzellenz erreicht. Letztendlich sollte für jeden im Software-Entwicklungszyklus ein einfaches Motto gelten: Wenn Software nicht sicher ist, ist sie keine gute Software.

Sagen Sie es weiter.