Pentest-Freelancer oder Pentest-Team: Welche Zusammenarbeit passt?

Wann ein direkt eingebundener Pentest-Freelancer sinnvoll ist, wann ein spezialisiertes Team besser passt und welche Fragen vor der Beauftragung zählen.

Ein Penetrationstest ist keine austauschbare Prüfleistung. Zwei Angebote können denselben Scope nennen und trotzdem eine völlig andere Zusammenarbeit bedeuten. Entscheidend ist nicht nur, was getestet wird, sondern auch, wer während des Tests erreichbar ist, wie schnell Rückfragen beantwortet werden und ob für das Vorhaben eine Person oder ein belastbares Team gebraucht wird.

Für manche Projekte ist ein Pentest-Freelancer die passende Besetzung: eine klar verantwortliche Person, direkter Kontakt zur Entwicklung und wenig Übergabeaufwand. Andere Vorhaben benötigen mehrere Tester, verschiedene Fachrichtungen oder formale Lieferfähigkeit. Dann ist ein spezialisiertes Pentest-Unternehmen die bessere Struktur. Die ehrliche Antwort lautet deshalb nicht „Freelancer ist besser“ oder „Unternehmen ist sicherer“, sondern: Das Betriebsmodell muss zum Risiko und zur Organisation passen.

Ich arbeite selbst an der Schnittstelle. Entwicklungsnahe, klar begrenzte Aufgaben kann ich persönlich als Freelancer begleiten. Umfangreiche offensive Sicherheitsprojekte werden über DSecured umgesetzt. So lässt sich die Form nach dem tatsächlichen Bedarf wählen, ohne aus jeder Anfrage künstlich dasselbe Produkt zu machen.

Was bei einem Pentest tatsächlich eingekauft wird

Ein guter Pentest besteht nicht nur aus Teststunden. Vor dem ersten Request müssen Ziele, Systeme, Rollen und Grenzen verstanden werden. Während der Prüfung entstehen Hypothesen, Belege und Rückfragen. Danach müssen Findings so erklärt werden, dass Entwicklung und Verantwortliche handeln können. Häufig schließt sich ein Nachtest an.

Damit kauft ein Auftraggeber mindestens fünf Dinge ein:

  • eine unabhängige Angreiferperspektive,
  • konzentrierte Zeit für manuelle Prüfungen,
  • sichere Kommunikation bei kritischen Funden,
  • nachvollziehbare technische Dokumentation,
  • und Verfügbarkeit für Einordnung und Nachtest.

Die Organisationsform ist nur ein Mittel, diese Zusagen zuverlässig zu erfüllen. Ein einzelner Spezialist kann bei engem Scope sehr effizient sein. Er darf aber keine Kapazität vorspiegeln, die nur ein Team leisten kann. Umgekehrt hilft ein großer Prozess wenig, wenn ein kleines Produktteam eigentlich eine erfahrene Person direkt neben seinen Entwicklern benötigt.

Wann ein Pentest-Freelancer gut passt

Ein Freelancer ist besonders sinnvoll, wenn das Zielsystem klar abgegrenzt ist und die Zusammenarbeit fachlich eng werden soll. Das kann eine Webanwendung, eine API, ein kritischer Workflow oder die Sicherheitsprüfung einer konkreten Änderung sein. Der Vorteil liegt nicht in weniger Sorgfalt, sondern in einer kurzen Verbindung zwischen den Menschen, die testen und denen, die das Produkt kennen.

Typische Signale für dieses Modell sind:

  • Das Entwicklungsteam möchte während des Tests Rückfragen direkt beantworten.
  • Geschäftslogik, Rollen oder Mandantengrenzen benötigen viel Produktkontext.
  • Ein Release oder eine einzelne Risikofläche soll gezielt geprüft werden.
  • Findings sollen gemeinsam mit den Entwicklern technisch eingeordnet werden.
  • Dieselbe Person soll beim Retest den ursprünglichen Angriffspfad erneut bewerten.

Gerade bei individueller Software ist Kontext wertvoll. Ein Tester muss verstehen, welche Zustandswechsel erlaubt sind, welche Daten einem Mandanten gehören und welche Aktionen nur in einer bestimmten Reihenfolge möglich sein dürfen. Direkter Austausch beschleunigt dieses Verständnis. Er ersetzt jedoch nie die unabhängige Prüfung: Die Anwendung wird weiterhin gegen ihre Sicherheitsannahmen getestet, nicht nur gegen die Erwartungen des Teams.

Wann ein spezialisiertes Team die richtige Wahl ist

Ein Unternehmen oder ein eingespieltes Pentest-Team ist sinnvoll, sobald der Auftrag mehrere parallele Kompetenzen, größere Kapazität oder organisatorische Redundanz erfordert. Beispiele sind kombinierte Prüfungen von Anwendungen und Infrastruktur, mehrere Zielsysteme mit engem Termin, Red-Teaming-Szenarien oder Beschaffungsprozesse mit umfassenden formalen Anforderungen.

Auch Kontinuität kann ein Grund sein. Wenn ein Test zwingend zu einem festen Termin mit mehreren Prüfern stattfinden muss, darf das Projekt nicht von der Verfügbarkeit einer einzelnen Person abhängen. Ein Team kann außerdem Spezialwissen gezielt kombinieren und Vier-Augen-Prüfungen organisatorisch abbilden.

Für diese Fälle ist DSecured nicht einfach eine größere Version meiner Freelancer-Arbeit. Es ist das passende Liefermodell für breitere offensive Sicherheitsprojekte: mit Teamstruktur, abgestimmtem Prozess und zusätzlichen Leistungsbereichen. Auf damianstrobel.de bleibt der Fokus dagegen auf meiner persönlichen, entwicklungsnahen Mitarbeit.

Fünf Fragen, die vor der Entscheidung helfen

Wie breit ist der Scope?

Eine Anwendung mit zwei klar definierten Rollen ist etwas anderes als eine Plattform mit Web-Frontend, mobilen Clients, zahlreichen APIs, Cloud-Infrastruktur und mehreren Identitätssystemen. Der Scope sollte in prüfbare Bestandteile zerlegt werden. Erst dann ist erkennbar, ob eine Person die gewünschte Tiefe im verfügbaren Zeitraum seriös leisten kann.

Wie viel Produktwissen ist nötig?

Je stärker die Sicherheit von fachlichen Regeln abhängt, desto wichtiger wird der Kontakt zum Produktteam. Bei einem Standard-Perimeter kann ein stark formalisierter Ablauf gut funktionieren. Bei komplexen Freigaben, Abrechnungen oder Mandantengrenzen ist eine direkte, wiederholte Abstimmung oft wertvoller.

Welche Verfügbarkeit wird erwartet?

„Test im September“ reicht als Planung nicht. Relevant sind konkrete Zeitfenster, Abhängigkeiten und Reaktionszeiten. Muss ein kritischer Fund sofort gemeinsam untersucht werden? Ist ein Entwickler für Rückfragen erreichbar? Wann sollen Fixes nachgetestet werden? Ein realistisches Modell benennt diese Verfügbarkeit vor der Beauftragung.

Welche Unabhängigkeit verlangt der Zweck?

Ein entwicklungsbegleitender Test und eine formale Prüfanforderung können unterschiedliche Erwartungen an Trennung, Freigabe und Dokumentation haben. Wer einen Nachweis für Kunden, Versicherer oder interne Governance braucht, sollte dessen Anforderungen vorab klären. Die Bezeichnung „Pentest“ allein garantiert nicht, dass jedes gewünschte Nachweisformat erfüllt wird.

Was passiert nach dem Bericht?

Ein Bericht ist ein Zwischenprodukt. Gute Zusammenarbeit endet erst, wenn die Empfänger Angriffspfad und Priorität verstehen und ein Nachtest die Wirksamkeit der Korrektur bewertet hat. Deshalb sollte schon im Angebot stehen, wie Rückfragen, Fix-Begleitung und Retests organisiert sind.

Red Flags unabhängig von der Organisationsform

Ob Freelancer oder Unternehmen: Einige Warnsignale bleiben gleich. Ein Angebot ist problematisch, wenn Prüftiefe und Zeitbudget nicht zusammenpassen, ausschließlich Scanner-Ausgaben versprochen werden oder niemand erklären kann, wie kritische Ergebnisse kommuniziert werden. Auch ein unklarer Scope ist kein Zeichen von Flexibilität. Er schafft Streit darüber, welche Systeme, Rollen und Testarten tatsächlich enthalten waren.

Sinnvolle Fragen an jeden Anbieter sind:

  • Wer führt den Test konkret durch?
  • Wie wird manuelle Prüfung von automatisierter Unterstützung getrennt?
  • Welche Zugänge und Testdaten werden benötigt?
  • Wie werden kritische Findings während des Tests gemeldet?
  • Was enthält der Bericht und ist ein Retest vereinbart?
  • Wer beantwortet technische Rückfragen nach der Übergabe?

Orientierung für Scope und Prüfinhalte bietet beispielsweise der OWASP Web Security Testing Guide. Er ersetzt kein projektspezifisches Testkonzept, macht aber sichtbar, dass ein belastbarer Web-Pentest weit mehr als einen Scan umfasst.

Zwei Modelle können sich ergänzen

Die Entscheidung muss nicht dauerhaft oder exklusiv sein. Ein Freelancer kann ein Produktteam über mehrere Releases hinweg begleiten und klar abgegrenzte Funktionen prüfen. Für eine größere jährliche Gesamtprüfung, Infrastruktur oder ein Red-Teaming-Projekt kann parallel ein spezialisiertes Team beauftragt werden. Umgekehrt können aus einem Unternehmensprojekt konkrete entwicklungsnahe Aufgaben entstehen, bei denen direkte persönliche Mitarbeit sinnvoll ist.

Wichtig ist eine saubere Rollenverteilung. Wer Code mitentwickelt, sollte nicht stillschweigend die einzige unabhängige Abnahme derselben Änderung übernehmen. Wer den Gesamtbericht verantwortet, muss wissen, welche Teilprüfungen wann und unter welchen Bedingungen stattfanden. Transparenz ist hier wichtiger als ein möglichst einfaches Etikett.

Wie ich Anfragen einordne

Bei einer ersten Anfrage brauche ich keine perfekte Leistungsbeschreibung. Hilfreich sind der Anwendungstyp, die wichtigsten Rollen, der Anlass, ein grober Termin und die Frage, was nach dem Test entschieden werden soll. Daraus lässt sich ein sinnvoller nächster Schritt ableiten.

Passt der Auftrag zu einer persönlichen, entwicklungsnahen Zusammenarbeit, kann ich Scope, Testfenster und Ergebnis gemeinsam mit dem Team konkretisieren. Erfordert er mehrere Disziplinen, parallele Kapazität oder einen größeren organisatorischen Rahmen, ist die Weiterleitung zu DSecured keine Absage, sondern die fachlich richtige Besetzung.

Fazit

Ein Pentest-Freelancer ist kein verkleinertes Pentest-Unternehmen, und ein Pentest-Unternehmen ist nicht automatisch die bessere Antwort auf jeden Scope. Die Wahl hängt von Prüfumfang, benötigtem Kontext, Terminrisiko, formalen Anforderungen und der gewünschten Zusammenarbeit nach dem Bericht ab.

Für klar abgegrenzte Web-, API- und Laravel-Themen mit engem Draht zur Entwicklung biete ich eine persönliche Zusammenarbeit als Pentest-Freelancer an. Wenn das Vorhaben ein breiteres Team oder zusätzliche offensive Disziplinen benötigt, wird es passend über DSecured strukturiert. Wer den Anwendungskontext und das gewünschte Ergebnis kurz beschreibt, bekommt deshalb zuerst eine ehrliche Einordnung – und erst danach einen Vorschlag für das Liefermodell.

Eine ähnliche Entscheidung steht in Ihrem Projekt an?

Schildern Sie den Kontext. Ich ordne die technischen Optionen, Risiken und einen sinnvollen nächsten Schritt ein.

Projektfrage besprechen ↗