Klassische Penetrationstests werden häufig wie eine externe Abnahme organisiert: Scope übergeben, einige Tage warten, Bericht erhalten. Das schafft eine klare Grenze, aber auch Informationsverlust. Tester müssen Produktlogik erraten, Entwickler erfahren erst am Ende, welche Annahmen angegriffen wurden, und kleine Rückfragen werden zu formalen Schleifen.
Für aktive Produktteams kann ein anderes Modell sinnvoll sein: Ein externer Pentester arbeitet für einen begrenzten Zeitraum direkt mit Product Ownern und Entwicklern. Er kennt die nächste Änderung, kann fachliche Risiken früh hinterfragen und testet die laufende Anwendung trotzdem aus unabhängiger Angreiferperspektive. Das ist weder eine dauerhafte Entwicklerrolle noch eine beiläufige Code-Review. Es ist entwicklungsnahes Pentesting mit klaren Grenzen.
Als Pentest-Freelancer kann ich genau diese kurze Verbindung anbieten. Der Wert entsteht dabei nicht durch möglichst viele Meetings, sondern durch rechtzeitigen Kontext, reproduzierbare Belege und einen direkten Weg vom Angriffspfad zum belastbaren Fix.
Was „im Produktteam“ bedeutet
Ein externer Pentester muss nicht jeden Daily-Termin besuchen oder Zugriff auf sämtliche internen Systeme erhalten. Eingebunden zu sein bedeutet vor allem, an den sicherheitsrelevanten Stellen nicht blind arbeiten zu müssen. Dazu gehören ein erreichbarer technischer Ansprechpartner, verständliche Architekturinformationen und ein Kanal für vertrauliche Findings.
Ein praktikables Setup kann so aussehen:
- Zu Beginn werden Ziel, Scope, Testumgebung und Stop-Regeln vereinbart.
- Das Team erklärt Rollen, kritische Daten und ungewöhnliche Geschäftslogik.
- Der Pentester formuliert Angriffshypothesen und prüft sie eigenständig.
- Kritische Befunde werden sofort, sonstige Befunde gesammelt kommuniziert.
- Entwickler können Verständnisfragen stellen, ohne das Ergebnis zu verhandeln.
- Fixes werden zuerst durch Regressionstests und anschließend durch einen unabhängigen Retest bestätigt.
Die Einbindung verkürzt den Informationsweg. Sie darf aber nicht dazu führen, dass nur noch bekannte Risiken oder die vom Team bevorzugten Testfälle geprüft werden. Ein Teil der Testzeit bleibt bewusst frei für Exploration, unerwartete Zustände und Kombinationen, die in Tickets oder Architekturdiagrammen nicht beschrieben sind.
Der richtige Zeitpunkt ist vor dem Release-Stau
Sicherheit wird teuer, wenn alle wichtigen Entscheidungen bereits feststehen. Ist eine zentrale Berechtigungslogik tief in Controller, Jobs und Exporte verteilt, lässt sie sich kurz vor dem Release nur schwer grundlegend korrigieren. Eine frühzeitige Angriffshypothese kann zeigen, welche Invarianten das Design erzwingen muss. Der eigentliche Pentest bleibt trotzdem wichtig, weil eine plausible Architektur noch keine korrekte Implementierung beweist.
Eine sinnvolle Staffelung besteht aus drei Berührungspunkten:
Risikogespräch vor der Umsetzung
Hier geht es nicht um vollständiges Threat Modeling. In 30 bis 60 Minuten lassen sich die wichtigsten Schutzobjekte, Rollen und unerwünschten Ergebnisse benennen. Beispielsweise: „Ein Nutzer darf niemals Daten eines anderen Mandanten exportieren“ oder „Eine Rückerstattung darf nicht durch Wiederholung doppelt ausgelöst werden.“ Solche Aussagen geben Entwicklung und späterem Test eine gemeinsame Referenz.
Fokussierter Test auf einer stabilen Umgebung
Sobald der Workflow vollständig nutzbar ist, beginnt die unabhängige Prüfung. Der Tester erhält definierte Rollen und Testdaten, versucht aber bewusst, die vorgesehenen Abläufe zu verlassen. Dabei werden nicht nur einzelne Endpunkte betrachtet. Relevant sind Zustandsübergänge, indirekte Zugriffe über Dateien oder Jobs und die Frage, ob eine schwächere Rolle Aktionen einer stärkeren Rolle auslösen kann.
Retest vor oder nach der Auslieferung
Der Retest wiederholt nicht lediglich denselben HTTP-Request. Er prüft den ursprünglichen Angriffspfad, naheliegende Varianten und mögliche Nebenwirkungen des Fixes. Bei einem zeitkritischen Release kann außerdem vereinbart werden, welche verbleibenden Risiken eine Freigabe verhindern und welche transparent nachgelagert werden dürfen.
Rollen sauber trennen
Nähe zum Team darf Unabhängigkeit nicht auflösen. Deshalb sollten drei Rollen sichtbar bleiben: Das Produktteam verantwortet Anforderungen und Umsetzung. Der Pentester verantwortet Testhypothesen, Belege und fachliche Bewertung. Eine benannte Person auf Auftraggeberseite entscheidet über Risikoakzeptanz und Release.
Diese Trennung verhindert typische Missverständnisse. Ein Entwickler kann eine alternative Lösung vorschlagen, aber nicht allein erklären, dass ein reproduzierbarer Angriff „in der Praxis niemandem auffällt“. Der Pentester kann eine technische Auswirkung beschreiben, entscheidet jedoch nicht über geschäftliche Akzeptanz. Und der Product Owner darf einen Befund bewusst zurückstellen, muss diese Entscheidung dann aber nachvollziehbar verantworten.
Besondere Aufmerksamkeit braucht die Situation, in der der externe Spezialist selbst Code verändert. Fix-Begleitung kann sehr wertvoll sein, doch der eigene Patch sollte nicht die einzige Grundlage für die Aussage „behoben“ sein. Mindestens ein reproduzierbarer Regressionstest und eine transparente zweite Prüfung des Angriffspfads schaffen hier die nötige Nachvollziehbarkeit.
Welche Informationen wirklich helfen
Ein riesiger Dokumentenordner verbessert den Pentest selten. Hilfreicher ist eine kleine, aktuelle Kontextmappe:
- Zielsysteme und ausdrücklich ausgeschlossene Systeme,
- Rollenmatrix mit erlaubten Kernaktionen,
- Testkonten für unterschiedliche Berechtigungsstufen,
- Datenflüsse zu externen Diensten,
- besonders schützenswerte Daten und Operationen,
- bekannte Einschränkungen der Testumgebung,
- Kontakt und Eskalationsweg für kritische Ergebnisse.
Quellcodezugriff kann die Testtiefe erhöhen, wenn er zum Auftrag passt. Er macht einen dynamischen Test nicht überflüssig. Code zeigt mögliche Pfade; das laufende System zeigt, welche Middleware, Konfiguration, Proxies, Jobs und Integrationen tatsächlich zusammenspielen. Der Nutzen entsteht aus der Verbindung beider Perspektiven.
Für Webanwendungen bietet der OWASP Application Security Verification Standard eine gemeinsame Sprache für Sicherheitsanforderungen. Er sollte risikoorientiert verwendet werden, nicht als mechanische Liste, die jede fachliche Besonderheit der Anwendung abbilden soll.
Kommunikation ohne Meeting-Overhead
Direkte Zusammenarbeit bedeutet nicht Dauerunterbrechung. Ein klarer Rhythmus reicht meist aus. Ein Kick-off klärt die Voraussetzungen. Kurze asynchrone Fragen werden in einem vereinbarten Kanal beantwortet. Kritische Findings haben einen eigenen Eskalationsweg. Ein Zwischenstand ist nur nötig, wenn sich Scope, Erreichbarkeit oder Risiko wesentlich ändern.
Jeder vorab gemeldete Befund sollte bereits belastbar genug sein, um Missverständnisse zu vermeiden:
- betroffene Funktion und Rolle,
- notwendige Voraussetzungen,
- reproduzierbare Schritte,
- beobachtete technische Auswirkung,
- erste Einschätzung zu Reichweite und Dringlichkeit.
Der vollständige Bericht ergänzt Ursache, Varianten, Behebungshinweise und Management-Kontext. So bleibt der schnelle Kanal handlungsfähig, ohne eine lose Sammlung von Chat-Nachrichten zum einzigen Projektergebnis zu machen.
Was dieses Modell nicht ersetzen soll
Ein eingebundener Pentester ist keine ausgelagerte Sicherheitsabteilung. Er übernimmt nicht automatisch Asset-Inventar, Patch-Management, Monitoring, Incident Response oder die Verantwortung für sichere Architektur. Solche Aufgaben können wichtig sein, benötigen aber eigene Zuständigkeiten.
Auch eine umfassende unabhängige Prüfung kann weiterhin sinnvoll sein. Wenn viele Systeme parallel betrachtet werden, mehrere Spezialgebiete nötig sind oder formale Anforderungen ein größeres Liefermodell verlangen, gehört der Auftrag in ein Team. DSecured ist dafür die separate Unternehmensstruktur. Die persönliche Freelancer-Zusammenarbeit konzentriert sich auf Situationen, in denen direkter Produktkontext und kurze technische Wege den größten Nutzen bringen.
Ein kleines Startformat
Teams müssen nicht sofort ein langfristiges Modell vereinbaren. Ein klar begrenzter Einstieg kann aus einem Risikogespräch, zwei bis fünf Testtagen für einen relevanten Workflow und einem Retest-Fenster bestehen. Das Ergebnis zeigt nicht nur mögliche Findings, sondern auch, ob Zugänge, Kommunikation und Dokumentation für beide Seiten funktionieren.
Vor dem Start sollten vier Ergebnisse definiert sein:
- Welcher Workflow oder Release ist Gegenstand der Prüfung?
- Welche Rollen und Daten stehen zur Verfügung?
- In welcher Form werden kritische und normale Befunde geliefert?
- Bis wann kann ein Fix nachgetestet werden?
Danach lässt sich sachlich entscheiden, ob weitere Release-Checks, ein größerer Pentest oder keine fortlaufende Begleitung nötig ist. Das Modell bleibt damit ein Werkzeug und wird nicht zum Selbstzweck.
Fazit
Ein Pentester direkt im Produktteam kann Sicherheitsfeedback deutlich näher an die technische Entscheidung bringen. Der Erfolg hängt aber von klaren Rollen ab: Kontext und Kommunikation werden geteilt, die Prüfung bleibt unabhängig, und Risikoentscheidungen verbleiben beim Auftraggeber.
Besonders gut funktioniert das bei individuellen Webanwendungen, APIs und Laravel-Systemen mit komplexen Rollen oder Geschäftsprozessen. Wenn ein kommender Release, ein kritischer Workflow oder eine neue Integration diesen Blick benötigt, können wir den Kontext in einem unverbindlichen Projektgespräch eingrenzen. Für breitere, multidisziplinäre Prüfungen bleibt DSecured der passende Weg; für die direkte Arbeit mit dem Entwicklungsteam stehe ich persönlich zur Verfügung.