Security-Audits für Software bedeuten, Sicherheitslücken kontinuierlich im Entwicklungsprozess zu erkennen, statt erst nach einem Vorfall zu reagieren. Der Schlüssel liegt nicht in einmaligen Aufräumaktionen, sondern in einem positiven Trend: neue Probleme vermeiden, bestehende schrittweise abbauen, Tools direkt in Code-Reviews integrieren.
Das Wichtigste in Kürze
- Ad-hoc-Aufmerksamkeit für Security funktioniert nicht: Wer das Thema nur nach einem Vorfall angeht, verliert die Attention genauso schnell wieder, wie sie gekommen ist.
- Statt Aufräumaktionen empfiehlt sich die Zeltplatzregel: Wer eine Datei oder Methode ohnehin anfasst, räumt dabei zwei oder drei Security-Findings direkt mit weg.
- Der Pull-Request ist der beste Integrationsort für Security-Checks, weil dort jede Änderung ohnehin vorbeikommt und ein menschlicher Reviewer die Tool-Ergebnisse sofort sieht.
- Eine siebenstellige Findingzahl muss kein Grund zur Panik sein: Wer eine Baseline zieht und kontinuierlich den Trend verbessert, hat mehr erreicht als ein Team, das einmalig aufräumt und danach nichts mehr tut.
- Security lässt sich nicht allein auf Code-Ebene beantworten, weil Rollenkonzepte, IT-Infrastruktur und organisatorische Regeln zwingend mitbetrachtet werden müssen.
Warum Security-Probleme so lange liegen bleiben
Fast jeder hält Security für wichtig, und trotzdem stecken in den meisten Systemen ungelöste Sicherheitsprobleme. Dieser Widerspruch ist der Kern des Problems. Es braucht keine lange Überzeugungsarbeit, um jemandem klarzumachen, dass Security relevant ist. Der Schritt vom Bewusstsein ins Handeln misslingt aber regelmäßig.
Ein Grund ist die schiere Schwierigkeit, das Thema anzufassen. Wenn ein großer Hack durch die News geht, sind alle aufgeschreckt, die Aufmerksamkeit ist hoch. Dann kommt die nüchterne Frage: Betrifft uns das überhaupt? Bei der Log4Shell-Lücke ließ sich das noch relativ einfach prüfen. Viele andere Probleme sind komplexer und lassen sich nicht in wenigen Minuten zuordnen.
Hinzu kommt der Druck der Features. Entwicklungsteams arbeiten featuregetrieben, der nächste Sprint, das nächste Release. Kein Team sagt: Wir haben gerade keine Features, dann kümmern wir uns mal um Security. Die Features sind immer da, immer prominenter. Security konkurriert mit ihnen um dieselbe Zeit.
Findings auf Code-Ebene zu prüfen ist teuer
Sicherheitsbefunde lassen sich oft nicht allein im Code beantworten, und genau das macht sie so aufwendig. Ein Beispiel: Werte werden aus einer ini-Datei gelesen. Sofort steht die Frage im Raum, wer überhaupt in diese Datei schreiben darf. Das sieht man dem Code nicht an.
Damit wandert die Analyse schnell weg vom einzelnen File hin zur IT-Infrastruktur, zu Rollenkonzepten, zu organisatorischen Fragen. Security ist eben kein reines Code-Thema. Der lokale Kontext einer Datei reicht häufig nicht aus, um ein Finding zu bewerten.
Dazu kommen False Positives, im Security-Bereich tendenziell mehr als bei anderen Analysen. Sich durch diese Befunde zu wühlen, ist mühsam und wenig befriedigend. Man kommt kaum voran, und es stellt sich rasch Ernüchterung ein. Das verzögert die Auseinandersetzung weiter.
Entwicklung und Management ziehen aus denselben Findings unterschiedliche Schlüsse
Die beiden Perspektiven auf Security passen nicht automatisch zusammen. Das Entwicklungsteam muss jedes Finding auf detaillierter Code-Ebene nachvollziehen und entscheiden, ob es real ist. Das Management hat ein berechtigtes Interesse an einem sicheren System, oft verstärkt durch Auflagen von Behörden oder externe Guidelines.
In der Praxis zählen auf Management-Seite häufig die nackten Zahlen. Ob ein Befund ein False Positive ist oder nicht, tritt in den Hintergrund. Solche Findings sollen schlicht nicht auftauchen. Das erzeugt Spannung zu einem Team, das jeden einzelnen Befund teuer einordnen muss.
Diese Lücke zwischen Detailarbeit unten und Zahlenblick oben ist mit ein Grund, warum gut gemeinte Security-Initiativen zerfallen.
Ad-hoc-Aufmerksamkeit funktioniert nicht, kontinuierliche schon
Sporadische Aufmerksamkeit für Security bringt nichts. Etwas passiert, alle sind aufgescheucht, man macht ein paar Sachen, und dann ist die Aufmerksamkeit wieder weg. Dieses Muster trägt nachweislich nicht.
Was trägt, ist die kontinuierliche Auseinandersetzung mit dem Thema, und das gilt für Qualitätsthemen insgesamt, nicht nur für Security. Kurzfristig verschwinden dabei nicht alle Probleme. Mittelfristig stellt sich aber ein positiver Trend ein, und genau darauf kommt es an.
Schon viel erreicht hat ein Team, das die Probleme stoppt: Es wird nicht mehr schlimmer. Das ist die erste realistische Stufe. Wer es danach schafft, kontinuierlich besser zu werden, ist auf dem richtigen Weg. Alle sinnvollen Methoden zielen darauf, Security in den normalen Entwicklungsprozess zu integrieren, statt sie als Sonderaktion danebenzustellen.
Wie der Merge Request zum besten Ort für Security wird
Der größte Hebel sitzt dort, wo ohnehin jede Änderung vorbeikommt: im Merge Request oder Pull Request. GitLab und GitHub haben diesen Ort längst etabliert, und genau dort findet das Review statt.
Bringt man die Information “hier sind drei neue Findings im Bereich Security” direkt in den Merge Request, hat man eine Prüfstelle mit sehr niedriger Schwelle. Niemand muss ein zweites Tool öffnen oder einen statischen HTML-Report aus irgendeinem Verzeichnis suchen. Die Information ist da, wo jemand die Änderung sowieso freigeben muss.
Eine praktikable Regel: Solange die Tools noch Findings melden, geht kein menschlicher Reviewer an die Änderung. Erst wenn die automatischen Prüfungen sauber sind, beginnt das menschliche Review. Das spart Reviewer-Zeit und macht die Schwelle für sauberen Code zur Voraussetzung, nicht zur Kür.
Voraussetzung dafür ist Transparenz. Es ist unfair, wenn ein querschnittliches Security-Team irgendwann auftaucht und eine Liste mit Problemen auspackt. Teams müssen vorher wissen, worauf geschaut wird und wo sie selbst nachsehen können. Was per Tool prüfbar und im jeweiligen Kontext relevant ist, sollte aktiviert sein. Irrelevante Checks gehören abgeschaltet.
Eine Baseline schlägt die große Aufräumaktion
Bei Altsystemen mit riesigen Findings-Zahlen ist die Akzeptanz des Status quo der entscheidende Schritt. Siebenstellige Findings-Zahlen sind nichts Ungewöhnliches. Wer versucht, alles auf null zu bringen, scheitert an der Realität.
Die Lösung klingt zunächst banal: Man zieht eine Baseline und akzeptiert den aktuellen Stand. Bei sieben Millionen Findings ist das Ziel nicht, sie alle wegzuarbeiten, sondern dass es bei der nächsten Retrospektive nicht mehr werden. Den Bestand abzubauen dauert lange. Neue Probleme zu vermeiden, ist der Punkt, an dem der Trend kippt.
Dieser Trend wirkt motivierend. Irgendwann tritt die absolute Zahl in den Hintergrund, und man schaut nur noch auf die Richtung: Hat es wieder geklappt, zeigen die Pfeile nach oben. Das ist tragfähiger als jede absolute Kennzahl.
Große Aufräumaktionen sind dagegen meist kontraproduktiv. Drei Wochen ohne Features erzeugen Frust, weil die Features fehlen. Schlimmer noch: Durch die Korrekturen kommen oft neue Probleme rein, und dann steht man argumentativ schlecht da.
Besser ist die Zeltplatzregel: Verlasse den Zeltplatz etwas sauberer, als du ihn vorgefunden hast.
Wenn du eine Datei bearbeitest und dort Code änderst, nimm das als Gelegenheit, die Probleme dort zu adressieren. Du bist eh drin, hast es gelesen, hast es verstanden, es muss durch den Test und durchs Review. — Nils Göde
Wie viel Security-Wissen ein Entwicklungsteam wirklich braucht
Ein solides Grundwissen reicht, vor allem auf Code-Level, niemand muss zum Vollzeit-Security-Experten werden. Detailtiefe in jeder Lücke ist nicht das Ziel. Für tiefer liegende Angriffsflächen gibt es ergänzend den Pen-Test, der Dinge abfängt, die andere Prüfungen nicht sehen.
Reviews und Retrospektiven sind ein gutes Forum für den Wissensaustausch. Meist gibt es ein, zwei Personen im Team, die sich mit dem Thema schon beschäftigt haben. Blättert man in einer Retrospektive zwei oder drei exemplarische Findings auf und fragt: Warum ist das ein Problem, betrifft uns das, wie gehen wir künftig damit um, entsteht echter Austausch.
Ergänzt um etwas Dokumentation ist die Basis solide. Die Coding Guidelines um einen Abschnitt Security zu erweitern, hält das Wissen fest und macht es für alle nutzbar.
So startet ein Team in die kontinuierliche Security-Arbeit
Der pragmatischste Einstieg führt über das Tool, das ohnehin schon im Einsatz ist. Viele Analysewerkzeuge bringen bereits eine Reihe von Security-Checks mit. Diese Checks sind eine brauchbare Ausgangsbasis, ohne dass man das Thema vorher komplett top-down durchdenken muss.
Wahrscheinlich braucht es zum Auftakt eine Art Kick-off, der Security überhaupt auf die Agenda bringt. Danach lohnt je nach Anwendung ein Blick auf Guidelines wie die OWASP Top 10. Die Frage dabei: Was davon decken unsere vorhandenen Tools ab, wo bleiben Lücken, und braucht es ein zweites Tool, um sie zu schließen. Eine Integrationsplattform bündelt diese Informationen an einem Ort, damit niemand fünf Tools an fünf Stellen prüfen muss.
Von dort hangelt man sich über Retrospektiven Schritt für Schritt voran:
- Checks, die im eigenen Kontext nie relevant sind, werden in der Konfiguration deaktiviert, die Findings verschwinden.
- Checks, die grundsätzlich relevant sind, aber einzelne nicht relevante Treffer liefern, werden im Team diskutiert. Beispiel: Passwörter im Produktivcode sind ein klares Problem, Passwörter im Testcode sind diskussionswürdig.
- Schritt für Schritt entsteht eine passende Tool-Konfiguration plus Guidelines, die sich mit wenig Aufwand dauerhaft leben lässt.
Der wenig Aufwand ist der Knackpunkt. Security darf nicht zum Zusatzprojekt werden, sondern muss auf der Spur mitlaufen.
Sicherheit gegen Komfort: ein Trade-off, den viele nie zu Ende denken
Zwischen Sicherheit und Komfort gibt es einen Schieberegler, und viele Teams haben nie bewusst entschieden, wo er stehen soll. Hundert Prozent Sicherheit gibt es ohnehin nicht. Aber die Position auf dieser Skala lässt sich verschieben, Richtung Sicherheit oder Richtung Komfort.
Das Bild dazu ist der Geldautomat. Ohne PIN wäre er komfortabler, aber eben weniger sicher. Dasselbe gilt für die allermeisten Software-Systeme. Ein initiales Treffen ist ein guter Anlass, sich dieser Frage bewusst zu stellen, statt sie implizit liegen zu lassen.
Auch beim Beispiel Test-User zeigt sich das. Test-Accounts schlagen in Prüfungen an, etwa weil Organisationsvorgaben regelmäßige Passwortwechsel verlangen. Wie sicher die Testinfrastruktur sein soll und wie komfortabel sie bleiben darf, ist genau so eine Trade-off-Entscheidung, die ins Team gehört.
Was Vorfälle wie Log4Shell tatsächlich verändern
Ein großer Vorfall erzeugt Momentum, und dieses Momentum lässt sich in dauerhafte Aufmerksamkeit übersetzen. Bei Log4Shell war die Relevanz für alle spürbar, jeder war bemüht zu verstehen, wo das Problem liegt und wie man sich schützt. Insofern hat der Mechanismus funktioniert.
Der Haken: Solche Reaktionen tragen weiterhin den Charakter des Ad-hoc-Vorgehens. Jetzt ist gerade ein großes Problem, also kümmern sich alle. In günstigen Fällen gelingt es, daraus ein angemessenes Level an dauerhafter Aufmerksamkeit für Security zu etablieren. Genau darin liegt der Wert eines Vorfalls.
Ungenutzte Schwachstellen sind schlummernde Schläfer, kein Freibrief
Eine Schwachstelle, die heute keinen Schaden anrichtet, ist kein Beleg dafür, dass sie harmlos ist. Sie zahlt auf die Zukunft ein. Im besten Fall wird sie nicht genutzt, doch verlassen kann man sich darauf nicht.
Die Annahme, ungenutzte Lücken würden grundsätzlich nicht ausgenutzt, ist riskant. Es gibt Lücken, die auf irgendeine Weise genutzt werden, ohne dass es zum Super-GAU kommt. Nicht jeder Angriff will ein System lahmlegen. Manchem reicht es, massenweise Daten abzusaugen, ohne dass es jemandem auffällt.
Deshalb ist die ehrliche Formulierung wichtig: Nach aktuellem Kenntnisstand ist nichts passiert. Wissen lässt sich das nicht. Die Dunkelziffer dürfte hoch sein, auch weil Betroffene kein Interesse daran haben, dass solche Vorfälle publik werden.
