Grundwissen Software-Entwicklung: Copy & Paste – Code erzeugt Sicherheitsprobleme

Clean Code und IT-Security hängen eng zusammen. Mangelnde Softwarequalität ist als Ursache für Sicherheitsprobleme bekannt und schafft es auch immer wieder in die Medien – zuletzt geschehen zur Bundestagswahl 2017: Die von Gemeinden in ganz Deutschland seit vielen Jahren bei Wahlen eingesetzte Software „PC Wahl“ wies eklatante Sicherheitslücken auf. Die Sorge vor möglicher Wahlmanipulation bereitete sich aus. Der Hersteller war kurzfristig nicht in der Lage, die Sicherheits-Lücken seiner Software zu schließen. Am Ende bot sogar der Chaos Computer Club (CCC) seine Hilfe an. Ein PR-Desaster für den Hersteller.

Das Gegenteil von Clean:
Mit Copy & Paste Sicherheitsprobleme verbreiten

Eine veraltete Softwarearchitektur und Sicherheitslücken im Updateprozess sollen im beschriebenen Fall eine Rolle gespielt haben. Eine der größten Fehlerquellen besteht meiner Ansicht nach im „sorglosen“ kopieren von Quellcode. Wer hat nicht schon einmal zu einem speziellen Problem nach einer „fertigen Lösung“ bei Stackoverflow , der größten inoffiziellen (Java)Codebasis der Welt, recherchiert?

Das Problem dabei: Tut man das, ohne den Kopf einzuschalten, dann kopiert man vielleicht nicht nur schlechten, sondern womöglich sogar gefährlichen Quellcode.

Code wird eher kopiert statt kapiert

Eine aktuelle Studie zeigt das sehr schön, was in einem Heise-Security-Artikel angerissen wird: Code für essentielle Security-Themen (Auth, Zerts, Encryption etc.) wird häufig eher kopiert statt kapiert. Selbststudium zu Themen und Problemen anhand von Büchern oder aus der API sind demnach eher die Ausnahme. Stattdessen dominiert die Vorgehensweise „Copy & Paste“ aus dem Web bei der Problemlösung.

Kampf dem Copy & Paste

Zunächst gilt es, Folgendes zu beachten:

• Es wird nicht jeder Entwickler im Team (wahrscheinlich nicht einmal einer pro Team) jedes Security-Thema verstehen und korrekt und sicher umsetzen können.
• Bibliotheken sind statt eigenem (oder kopiertem) Code zu bevorzugen. Diese sind dann aber auch korrekt einzusetzen und aktuell zu halten.
• Es werden trotzdem im Lauf der Zeit durch Altern von Code, Libs und Algorithmen Sicherheitslücken auftreten, auf die es zu reagieren gilt.

Hier ist mein praxisorientierter Lösungsansatz, der sich aus folgenden Bausteinen zusammensetzt:

• Weiterbildung der Entwickler im Bereich Security und Clean Code.
• Einsatz von automatisierten Werkzeugen im Continuous-Integration-Prozess zum Aufdecken von solchen Sicherheitslücken (Voraussetzung ist hier natürlich die Existenz eines solchen CI-Prozesses) und kontinuierliches Monitoring und Alerting der Ergebnisse.
• Integration bzw. Verankerung der SDLC-Prinzipien im Entwicklungsprozess.
• Externe Penetration/Security-Tests als obligatorische Tests in die QS integrieren (weit oben in der Testpyramide).

Als mittelfristige stützende Maßnahme braucht eine solide Lösung zur Vermeidung der genannten Security-Probleme eine organisatorische Verankerung. Zentralisierung und Standardisierung in der Organisation sind gefragt, etwa in Form eines cross-funktionalen agilen Security-Teams (bestehend aus Tester, Entwickler, Administrator, Hacker), das sich um die Umsetzung der vier Stufen in den Teams der Organisation kümmert.

Hier ist das Management gefragt – eine Etablierung eines solchen Teams (neben formalen Positionen wie etwa dem IT-Sicherheitsbeauftragten) sollte jedoch im höchsten Eigeninteresse der Unternehmung liegen.

Die Grundlage sicherer Software ist die sichere Softwareentwicklung. Für alle Softwareentwickler befassen wir uns daher in einer Blogreihe mit den 15 Prinzipien der sicheren Softwareentwicklung.