# Pentest, bug bounty ali skeniranje ranljivosti? Izbira primernega postopka preverjanja

> Pentest ali skeniranje ranljivosti, ali kar bug bounty? Kaj najde vsak postopek preverjanja, kje je slep in v katerem vrstnem redu je smiseln za MSP.

Vir: https://phpsos.de/sl/blog/pentest-bugbounty-scan/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Pentest ali skeniranje ranljivosti ni vprašanje »ali–ali«, ampak vprašanje vrstnega reda. Skeniranje ranljivosti samodejno najde znane vrzeli in napačne konfiguracije, hitro in poceni, vendar z lažnimi alarmi in slepimi pegami. Penetracijski test ciljno preveri, kaj bi napadalec dejansko lahko dosegel. Program bug bounty odpre preverjanje zunanjim raziskovalcem in se splača šele, ko so skeniranja in pentesti rutina. Za večino MSP je vrstni red: redno skenirati, ugotovitve odpraviti, ciljno naročiti test, vzpostaviti prijavno točko za ranljivosti.

## Zakaj se vprašanje po PHP2Shell postavlja na novo

Kdor po PHP2Shell svojo spletno stran preveri s spletnim skenerjem, lahko dobi zmedene rezultate. Skener morda javi kritično vrzel, čeprav je ponudnik gostovanja popravek potrdil. Drug ne javi ničesar, čeprav strežnik še uporablja staro različico PHP, ker je podatek o različici skrit.

Razlog je v načinu dela. Mnogi skenerji ranljivost izpeljejo iz prikazane različice. Distribucije pa nameščajo prenose popravkov, ne da bi spremenile številko različice; po poročilih Ubuntu 24.04 po posodobitvi še naprej kaže 8.3.6. Zakaj je tako, pojasnjuje [Zakaj php -v po posodobitvi kaže isto številko](https://phpsos.de/sl/blog/php-v-zeigt-alte-nummer/). Zanesljivo dokazilo daje dnevnik sprememb paketa, glejte [Pravilno preverjanje različice PHP in stanja popravkov](https://phpsos.de/sl/php2shell/php-version-pruefen/).

To ni argument proti skenerjem, ampak za to, da poznamo njihove meje in jih združimo z drugimi postopki.

## Pentest ali skeniranje ranljivosti: trije postopki v primerjavi

| Merilo | Skeniranje ranljivosti | Penetracijski test | Bug bounty |
|---|---|---|---|
| Kdo preverja? | Samodejno orodje | Naročeni strokovnjaki | Zunanji raziskovalci, pogosto prek platforme |
| Kaj se najde? | Znane vrzeli, zastarele različice, napačne konfiguracije | Izkoristljive ranljivosti, logične napake, povezave | Kar raziskovalci najdejo in prijavijo, pogosto nenavadno |
| Globina | Široko, a površinsko | Globoko v dogovorjenem obsegu | Različno, odvisno od udeležencev |
| Lažni alarmi | Pogosti | Redki, ugotovitve so dokazane | Mnogo prijav, ki jih je treba oceniti |
| Načrtljivost | Visoka, poljubno ponovljivo | Visoka, fiksno obdobje in obseg | Majhna, prijave prihajajo sproti |
| Predpogoji v podjetju | Nekdo, ki ovrednoti rezultate | Usklajen obseg, testno okolje ali vzdrževalno okno | Zrel postopek za oceno, odpravo in nagrado |
| Značilna uporaba | Sproti, na primer mesečno ali po spremembah | Pred zagonom, po večjih spremembah, redno | Dopolnilno pri zrelih, izpostavljenih aplikacijah |

Nobeden od postopkov drugih ne nadomešča. Skeniranje v kratkem času pokaže veliko, pentest pokaže, kaj zares šteje, bug bounty pa najde, na kar nihče ni pomislil.

Pri skenerjih se splača še drugi pogled na vrsto skeniranja. Skeniranje od zunaj vidi samo to, kar vidi vsak obiskovalec, in mora različice pogosto ugibati iz odgovorov strežnika. Overjeno skeniranje, pri katerem orodje z lastnimi dostopnimi podatki prebere nameščene pakete na strežniku, daje občutno zanesljivejše rezultate, zlasti pri dejanskem stanju paketa PHP. Zahteva pa, da za to vzpostavite omejen dostop in ga dobro zavarujete. Za odvisnosti lastnih aplikacij PHP obstajajo spet lastna orodja za preverjanje, na primer `composer audit` za pakete iz Composerja.

## Smiseln vrstni red za MSP

1. **Popis in skeniranje:** Najprej vedeti, katere spletne strani in strežniki obstajajo, nato redno skenirati. Ugotovitev ne prevzemati nepreverjeno, ampak jih oceniti.
2. **Odpraviti osnove:** Odpraviti zastarelo programsko opremo, manjkajoče posodobitve in očitne napačne konfiguracije. Pentest na nepopravljenih sistemih zapravlja proračun.
3. **Ciljni penetracijski test:** Za najpomembnejše aplikacije, na primer trgovino, portal za stranke ali vmesnike, z jasno dogovorjenim obsegom in naknadnim testom.
4. **Pregled kode pri lastnih razvojih:** Kdor upravlja lastne aplikacije PHP, test dopolni s pregledom izvorne kode. Kako to poteka, opisuje [Varnostni pregled kode za projekte PHP](https://phpsos.de/sl/blog/sicherheits-code-review-php/).
5. **Prijavna točka za ranljivosti:** Politika, kako lahko zunanji prijavijo vrzeli, in datoteka security.txt po RFC 9116 pod `/.well-known/security.txt` s kontaktom in datumom poteka.
6. **Bug bounty, ko so osnove postavljene:** Šele ko se prijave zanesljivo ocenjujejo in vrzeli hitro odpravljajo.

Da iz tega nastane trajen postopek, se splača pogled v [Upravljanje ranljivosti v srednje velikih podjetjih](https://phpsos.de/sl/blog/schwachstellenmanagement-mittelstand/).

## Česa noben postopek ne zmore

Noben postopek preverjanja ne dokazuje, da je sistem varen. Pokaže le, kaj je bilo ob določenem času z določenimi metodami najdeno. Čisto poročilo o pentestu izpred pomladi ne pove nič o vrzeli, kot je PHP2Shell, ki postane znana oktobra.

Prav tako skeniranje ali pentest ne odgovorita na vprašanje, ali je strežnik že ogrožen. Za to je potrebno iskanje sledi na samem sistemu: procesi, datoteke, cron opravila, računi, povezave. To je lastna naloga z lastnimi metodami.

> **Pomembno:**
> Preverjajte samo sisteme, za katere ste upravičeni, in pri gostovanih sistemih vnaprej razjasnite pravila ponudnika. Penetracijski test zahteva pisno naročilo z obsegom, obdobjem in kontaktnimi osebami.

## Kdaj zunanjega testa ne potrebujete

Za preprosto spletno stran podjetja brez obrazcev z občutljivimi podatki, pri ponudniku gostovanja, ki posodobitve zanesljivo namešča, pogosto zadošča redno skeniranje s kritično oceno rezultatov. Penetracijski test bi bil tu običajno nesorazmeren. Pomembnejše so ažurna programska oprema, močni dostopi in varnostne kopije.

Zunanji test se splača pri trgovinah, portalih, lastnih razvojih, vmesnikih do notranjih sistemov in povsod, kjer stranke ali norme zahtevajo neodvisno dokazilo.

## Kako PHP SOS pomaga konkretno?

- Vzpostavimo redna skeniranja in ocenimo rezultate, vključno z lažnimi alarmi zaradi prenosov popravkov.
- Pomagamo odpraviti osnove, preden denar steče v pentest.
- Skupaj s specializiranimi partnerji izvajamo [varnostne revizije in penetracijske teste](https://phpsos.de/sl/leistungen/sicherheitsaudit-penetrationstest/) z usklajenim obsegom in naknadnim testom.
- Podpiramo pri vzpostavitvi prijavne točke za ranljivosti in datoteke security.txt.

## Sklep

Skeniranje, pentest in bug bounty so stopnje, ne tekmeci. Kdor začne z rednimi skeniranji, odpravi osnove in nato ciljno naroči test, dobi za svoj proračun največ varnosti. Bug bounty je kreativna naloga za organizacije, katerih obveznosti so že izpolnjene.


## Pogosta vprašanja

**Kakšna je razlika med pentestom in skeniranjem ranljivosti?**  
Skeniranje ranljivosti samodejno preveri, ali so prepoznavne znane vrzeli ali napačne konfiguracije. Penetracijski test gre dlje: strokovnjaki v dogovorjenem okviru poskušajo ranljivosti dejansko izkoristiti in povezati ter ocenijo posledice.

**Ali skener ugotovi, ali je moj strežnik popravljen proti PHP2Shell?**  
Samo omejeno. Mnogi skenerji preberejo prikazano različico PHP. Če distribucija namesti prenos popravka (backport), številka pogosto ostane enaka in skener javi vrzel, ki je že zdavnaj zaprta. Obratno se lahko prikaže nova številka, medtem ko stari procesi še tečejo.

**Ali je program bug bounty primeren za mala podjetja?**  
Običajno še ne. Bug bounty predpostavlja, da se prijave hitro ocenijo in vrzeli hitro odpravijo. Dober vstop je preprosta politika prijave ranljivosti z datoteko security.txt.

**Ali smem svojo spletno stran preveriti sam s skenerjem?**  
Svoje sisteme praviloma da, če ste za to upravičeni. Če je spletna stran pri ponudniku gostovanja, vnaprej razjasnite, ali so skeniranja dovoljena ali jih je treba napovedati. Tuje sisteme preverjate samo s pisnim dovoljenjem upravljavca.

**Kako pogosto naj poteka pentest?**  
Trdnega pravila ni. Običajen je test pred zagonom nove aplikacije, po večjih spremembah in v rednih razmikih, ki jih določajo vaše tveganje in po potrebi zahteve strank ali norm.

## Viri

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