# Pentest, Bug Bounty oder Schwachstellenscan? Das passende Prüfverfahren wählen

> Pentest oder Schwachstellenscan, oder gleich Bug Bounty? Was jedes Prüfverfahren findet, wo es blind ist und in welcher Reihenfolge es für KMU Sinn ergibt.

Quelle: https://phpsos.de/blog/pentest-bugbounty-scan/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Pentest oder Schwachstellenscan ist keine Entweder-oder-Frage, sondern eine Frage der Reihenfolge. Ein Schwachstellenscan findet automatisiert bekannte Lücken und Fehlkonfigurationen, schnell und günstig, aber mit Fehlalarmen und blinden Flecken. Ein Penetrationstest prüft gezielt, was ein Angreifer tatsächlich erreichen könnte. Ein Bug-Bounty-Programm öffnet die Prüfung für externe Forschende und lohnt sich erst, wenn Scans und Pentests zur Routine gehören. Für die meisten KMU ist die Reihenfolge: regelmäßig scannen, Befunde beheben, gezielt testen lassen, eine Meldestelle für Schwachstellen einrichten.

## Warum die Frage nach PHP2Shell neu gestellt wird

Wer nach PHP2Shell seine Website mit einem Online-Scanner prüft, kann verwirrende Ergebnisse erhalten. Ein Scanner meldet womöglich eine kritische Lücke, obwohl der Hoster den Patch bestätigt hat. Ein anderer meldet nichts, obwohl der Server noch eine alte PHP-Version nutzt, weil die Versionsangabe ausgeblendet ist.

Der Grund liegt in der Arbeitsweise. Viele Scanner leiten die Verwundbarkeit aus der angezeigten Version ab. Distributionen spielen aber Backports ein, ohne die Versionsnummer zu ändern; laut Berichten zeigt etwa Ubuntu 24.04 nach dem Update weiter 8.3.6. Warum das so ist, erklärt [Warum php -v nach dem Update dieselbe Nummer zeigt](https://phpsos.de/blog/php-v-zeigt-alte-nummer/). Den verlässlichen Nachweis liefert der Paket-Changelog, siehe [PHP-Version und Patchstand richtig prüfen](https://phpsos.de/php2shell/php-version-pruefen/).

Das ist kein Argument gegen Scanner, sondern eines dafür, ihre Grenzen zu kennen und sie mit anderen Verfahren zu kombinieren.

## Pentest oder Schwachstellenscan: die drei Verfahren im Vergleich

| Kriterium | Schwachstellenscan | Penetrationstest | Bug Bounty |
|---|---|---|---|
| Wer prüft? | Automatisiertes Werkzeug | Beauftragte Fachleute | Externe Forschende, oft über eine Plattform |
| Was wird gefunden? | Bekannte Lücken, veraltete Versionen, Fehlkonfigurationen | Ausnutzbare Schwachstellen, Logikfehler, Verkettungen | Was Forschende finden und melden, oft Ungewöhnliches |
| Tiefe | Breit, aber oberflächlich | Tief im vereinbarten Umfang | Unterschiedlich, abhängig von Teilnehmenden |
| Fehlalarme | Häufig | Selten, Befunde werden belegt | Viele Meldungen, die bewertet werden müssen |
| Planbarkeit | Hoch, beliebig wiederholbar | Hoch, fester Zeitraum und Umfang | Gering, Meldungen kommen laufend |
| Voraussetzungen im Unternehmen | Jemand, der Ergebnisse bewertet | Abgestimmter Umfang, Testumgebung oder Wartungsfenster | Reifer Prozess für Bewertung, Behebung und Belohnung |
| Typischer Einsatz | Laufend, etwa monatlich oder nach Änderungen | Vor Start, nach größeren Änderungen, regelmäßig | Ergänzend bei reifen, exponierten Anwendungen |

Keines der Verfahren ersetzt die anderen. Der Scan zeigt viel in kurzer Zeit, der Pentest zeigt, was wirklich zählt, und Bug Bounty findet, woran niemand gedacht hat.

Bei Scannern lohnt außerdem ein zweiter Blick auf die Art des Scans. Ein Scan von außen sieht nur, was jeder Besucher sieht, und muss Versionen oft aus Antworten des Servers erraten. Ein authentifizierter Scan, bei dem das Werkzeug mit eigenen Zugangsdaten die installierten Pakete auf dem Server ausliest, liefert deutlich verlässlichere Ergebnisse, gerade beim tatsächlichen Paketstand von PHP. Er setzt aber voraus, dass Sie dafür einen eingeschränkten Zugang einrichten und gut schützen. Für die Abhängigkeiten eigener PHP-Anwendungen gibt es wiederum eigene Prüfwerkzeuge, etwa `composer audit` für Pakete aus Composer.

## Die sinnvolle Reihenfolge für KMU

1. **Inventar und Scan:** Erst wissen, welche Websites und Server es gibt, dann regelmäßig scannen. Befunde nicht ungeprüft übernehmen, sondern bewerten.
2. **Grundlagen beheben:** Veraltete Software, fehlende Updates und offensichtliche Fehlkonfigurationen beseitigen. Einen Pentest auf ungepatchte Systeme anzusetzen, verschwendet Budget.
3. **Gezielter Penetrationstest:** Für die wichtigsten Anwendungen, etwa Shop, Kundenportal oder Schnittstellen, mit klar vereinbartem Umfang und Nachtest.
4. **Code-Prüfung bei Eigenentwicklungen:** Wer eigene PHP-Anwendungen betreibt, ergänzt den Test durch eine Durchsicht des Quellcodes. Wie das abläuft, beschreibt [Sicherheits-Code-Review für PHP-Projekte](https://phpsos.de/blog/sicherheits-code-review-php/).
5. **Meldestelle für Schwachstellen:** Eine Richtlinie, wie Externe Lücken melden können, und eine security.txt-Datei nach RFC 9116 unter `/.well-known/security.txt` mit Kontakt und Ablaufdatum.
6. **Bug Bounty, wenn die Grundlagen sitzen:** Erst wenn Meldungen zuverlässig bewertet und Lücken zügig behoben werden.

Damit daraus ein dauerhafter Ablauf wird, lohnt der Blick auf [Schwachstellenmanagement für den Mittelstand](https://phpsos.de/blog/schwachstellenmanagement-mittelstand/).

## Was keines der Verfahren leistet

Kein Prüfverfahren beweist, dass ein System sicher ist. Es zeigt nur, was zu einem Zeitpunkt mit bestimmten Methoden gefunden wurde. Ein sauberer Pentest-Bericht vom Frühjahr sagt nichts über eine Lücke wie PHP2Shell, die im Oktober bekannt wird.

Ebenso wenig beantworten Scan oder Pentest die Frage, ob ein Server bereits kompromittiert ist. Dafür braucht es eine Spurensuche auf dem System selbst: Prozesse, Dateien, Cronjobs, Konten, Verbindungen. Das ist eine eigene Aufgabe mit eigenen Methoden.

> **Wichtig:**
> Lassen Sie nur Systeme prüfen, für die Sie berechtigt sind, und klären Sie bei gehosteten Systemen vorher die Regeln des Anbieters. Ein Penetrationstest braucht eine schriftliche Beauftragung mit Umfang, Zeitraum und Ansprechpartnern.

## Wann Sie keinen externen Test brauchen

Für eine einfache Firmenwebsite ohne Formulare mit sensiblen Daten, bei einem Hoster, der Updates zuverlässig einspielt, genügt oft ein regelmäßiger Scan mit kritischer Bewertung der Ergebnisse. Ein Penetrationstest wäre hier meist unverhältnismäßig. Wichtiger sind aktuelle Software, starke Zugänge und Backups.

Ein externer Test lohnt sich bei Shops, Portalen, Eigenentwicklungen, Schnittstellen zu internen Systemen und überall dort, wo Kunden oder Normen einen unabhängigen Nachweis verlangen.

## Wie hilft PHP SOS konkret?

- Wir richten regelmäßige Scans ein und bewerten die Ergebnisse, einschließlich der Fehlalarme durch Backports.
- Wir helfen, die Grundlagen zu beheben, bevor Geld in einen Pentest fließt.
- Gemeinsam mit spezialisierten Partnern führen wir [Sicherheitsaudits und Penetrationstests](https://phpsos.de/leistungen/sicherheitsaudit-penetrationstest/) mit abgestimmtem Umfang und Nachtest durch.
- Wir unterstützen beim Aufbau einer Meldestelle für Schwachstellen und einer security.txt.

## Fazit

Scan, Pentest und Bug Bounty sind Stufen, keine Konkurrenten. Wer mit regelmäßigen Scans beginnt, die Grundlagen behebt und dann gezielt testen lässt, bekommt für sein Budget die meiste Sicherheit. Bug Bounty ist die Kür für Organisationen, deren Pflicht schon sitzt.


## Häufige Fragen

**Was ist der Unterschied zwischen Pentest und Schwachstellenscan?**  
Ein Schwachstellenscan prüft automatisiert, ob bekannte Lücken oder Fehlkonfigurationen erkennbar sind. Ein Penetrationstest geht weiter: Fachleute versuchen in einem vereinbarten Rahmen, Schwachstellen tatsächlich auszunutzen und zu verketten, und bewerten die Folgen.

**Findet ein Scanner heraus, ob mein Server gegen PHP2Shell gepatcht ist?**  
Nur eingeschränkt. Viele Scanner lesen die angezeigte PHP-Version aus. Spielt die Distribution einen Backport ein, bleibt die Nummer oft gleich, und der Scanner meldet eine Lücke, die längst geschlossen ist. Umgekehrt kann eine neue Nummer angezeigt werden, während alte Prozesse noch laufen.

**Ist ein Bug-Bounty-Programm etwas für kleine Unternehmen?**  
Meist noch nicht. Bug Bounty setzt voraus, dass Meldungen schnell bewertet und Lücken zügig behoben werden. Ein guter Einstieg ist eine einfache Richtlinie zur Meldung von Schwachstellen mit einer security.txt-Datei.

**Darf ich meine Website selbst mit einem Scanner prüfen?**  
Ihre eigenen Systeme in der Regel ja, wenn Sie dazu berechtigt sind. Liegt die Website bei einem Hoster, klären Sie vorher, ob Scans erlaubt oder anzukündigen sind. Fremde Systeme prüfen Sie nur mit schriftlicher Erlaubnis des Betreibers.

**Wie oft sollte ein Pentest stattfinden?**  
Eine feste Regel gibt es nicht. Üblich ist ein Test vor dem Start einer neuen Anwendung, nach größeren Änderungen und in regelmäßigen Abständen, die Ihr Risiko und gegebenenfalls Vorgaben von Kunden oder Normen bestimmen.

## Quellen

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [security.txt (RFC 9116)](https://securitytxt.org/)
- [BSI](https://www.bsi.bund.de/)