Möge die Sicherheit mit dir sein Was Sicherheitsverantwortliche von Star Wars lernen können

Anbieter zum Thema

GitHub Inc.

Fsas Technologies GmbH

SEPPmail - Deutschland GmbH

Ein ungesicherter Lüftungsschaft war ausreichend, um den Todesstern in die Luft zu jagen. Die größte Schwachstelle war keine Superwaffe der Rebellen, sondern die Ignoranz des Imperiums gegenüber Sicherheits­prinzipien. Der Todesstern wurde nicht zerstört, weil er zu schwach gebaut war, sondern weil die Sicherheit vernachlässigt wurde.

Anhand des Finales von „Krieg der Sterne: Episode IV“, in dem der Todesstern zerstört wird, zeigt sich, dass Sicherheitsarchitektur und Risikobewertung nicht vernachlässigt werden soll­ten. Was für den Todesstern gilt, gilt auch in modernen IT-Landschaften. Auch in der Realität reicht eine einzige übersehene Sicherheitslücke, um ganze Unternehmen ins Wanken zu bringen. Angesichts komplexer Software-Lieferketten, Zero-Day-Exploits und wachsender regulatorischer Anforderungen reicht es nicht, Sicherheit am Ende eines Projekts „drauf­zusetzen“. Sie muss von Beginn an Teil des Entwicklungsprozesses sein.

Von Anfang an sicher

Die Vorteile von „Secure by Design“

Wie Produktivität und Sicherheit Hand in Hand gehen

Von kleinen Start-ups bis hin zu globalen Unternehmen wächst der Druck, Sicherheits­maß­nahmen in die Entwicklungsprozesse zu integrieren, ohne dabei die Innovations­ge­schwin­dig­keit zu verringern. Klassische Scanning-Tools führen hierbei nicht zum gewünschten Erfolg: komplizierte Implementierung, mangelnde Akzeptanz bei Entwicklern und zu viele False Positives.

Deshalb gelten Sicherheitsmaßnahmen in vielen Entwicklungsteams noch immer als not­wen­diges Übel. Ein zusätzlicher Schritt, der Zeit kostet und oft für Frust sorgt. Doch Security muss kein Bremsklotz sein. Denn richtig integriert kann sie die Produktivität von Entwicklungsteams sogar steigern. Aus den Erfahrungen von Unternehmen wie IKEA, SAP und WirelessCar lassen sich konkrete Handlungsempfehlungen ableiten.

1. Sicherheit dort verankern, wo gearbeitet wird

R2-D2, der Astromech-Droide aus dem Star-Wars-Universum, wartet nicht auf Anweisungen der Planeten Tatooine oder Dagobah, um Luke beim Fliegen zu navigieren – er ist von Anfang an in seinem X-Wing mit dabei. Währenddessen ist ein zentrales Problem vieler Legacy-Tools, dass Entwicklerteams ihre gewohnte Arbeitsumgebung verlassen müssen. Aus diesem Grund ent­schied sich zum Beispiel auch IKEA für eine Integration von Sicherheitstools in bestehende Entwickler-Workflows. Dadurch konnten Sicherheitsprüfungen, etwa durch Pull Requests, di­rekt in den Entwicklungsprozess eingebettet werden. So lassen sich Probleme erkennen und beheben, bevor sie überhaupt in die Codebasis gelangen. Das senkt die Hürde und reduziert den Kontextwechsel, der im Alltag häufig wertvolle Zeit kostet. Auch der zeitliche Aufwand für Kon­fi­guration und Updates, der bei selbstgehosteten Lösungen häufig anfällt, kann so reduziert werden und Sicherheitsteams können sich stärker auf strategische Aufgaben konzentrieren.

Shift-Left in der Softwareentwicklung, Teil 2

DevSecOps-Prozesse in der Praxis

2. Entwicklerteams frühzeitig einbinden

„Eine elegante Waffe für ein zivilisiertes Zeitalter.” Mit diesen Worten wandert das Licht­schwert von Obi-Wan in die Hände eines anfangs noch zögernden Luke, und der Rest ist Geschichte. Nicht nur für Lichtschwerter gilt: Die Akzeptanz von Sicherheitstools steigt deutlich, wenn Nutzer nicht erst am Ende, sondern schon in der Einführungsphase eingebunden werden. Nur wenn sie die Tools akzeptieren und aktiv mitgestalten, werden diese langfristig erfolgreich eingesetzt. Das zeigen auch interne Umfragen von SAP: Entwicklerteams fühlten sich durch die frühe Einbindung in neue Sicherheitstools produktiver, Fehler wurden schneller behoben und die Akzeptanz für verpflichtende Sicherheitstools stieg auf einen Net Promoter Score von 75.

Besonders wirksam sind Funktionen, die unmittelbares Feedback geben: Pull-Request-Scans zum Beispiel machen Schwachstellen direkt im Code-Review sichtbar und erhöhen dadurch die Wahrscheinlichkeit, dass sie sofort behoben werden. Auch Auto-Fix-Funktionen können helfen, Routinefehler ohne großen Aufwand zu beseitigen. Gleichzeitig sollten Produktteams die Frei­heit haben, mit ergänzenden Tools zu arbeiten, solange die Ergebnisse aller Tools in einem zentralen Dashboard zusammengeführt werden.

Softwaresicherheit im Wandel

Den Schwachstellen-Teufelskreis durchbrechen

3. Governance und Transparenz schaffen

Denn Sicherheit braucht klare Zuständigkeiten und Prioritäten. Große Unternehmen nutzen zentralisierte Übersichten, wie Dashboards, um den Überblick über hunderte Repositories zu behalten. Außerdem lassen sich mit deren Funktionen, um Repositories und Risiken nach Ge­schäftskritikalität bewerten, um Ressourcen gezielter einzusetzen. Auf diese Weise lässt sich vermeiden, dass alle Schwachstellen, unabhängig davon, wie relevant sie für das Geschäft sind, gleich behandelt werden.

Darüber hinaus helfen Governance-Strukturen, wie klar definierte Rollen, Zugriffs­be­schrän­kungen und CI/CD-gestützte Rollouts, eine schnelle und flächendeckende Einführung neuer Sicherheitsfunktionen. Nicht umsonst ist in späteren Filmen nicht mehr von Prinzessin, son­dern von Generalin Leia die Rede.

Von der Rechtsnorm zur Codezeile

Datenschutz beginnt im Code

4. Developer-freundliche Tools auswählen

Nicht jedes Tool erfüllt seinen Zweck. Denn nur wenn sie einfach einzurichten sind und eine in­tuitive Oberfläche bieten, werden sie von Teams akzeptiert, wie C-3PO einst von der Re­bellen­allianz. Entscheidend ist, dass Sicherheitslösungen aussagekräftige Ergebnisse liefern, Fehl­alarme minimieren, sich ohne großen Aufwand in bestehende Prozesse integrieren lassen und kontinuierlich neue Programmiersprachen unterstützen. Automatisierte Prozesse wie bei­spiels­weise Secret Scanning können dabei sofort sichtbare Erfolge liefern und zeigen Teams, wel­chen Mehrwert Sicherheit bringen kann. Für WirelessCar zeigte sich so, wie schnell un­ent­deckte Risiken sichtbar und eliminiert werden können.

Sicherheit im Software-Lebenszyklus

Wie Automatisierung DevSecOps und Anwendungssicherheit verändert

5. Fortschritte sichtbar machen

In der Schlacht um den Todesstern fliegt niemand blind. Sicherheitsinitiativen sind nur dann nachhaltig, wenn Fortschritte über KPIs und Dashboards sichtbar gemacht und kommuniziert werden. Dazu gehören messbare Kennzahlen wie geschlossene Sicherheitslücken, die Zeit bis zur Behebung oder die Reduktion von False Positives.

Ebenso wichtig ist das Feedback der Entwicklerteams selbst. Denn nur so zeigt sich, ob die Maßnahmen tatsächlich als hilfreich empfunden werden oder ob Anpassungen nötig sind. Sie geben Rückmeldung zur Nutzererfahrung, zeigen Verbesserungsbedarf auf und helfen, die Wirkung von Sicherheitstools auf Produktivität und Codequalität zu validieren.

Empfehlungen von ATHENE

So integrieren Sie die CRA-An­for­de­rung­en in Ihre SecDevOps-Prozesse

Security als strategische DNA

Der Vergleich mit dem Krieg der Sterne verdeutlicht, wie gefährlich es ist, Sicherheit als Nebensache zu behandeln. Denn Sicherheitslücken entstehen nicht durch fehlende Stärke, sondern durch fehlende Weitsicht. Für heutige Sicherheitsverantwortliche bedeutet das: Sicherheit darf nicht am Ende von Projekten stehen, sondern muss integraler Bestandteil des gesamten Entwicklungszyklus sein.

Erfolgreich gelingt das nur, wenn Entwickler frühzeitig eingebunden, Tools nahtlos in bestehende Workflows integriert und Fortschritte transparent gemacht werden. So wird Sicherheit nicht zum Bremsklotz, sondern zum Enabler, stärkt die Resilienz von Unternehmen und kann die Produktivität von Teams steigern. Denn nur, wenn Security automatisch mitläuft, bleibt sie langfristig wirksam und wirklich konsequent. Oder, um es in anderen Worten zu sagen: „Tu es oder tu es nicht. Es gibt kein Versuchen.“

Über den Autor: Steffen Wagner ist Head of Enterprise Sales DACH bei GitHub.

EU-Verordnung verlangt Software-Stücklisten

Onekey-Report: SBOMs als Fundament digitaler Resilienz

(ID:50622660)