Vertrauen ist gut – Kontrolle ist Pflicht: Christian Wenz über moderne Softwaresicherheit

Christian Wenz sitzt entspannt im Interviewstuhl auf der DWX, doch seine Worte haben Gewicht. Seit über zwei Jahrzehnten beschäftigt er sich mit Softwaresicherheit, und wer ihm zuhört, erkennt schnell: Hier spricht keiner, der sich in theoretischen Konstrukten verliert. Christian ist Pragmatiker – einer, der nicht nur Risiken benennt, sondern auch weiß, warum sie immer wiederkehren.

Und die Sicherheitslücken, die er in Web- und Cloud-Anwendungen sieht, ähneln sich seit Jahren. Was sich ändert, sind Frameworks, Tools, vielleicht auch die Sprache – nicht aber das Grundproblem. Und das, so Christian, heißt Vertrauen.

Vertrauen in Nutzereingaben. Vertrauen in externe APIs. Vertrauen in das eigene Framework. Vor allem aber: Vertrauen in die Illusion, dass Sicherheit sich durch Konvention einstellt, nicht durch aktive Gestaltung. Die meisten Schwachstellen, denen er in Projekten begegnet, lassen sich auf eines zurückführen – ein fehlendes Korrektiv für Annahmen, die nie hätten getroffen werden dürfen.

Sicherheitsdenken beginnt nicht im Debugger

„Security by Design“ ist längst Teil des Entwicklervokabulars, doch in der praktischen Umsetzung bleibt es oft Wunschdenken. Wenz kennt die Ursache: zu viel Fokus auf Technik, zu wenig Bewusstsein für Prozess und Verantwortung. Sicherheit lässt sich eben nicht nachrüsten wie ein Linter oder ein Logging-Modul. Sie muss von Beginn an mitgedacht werden – im Architekturentwurf, in der Datenflussanalyse, in der Entscheidung, ob eine bestimmte Schnittstelle überhaupt öffentlich sein sollte.

Und genau hier liegt das Dilemma: Es gibt keinen Masterplan, kein universelles Regelwerk, das jede Anwendung sicher macht. „Der eine Schuh, der allen passt – den gibt es nicht“, sagt Wenz. Wer nach einfachen Antworten sucht, wird in der Security enttäuscht. Was es braucht, ist Kontextsensibilität: das Wissen um Bedrohungen, die Bereitschaft, etablierte Muster zu hinterfragen – und die Fähigkeit, zwischen Vertrauen und Kontrolle zu unterscheiden.

Standards sind kein Luxus, sondern Pflicht

Auf die Frage, welche Rolle Sicherheitsstandards wie die OWASP Top 10 oder die Content Security Policy im Entwickleralltag spielen sollten, antwortet Wenz ohne Zögern: Pflicht. Und zwar nicht, weil sie alles lösen – sondern weil sie überhaupt erst ein Problembewusstsein schaffen. Die OWASP Top 10 etwa ist kein Dogma, sondern ein Einstieg: eine Einladung, sich mit den typischen Schwachstellen zu beschäftigen, die jede Webanwendung betreffen könnten. Eine Art Kartenmaterial für gefährliche Gegenden im digitalen Raum.

Bei der Content Security Policy hört für Christian der Spaß auf. Wer moderne Webanwendungen ohne CSP ausliefert, verzichtet auf eine der effektivsten Möglichkeiten, Angriffsvektoren wie Cross-Site Scripting einzuschränken. Dass viele Teams diese Header noch immer ignorieren oder fehlerhaft konfigurieren, wertet er als fahrlässig – oder als Zeichen dafür, dass Security zu selten im Fokus steht.

Das Framework macht es nicht automatisch richtig

Ein Thema, das ihm besonders am Herzen liegt, ist der Umgang mit Authentifizierung, Autorisierung und Session-Management. Die meisten modernen Frameworks bieten dafür solide Werkzeuge – und genau darin liegt die Falle. Denn allzu oft verlassen sich Entwickler*innen blind darauf, dass das Framework schon alles regelt. „Das ist eine Form von Vertrauen, die brandgefährlich ist“, warnt Wenz.

Natürlich ist es sinnvoll, auf etablierte Lösungen zu setzen. Niemand muss Session-Cookies selbst basteln oder eine Auth-Logik from scratch schreiben. Aber: Wer nicht versteht, was das Framework tut – und was nicht –, wird irgendwann in Schwierigkeiten geraten. Sicherheitsfeatures müssen konfiguriert, verstanden und auf den eigenen Anwendungsfall abgestimmt werden. Es reicht eben nicht, nur das Richtige zu benutzen. Man muss es auch richtig benutzen.

Automatisierung hilft – aber sie reicht nicht

Zum Abschluss des Gesprächs geht es um die Frage, ob sich Sicherheit nicht einfach automatisieren ließe. Static Code Analysis, Dependency Scanning, automatisierte Tests in der CI/CD-Pipeline – wäre es nicht wunderbar, könnte man Security einfach in den Build-Prozess schieben und abhaken?

Wenz winkt ab. „Das ist ein Fiebertraum.“ Automatisierung sei wichtig, keine Frage – aber sie finde meist nur die einfachen Fehler. Und selbst wenn ein Tool eine Schwachstelle aufspürt, muss immer noch jemand da sein, der sie versteht, bewertet und behebt. Sicherheit ist kein Zustand, den man erreicht, sondern ein ständiger Prozess. Tools sind Teil dieses Prozesses – aber sie ersetzen nicht den Menschen.

Fazit

Wer mit Christian Wenz über Sicherheit spricht, merkt schnell: Es geht nicht um Buzzwords, sondern um Haltung. Sicherheit ist kein Modul, das man irgendwann dazupackt – sie ist eine Grundhaltung gegenüber Software, gegenüber Daten, gegenüber Verantwortung. Vertrauen ist gut, sagt man. Doch in der Welt von Christian Wenz ist eines sicher: Kontrolle ist Pflicht.