Full-Cycle Security Engineer: Warum Entwickler Pentesting lernen sollten

March 18, 2026Ich war Backend-Entwickler. Dann habe ich angefangen, meinen eigenen Code anzugreifen. Nicht aus Langeweile. Nicht weil es gerade hip war. Sondern weil ich in einem Projekt saß, in dem ein externer Pentester uns einen 40-seitigen Report auf den Tisch gelegt hat -- und niemand im Team wirklich verstanden hat, was davon kritisch ist, was Noise ist, und vor allem: wie man es richtig fixt. Der Pentester hat geschrieben: "JWT-Signatur wird nicht validiert." Unser Lead hat gesagt: "Dann validieren wir halt." Was dann passiert ist? Die Validierung wurde eingebaut, aber der Key wurde hardcoded im Frontend hinterlegt. Problem gelöst, neues Problem geschaffen. Klassiker. An dem Tag habe ich beschlossen, dass ich beide Seiten verstehen will. Nicht nur Code schreiben, der funktioniert -- sondern Code schreiben, der standhält.

Das Problem: Dev und Security sprechen nicht die gleiche Sprache

In den meisten Unternehmen gibt es eine unsichtbare Mauer zwischen Entwicklung und Security. Und diese Mauer kostet richtig Geld.

Die Developer-Seite

Entwickler denken in Features, Deadlines und User Stories. Security ist das Ding, das "am Ende" draufkommt. Wie ein Vorhängeschloss an einer Tür, die schon eingebaut ist. Das Problem: Wenn die Tür aus Pappe ist, hilft das Schloss nicht viel. Die meisten Devs, die ich kenne (mich eingeschlossen, früher), machen folgende Fehler:

Input Validation? "Ach, das Frontend validiert doch schon."
Secrets Management? .env-Datei ins Repo, weil es schnell gehen muss.
Authorization? "Der Endpoint ist ja nur intern." (Spoiler: Nichts ist nur intern.)
Error Handling? Stack Traces direkt an den Client, weil es beim Debuggen hilft.

Das sind keine Anfängerfehler. Das passiert in Teams mit 10+ Jahren Erfahrung. Weil Security Thinking nicht Teil der Entwickler-Ausbildung ist. Du lernst Algorithmen, Design Patterns, Clean Code. Aber niemand bringt dir bei, wie ein Angreifer deine API anschaut.

Die Pentester-Seite

Pentester sind gut darin, Dinge kaputtzumachen. Das ist ihr Job. Aber die meisten Pentester haben nie produktiven Code geschrieben. Sie kennen OWASP Top 10 auswendig, können dir Burp Suite im Schlaf erklären und finden eine IDOR-Vulnerability in 20 Minuten. Was sie nicht können: dir sagen, wie du deine Architektur umbauen musst, damit das Problem nicht in drei Monaten in einer anderen Form wiederkommt. Ihr Report sagt: "Broken Access Control in /api/users/{id}." Ihr Fix-Vorschlag sagt: "Implementieren Sie eine Autorisierungsprüfung." Danke. Sehr hilfreich. Was fehlt: Soll ich das pro Endpoint machen? Middleware? Policy-based? RBAC oder ABAC? Wie integriere ich das in meine bestehende Architektur, ohne dass ich 200 Endpoints anfassen muss? Was ist mit den Edge Cases bei Multi-Tenancy?

Das Ergebnis: Teurer Ping-Pong

Was in der Praxis passiert, ist ein endloser Kreislauf:

Dev-Team baut Feature
Security-Team testet (Wochen später)
Report mit 30 Findings
Dev-Team fixt (ohne Security-Kontext)
Security-Team re-testet
10 Findings sind gefixt, 5 neue sind entstanden
Zurück zu Schritt 4

Ich habe das oft genug erlebt. In einem Projekt hat dieser Zyklus vier Monate gedauert. Vier Monate, in denen Features liegen blieben, weil das Team im Fix-Modus feststeckte.

Was ein Full-Cycle Security Engineer macht

Ein Full-Cycle Security Engineer ist kein Hybrid aus zwei halben Rollen. Es ist eine eigene Disziplin. Jemand, der Software baut UND angreift -- und deshalb an jeder Stelle im Entwicklungsprozess den richtigen Hebel kennt.

Secure Architecture von Tag 1

Bevor eine Zeile Code geschrieben wird, schaue ich mir die Architektur an. Nicht als Reviewer von außen, sondern als jemand, der sie mitgestaltet.

Wo liegen die Trust Boundaries?
Welche Daten sind sensitiv und wie fließen sie durch das System?
Welche Angriffsvektoren ergeben sich aus der gewählten Architektur?
Ist die Auth-Strategie skalierbar oder wird sie zum Bottleneck?

Das klingt nach viel Aufwand am Anfang. Ist es auch. Aber es ist ein Bruchteil dessen, was es kostet, eine unsichere Architektur später umzubauen.

Threat Modeling im Design

Threat Modeling ist nicht "wir malen ein Diagramm und schreiben STRIDE daneben." Es ist eine Denkweise. Bei jedem Feature frage ich: Was passiert, wenn jemand das absichtlich missbraucht? Ein Login-Feature? Okay, was passiert bei:

Brute Force? Rate Limiting, Account Lockout, progressive Delays.
Credential Stuffing? Breach-Detection, Anomaly-basierte Alerts.
Session Hijacking? Secure Cookies, Token Rotation, Device Fingerprinting.
Password Reset Abuse? Token Expiry, One-Time-Use, kein User Enumeration.

Wenn du das erst nach dem Pentest überlegst, baust du es auf ein Fundament, das nicht dafür gemacht war. Das wird teuer, fragil und meistens unvollständig.

Secure Code Review (nicht nur Linting)

SonarQube, Semgrep, CodeQL -- alles gute Tools. Aber sie finden Business Logic Vulnerabilities nicht. Sie finden keine Race Conditions in deinem Payment Flow. Sie finden nicht, dass dein Admin-Endpoint zwar Auth hat, aber die falsche Role checkt. Ein manuelles Code Review durch jemanden, der sowohl den Code versteht als auch weiß, wie ein Angreifer ihn ausnutzen würde, ist durch kein Tool ersetzbar. Ich lese Code nicht als Entwickler, der Bugs sucht. Ich lese Code als Angreifer, der einen Weg rein sucht. Das ist ein fundamentaler Unterschied.

Penetration Testing des eigenen Codes

Ja, ich teste meinen eigenen Code. "Aber ist das nicht ein Interessenkonflikt?" Nein. Es ist ein Vorteil. Ich kenne die Architektur. Ich weiß, wo die Shortcuts sind. Ich weiß, welche Edge Cases wir "später" fixen wollten. Ich weiß, wo der Zeitdruck zu Kompromissen geführt hat. Und genau da setze ich an. Das ersetzt kein externes Audit. Aber es sorgt dafür, dass ein externer Auditor seine Zeit mit echten Architekturproblemen verbringt -- und nicht mit Low-Hanging Fruit, die ich längst hätte finden können.

Fix Implementation, die architektonisch Sinn ergibt

Hier schließt sich der Kreis. Wenn ich eine Vulnerability finde, schlage ich nicht einfach einen Patch vor. Ich implementiere den Fix. Und weil ich die Architektur kenne, ist der Fix kein Pflaster, sondern eine Lösung. Zurück zum JWT-Beispiel vom Anfang: Ein Pentester hätte gesagt: "Validiert die Signatur." Ich habe stattdessen die gesamte Auth-Middleware refactored:

Asymmetrische Signatur (RS256 statt HS256)
Key Rotation über einen zentralen Key Store
Token Validation als Middleware, nicht pro Endpoint
Refresh Token Flow mit Device Binding
Audit Logging für alle Auth-Events

Das ist der Unterschied zwischen "Lücke geschlossen" und "Problem gelöst."

Der Business Case: Warum das Geld spart

Jetzt wird es pragmatisch. Denn am Ende entscheidet nicht die Technik, sondern der Business Case.

Die Kosten-Kurve

Die Kosten, eine Sicherheitslücke zu fixen, steigen exponentiell mit jeder Phase: | Phase | Relative Kosten | Beispiel | |-------|-----------------|----------| | Design | 1x | Threat Model anpassen | | Entwicklung | 5x | Code Review + Refactoring | | Testing/QA | 15x | Pentest + Fix + Re-Test | | Produktion | 60x | Incident Response + Patch + Audit | | Nach Breach | 200x+ | Forensik + Legal + Reputation | Diese Zahlen sind nicht von mir erfunden. IBM publiziert seit Jahren den "Cost of a Data Breach Report", und die Tendenz ist eindeutig: Je später du es findest, desto teurer wird es. Ein Full-Cycle Security Engineer arbeitet primär in den ersten beiden Phasen. Das heißt nicht, dass danach nichts mehr passiert. Aber die großen, teuren Architekturprobleme werden früh erwischt.

Kein Translation Loss

Wenn ein Pentester einem Entwickler einen Finding erklärt, geht Information verloren. Der Pentester denkt in Angriffsvektoren, der Entwickler in Code-Strukturen. Beide haben recht, aber sie reden aneinander vorbei. Wenn eine Person beides macht, fällt diese Übersetzungsschicht weg. Ich muss niemandem erklären, warum eine IDOR gefährlich ist. Ich muss niemandem erklären, wie das ORM funktioniert. Ich sehe das Problem, verstehe den Kontext und implementiere die Lösung. Ein Kommunikationsweg weniger, der schief gehen kann.

Ein echtes Beispiel

In einem API-Projekt habe ich während des Code Reviews eine JWT-Konfiguration gefunden, die kein automatisierter Scanner der Welt geflagged hätte: Der Token wurde korrekt signiert und validiert. HTTPS war aktiv. Die Expiry Time war gesetzt. Alles grün, oder? Das Problem: Der aud-Claim (Audience) wurde nicht geprüft. Das heißt: Ein Token, der für Service A ausgestellt wurde, war auch bei Service B gültig. In einer Microservice-Architektur ist das eine Lateral-Movement-Goldmine. Kein Scanner prüft das, weil die Signatur valide ist. Ein Pentester findet das nur, wenn er die Architektur versteht. Ein Entwickler sieht es nur, wenn er weiß, wonach er suchen muss. Ich habe es gefunden, weil ich beides bin.

Skills, die du brauchst (und wie ich dahin gekommen bin)

Ich will hier ehrlich sein: Dieser Weg ist nicht für jeden. Er erfordert, dass du bereit bist, in zwei Welten gleichzeitig zu leben.

Die technische Seite

Backend Engineering: Du musst produktionsreifen Code schreiben können. Nicht "ich kann ein Tutorial nachbauen", sondern "ich kann eine API mit Auth, Rate Limiting, Input Validation und Audit Logging von Grund auf designen und implementieren."
Netzwerk- und Infrastruktur-Verständnis: Du musst wissen, wie Pakete durch ein Netzwerk fließen. Wie DNS funktioniert. Was ein Reverse Proxy macht. Warum CORS existiert.
Offensive Security: Pentesting ist ein Handwerk. Tools wie Burp Suite, ffuf, Nuclei sind deine Werkzeuge. Aber wichtiger als die Tools ist die Methodik: Wie gehst du systematisch vor?

Ich habe mich auf diesem Weg durch den CPTS (Certified Penetration Testing Specialist) und den CWEE (Certified Web Exploitation Expert) von Hack The Box gearbeitet. Nicht weil Zertifikate alles sind -- sondern weil die Prüfungen dich zwingen, unter Druck real-world Systeme anzugreifen und zu dokumentieren. Das ist eine andere Liga als Multiple Choice.

Der Mindset-Shift

Die technischen Skills sind lernbar. Der schwierige Teil ist der Perspektivwechsel. Als Entwickler denkst du: "Wie bringe ich das zum Laufen?" Als Angreifer denkst du: "Wie bringe ich das zum Brechen?" Du musst lernen, deinen eigenen Code mit Misstrauen zu betrachten. Jede Assumption zu hinterfragen. Jede Abkürzung als potentielle Schwachstelle zu sehen. Das ist am Anfang unbequem, weil du deinen eigenen Code kritisierst. Aber es macht dich langfristig zu einem besseren Entwickler -- und einem besseren Sicherheitsexperten. Ein paar Fragen, die ich mir bei jedem Feature stelle:

Was passiert, wenn der Input nicht das ist, was ich erwarte?
Was passiert, wenn der User kein User ist, sondern ein Angreifer?
Was passiert, wenn dieser Service kompromittiert wird -- was kann der Angreifer von hier aus erreichen?
Was passiert, wenn die Datenbank geleakt wird -- welche Daten sind im Klartext?

Wenn du anfängst, so zu denken, findest du Bugs, bevor sie entstehen.

Mein Stack, mein Ansatz

Damit du ein konkretes Bild bekommst, hier ein typisches Engagement bei mir:

Kick-off: Architektur-Review, Threat Model Workshop mit dem Team. Keine PowerPoints, sondern Whiteboard und ehrliche Gespräche über Risiken.
Design Phase: Security Requirements definieren, Auth-Strategie festlegen, Datenfluss-Analyse.
Implementation: Ich baue mit oder reviewe den Code parallel zur Entwicklung. Nicht nach Sprint 10, sondern ab Sprint 1.
Testing: Manuelles Pentesting der Applikation, fokussiert auf Business Logic und Auth Bypass. Automatisierte Scans als Baseline, nicht als Ersatz.
Hardening: Infrastruktur-Review, CI/CD-Pipeline Security, Secrets Management, Monitoring.
Handoff: Dokumentation, Runbooks, Team-Schulung. Mein Ziel ist, dass das Team nach meinem Engagement selbstständig weitermachen kann.

Schluss: Code, der sich selbst verteidigt

Ich baue Backends, die sich selbst verteidigen. Nicht weil sie magisch sicher sind -- das gibt es nicht. Sondern weil Security von Anfang an Teil der Architektur ist. Weil jede Komponente so gebaut ist, dass ein Angreifer an jeder Ecke auf Widerstand stößt. Defense in Depth, aber nicht als Buzzword, sondern als Architekturprinzip. Die Welt braucht nicht mehr Pentester, die Reports schreiben, die niemand versteht. Und sie braucht nicht mehr Entwickler, die Security als "Phase 2" behandeln. Sie braucht Leute, die beides können. Wenn du ein Projekt hast, das von Anfang an sicher gebaut werden soll -- oder ein bestehendes System, das ein ehrliches Assessment braucht, von jemandem, der auch die Fixes implementieren kann -- dann lass uns reden. Du erreichst mich unter kontakt@buengener-software.de oder auf LinkedIn.