# Pentest, bug bounty vagy sebezhetőségi szkennelés? A megfelelő vizsgálati eljárás kiválasztása

> Pentest vagy sebezhetőségi szkennelés, esetleg bug bounty? Mit talál az egyes vizsgálati eljárás, hol vak, és milyen sorrend értelmes a kkv-knak.

Forrás: https://phpsos.de/hu/blog/pentest-bugbounty-scan/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A pentest vagy a sebezhetőségi szkennelés nem vagy-vagy kérdés, hanem a sorrend kérdése. A sebezhetőségi szkennelés automatizáltan találja meg az ismert réseket és hibás konfigurációkat, gyorsan és olcsón, de téves riasztásokkal és vak foltokkal. A penetrációs teszt célzottan vizsgálja, mit érhetne el valójában egy támadó. A bug bounty program megnyitja a vizsgálatot külső kutatók számára, és csak akkor éri meg, ha a szkennelések és a pentestek rutinná váltak. A legtöbb kkv-nak a sorrend: rendszeresen szkennelni, kijavítani a megállapításokat, célzottan teszteltetni, sebezhetőségi bejelentő pontot felállítani.

## Miért teszik fel újra a kérdést a PHP2Shell után

Aki a PHP2Shell után egy online szkennerrel vizsgálja a weboldalát, zavaros eredményeket kaphat. Az egyik szkenner kritikus rést jelent, noha a tárhelyszolgáltató megerősítette a javítást. Egy másik semmit sem jelent, noha a szerver még régi PHP-verziót használ, mert a verziókijelzés el van rejtve.

Az ok a működésmódban van. Sok szkenner a sebezhetőséget a megjelenített verzióból vezeti le. A disztribúciók azonban a verziószám módosítása nélkül telepítenek backportokat; a beszámolók szerint például az Ubuntu 24.04 a frissítés után is 8.3.6-ot mutat. Hogy ez miért van így, azt a [Miért mutatja a php -v ugyanazt a számot a frissítés után](https://phpsos.de/hu/blog/php-v-zeigt-alte-nummer/) magyarázza el. A megbízható igazolást a csomag changelogja adja, lásd [PHP-verzió és javítási állapot helyes ellenőrzése](https://phpsos.de/hu/php2shell/php-version-pruefen/).

Ez nem érv a szkennerek ellen, hanem amellett, hogy ismerjük a határaikat, és más eljárásokkal kombináljuk őket.

## Pentest vagy sebezhetőségi szkennelés: a három eljárás összehasonlítása

| Szempont | Sebezhetőségi szkennelés | Penetrációs teszt | Bug bounty |
|---|---|---|---|
| Ki vizsgál? | Automatizált eszköz | Megbízott szakemberek | Külső kutatók, gyakran egy platformon keresztül |
| Mit talál? | Ismert réseket, elavult verziókat, hibás konfigurációkat | Kihasználható sebezhetőségeket, logikai hibákat, láncolásokat | Amit a kutatók találnak és jelentenek, gyakran szokatlant |
| Mélység | Széles, de felszínes | Mély a megállapodott terjedelemben | Változó, a résztvevőktől függ |
| Téves riasztások | Gyakoriak | Ritkák, a megállapításokat igazolják | Sok bejelentés, amelyeket értékelni kell |
| Tervezhetőség | Magas, tetszés szerint megismételhető | Magas, rögzített időszak és terjedelem | Alacsony, a bejelentések folyamatosan érkeznek |
| Feltételek a vállalkozásban | Valaki, aki értékeli az eredményeket | Egyeztetett terjedelem, tesztkörnyezet vagy karbantartási ablak | Érett folyamat az értékelésre, javításra és jutalmazásra |
| Tipikus alkalmazás | Folyamatosan, például havonta vagy módosítások után | Indítás előtt, nagyobb módosítások után, rendszeresen | Kiegészítésként érett, kitett alkalmazásoknál |

Egyik eljárás sem pótolja a többit. A szkennelés rövid idő alatt sokat mutat, a pentest megmutatja, mi számít valójában, a bug bounty pedig megtalálja azt, amire senki sem gondolt.

A szkennereknél emellett érdemes másodszor is megnézni a szkennelés fajtáját. A kívülről végzett szkennelés csak azt látja, amit minden látogató, és a verziókat gyakran a szerver válaszaiból kell kitalálnia. A hitelesített szkennelés, amelynél az eszköz saját hozzáférési adatokkal kiolvassa a szerveren telepített csomagokat, lényegesen megbízhatóbb eredményeket ad, éppen a PHP tényleges csomagállapotánál. Feltételezi azonban, hogy ehhez korlátozott hozzáférést állít be, és jól védi. A saját PHP-alkalmazások függőségeihez viszont külön ellenőrző eszközök vannak, például a `composer audit` a Composer csomagokhoz.

## A kkv-knak értelmes sorrend

1. **Leltár és szkennelés:** Először tudni, mely weboldalak és szerverek vannak, azután rendszeresen szkennelni. A megállapításokat nem ellenőrzés nélkül átvenni, hanem értékelni.
2. **Az alapok kijavítása:** Az elavult szoftvert, a hiányzó frissítéseket és a nyilvánvaló hibás konfigurációkat megszüntetni. Egy pentestet javítatlan rendszerekre kiírni a költségvetés elpazarlása.
3. **Célzott penetrációs teszt:** A legfontosabb alkalmazásokra, például webshopra, ügyfélportálra vagy interfészekre, egyértelműen megállapodott terjedelemmel és utóteszttel.
4. **Kódellenőrzés saját fejlesztéseknél:** Aki saját PHP-alkalmazásokat üzemeltet, a tesztet a forráskód átvizsgálásával egészíti ki. Hogyan zajlik ez, azt a [Biztonsági kódellenőrzés PHP-projektekhez](https://phpsos.de/hu/blog/sicherheits-code-review-php/) írja le.
5. **Sebezhetőségi bejelentő pont:** Egy irányelv arról, hogyan jelenthetnek külsők réseket, és egy RFC 9116 szerinti security.txt fájl a `/.well-known/security.txt` helyen kapcsolattartóval és lejárati dátummal.
6. **Bug bounty, ha az alapok megvannak:** Csak ha a bejelentéseket megbízhatóan értékelik, és a réseket gyorsan kijavítják.

Hogy ebből tartós folyamat legyen, érdemes megnézni a [Sebezhetőségkezelés a közép- és kisvállalkozásoknál](https://phpsos.de/hu/blog/schwachstellenmanagement-mittelstand/) cikket.

## Amit egyik eljárás sem tud

Egyetlen vizsgálati eljárás sem bizonyítja, hogy egy rendszer biztonságos. Csak azt mutatja meg, mit találtak egy időpontban bizonyos módszerekkel. Egy tavaszi tiszta pentest-jelentés semmit sem mond egy olyan résről, mint a PHP2Shell, amely októberben válik ismertté.

Éppígy sem a szkennelés, sem a pentest nem válaszolja meg azt a kérdést, hogy egy szerver már kompromittált-e. Ehhez a rendszeren magán végzett nyomkeresés kell: folyamatok, fájlok, cron-feladatok, fiókok, kapcsolatok. Ez saját feladat saját módszerekkel.

> **Fontos:**
> Csak olyan rendszereket vizsgáltasson, amelyekhez jogosult, és hosztolt rendszereknél előtte tisztázza a szolgáltató szabályait. Egy penetrációs teszthez írásbeli megbízás kell a terjedelemmel, az időszakkal és a kapcsolattartókkal.

## Mikor nincs szüksége külső tesztre

Egy egyszerű cégweboldalhoz, érzékeny adatokat tartalmazó űrlapok nélkül, olyan tárhelyszolgáltatónál, amely megbízhatóan telepíti a frissítéseket, gyakran elég egy rendszeres szkennelés az eredmények kritikus értékelésével. Egy penetrációs teszt itt többnyire aránytalan lenne. Fontosabb az aktuális szoftver, az erős hozzáférések és a mentések.

Egy külső teszt webshopoknál, portáloknál, saját fejlesztéseknél, belső rendszerekhez vezető interfészeknél és mindenütt megéri, ahol az ügyfelek vagy a szabványok független igazolást követelnek.

## Hogyan segít konkrétan a PHP SOS?

- Rendszeres szkenneléseket állítunk be, és értékeljük az eredményeket, a backportok okozta téves riasztásokat is.
- Segítünk kijavítani az alapokat, mielőtt pénz folyna egy pentestbe.
- Specializált partnerekkel közösen [biztonsági auditokat és penetrációs teszteket](https://phpsos.de/hu/leistungen/sicherheitsaudit-penetrationstest/) végzünk egyeztetett terjedelemmel és utóteszttel.
- Támogatjuk a sebezhetőségi bejelentő pont és egy security.txt felállítását.

## Összegzés

A szkennelés, a pentest és a bug bounty fokozatok, nem versenytársak. Aki rendszeres szkenneléssel kezdi, kijavítja az alapokat, majd célzottan teszteltet, a költségvetéséért a legtöbb biztonságot kapja. A bug bounty a kűr azoknak a szervezeteknek, amelyeknél a kötelező már rendben van.


## Gyakori kérdések

**Mi a különbség a pentest és a sebezhetőségi szkennelés között?**  
A sebezhetőségi szkennelés automatizáltan vizsgálja, hogy felismerhetők-e ismert rések vagy hibás konfigurációk. A penetrációs teszt továbbmegy: szakemberek egy megállapodott keretben megpróbálják a sebezhetőségeket ténylegesen kihasználni és láncolni, és értékelik a következményeket.

**Megállapítja egy szkenner, hogy a szerverem javítva van-e a PHP2Shell ellen?**  
Csak korlátozottan. Sok szkenner a megjelenített PHP-verziót olvassa ki. Ha a disztribúció backportot telepít, a szám gyakran ugyanaz marad, és a szkenner olyan rést jelent, amely rég le van zárva. Fordítva, új szám jelenhet meg, miközben régi folyamatok még futnak.

**Való egy bug bounty program kis vállalkozásoknak?**  
Többnyire még nem. A bug bounty feltételezi, hogy a bejelentéseket gyorsan értékelik, és a réseket gyorsan kijavítják. Jó kezdet a sebezhetőségek bejelentésére szolgáló egyszerű irányelv egy security.txt fájllal.

**Szkennelhetem magam a weboldalamat szkennerrel?**  
A saját rendszereit általában igen, ha jogosult rá. Ha a weboldal tárhelyszolgáltatónál van, előtte tisztázza, hogy a szkennelések engedélyezettek vagy bejelentendők-e. Idegen rendszereket csak az üzemeltető írásbeli engedélyével vizsgáljon.

**Milyen gyakran legyen pentest?**  
Szigorú szabály nincs. Szokásos egy teszt egy új alkalmazás indítása előtt, nagyobb módosítások után és rendszeres időközönként, amelyeket az Ön kockázata és adott esetben az ügyfelek vagy a szabványok előírásai határoznak meg.

## Források

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