# Pentest, bug bounty ili skeniranje ranjivosti? Odabir prikladnog postupka provjere

> Pentest ili skeniranje ranjivosti, ili odmah bug bounty? Što svaki postupak provjere pronalazi, gdje je slijep i kojim redoslijedom ima smisla za mala i srednja poduzeća.

Izvor: https://phpsos.de/hr/blog/pentest-bugbounty-scan/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Pentest ili skeniranje ranjivosti nije pitanje ili-ili, nego pitanje redoslijeda. Skeniranje ranjivosti automatizirano pronalazi poznate ranjivosti i pogrešne konfiguracije, brzo i povoljno, ali s lažnim uzbunama i slijepim pjegama. Penetracijski test ciljano provjerava što bi napadač stvarno mogao postići. Program bug bounty otvara provjeru vanjskim istraživačima i isplati se tek kad skeniranja i pentestovi postanu rutina. Za većinu malih i srednjih poduzeća redoslijed je: redovito skenirati, otkloniti nalaze, ciljano dati testirati, uspostaviti mjesto za prijavu ranjivosti.

## Zašto se pitanje nakon PHP2Shella ponovno postavlja

Tko nakon PHP2Shella provjeri svoju web-stranicu online skenerom, može dobiti zbunjujuće rezultate. Jedan skener možda javlja kritičnu ranjivost iako je pružatelj hostinga potvrdio zakrpu. Drugi ne javlja ništa iako poslužitelj još koristi staru verziju PHP-a, jer je podatak o verziji skriven.

Uzrok je u načinu rada. Mnogi skeneri ranjivost izvode iz prikazane verzije. Distribucije pak instaliraju backportove a da ne mijenjaju broj verzije; prema izvješćima Ubuntu 24.04 nakon ažuriranja primjerice i dalje prikazuje 8.3.6. Zašto je tome tako, objašnjava [Zašto php -v nakon ažuriranja pokazuje isti broj](https://phpsos.de/hr/blog/php-v-zeigt-alte-nummer/). Pouzdan dokaz daje changelog paketa, vidi [Kako ispravno provjeriti verziju PHP-a i stanje zakrpe](https://phpsos.de/hr/php2shell/php-version-pruefen/).

To nije argument protiv skenera, nego argument da se poznaju njihove granice i da se kombiniraju s drugim postupcima.

## Pentest ili skeniranje ranjivosti: tri postupka u usporedbi

| Kriterij | Skeniranje ranjivosti | Penetracijski test | Bug bounty |
|---|---|---|---|
| Tko provjerava? | Automatizirani alat | Angažirani stručnjaci | Vanjski istraživači, često putem platforme |
| Što se pronalazi? | Poznate ranjivosti, zastarjele verzije, pogrešne konfiguracije | Iskoristive ranjivosti, logičke pogreške, povezivanja | Ono što istraživači pronađu i prijave, često neobično |
| Dubina | Široko, ali površno | Duboko u dogovorenom opsegu | Različita, ovisi o sudionicima |
| Lažne uzbune | Česte | Rijetke, nalazi se dokazuju | Mnogo prijava koje treba procijeniti |
| Planirljivost | Visoka, može se ponavljati po volji | Visoka, čvrsto razdoblje i opseg | Niska, prijave dolaze neprekidno |
| Preduvjeti u tvrtki | Netko tko procjenjuje rezultate | Usuglašen opseg, testno okruženje ili prozor održavanja | Zreo proces procjene, otklanjanja i nagrađivanja |
| Tipična primjena | Neprekidno, primjerice mjesečno ili nakon izmjena | Prije pokretanja, nakon većih izmjena, redovito | Dopunski kod zrelih, izloženih aplikacija |

Nijedan postupak ne zamjenjuje druge. Skeniranje pokazuje mnogo u kratkom vremenu, pentest pokazuje što stvarno vrijedi, a bug bounty pronalazi ono na što nitko nije mislio.

Kod skenera se isplati i drugi pogled na vrstu skeniranja. Skeniranje izvana vidi samo ono što vidi svaki posjetitelj i verzije često mora pogađati iz odgovora poslužitelja. Autentificirano skeniranje, u kojem alat s vlastitim pristupnim podacima čita instalirane pakete na poslužitelju, daje znatno pouzdanije rezultate, osobito kod stvarnog stanja paketa PHP-a. Pretpostavlja ipak da u tu svrhu postavite ograničen pristup i dobro ga zaštitite. Za ovisnosti vlastitih PHP aplikacija opet postoje zasebni alati za provjeru, primjerice `composer audit` za pakete iz Composera.

## Smislen redoslijed za mala i srednja poduzeća

1. **Popis i skeniranje:** Najprije znati koje web-stranice i poslužitelji postoje, zatim redovito skenirati. Nalaze ne preuzimati neprovjereno, nego ih procijeniti.
2. **Otkloniti temelje:** Ukloniti zastarjeli softver, nedostajuća ažuriranja i očite pogrešne konfiguracije. Zakazati pentest na nezakrpanim sustavima baca proračun.
3. **Ciljani penetracijski test:** Za najvažnije aplikacije, primjerice shop, korisnički portal ili sučelja, s jasno dogovorenim opsegom i naknadnim testom.
4. **Pregled koda kod vlastitih razvoja:** Tko vodi vlastite PHP aplikacije, test dopunjuje pregledom izvornog koda. Kako to teče, opisuje [Sigurnosni pregled koda za PHP projekte](https://phpsos.de/hr/blog/sicherheits-code-review-php/).
5. **Mjesto za prijavu ranjivosti:** Smjernica kako vanjski mogu prijaviti ranjivosti i datoteka security.txt prema RFC 9116 na `/.well-known/security.txt` s kontaktom i datumom isteka.
6. **Bug bounty kad su temelji postavljeni:** Tek kad se prijave pouzdano procjenjuju, a ranjivosti žurno otklanjaju.

Da bi od toga nastao trajan tijek, isplati se pogledati [Upravljanje ranjivostima za srednje tvrtke](https://phpsos.de/hr/blog/schwachstellenmanagement-mittelstand/).

## Što nijedan postupak ne može

Nijedan postupak provjere ne dokazuje da je sustav siguran. Pokazuje samo što je u jednom trenutku određenim metodama pronađeno. Čisto izvješće pentesta iz proljeća ne govori ništa o ranjivosti poput PHP2Shella koja postaje poznata u listopadu.

Jednako tako skeniranje ili pentest ne odgovaraju na pitanje je li poslužitelj već kompromitiran. Za to je potrebno traženje tragova na samom sustavu: procesi, datoteke, cron poslovi, računi, veze. To je zaseban zadatak sa zasebnim metodama.

> **Važno:**
> Dajte provjeravati samo sustave za koje ste ovlašteni i kod hostiranih sustava unaprijed razjasnite pravila pružatelja. Penetracijski test traži pisanu narudžbu s opsegom, razdobljem i kontakt osobama.

## Kada Vam vanjski test nije potreban

Za jednostavnu web-stranicu tvrtke bez obrazaca s osjetljivim podacima, kod pružatelja hostinga koji pouzdano instalira ažuriranja, često je dovoljno redovito skeniranje s kritičnom procjenom rezultata. Penetracijski test bio bi ovdje najčešće nerazmjeran. Važniji su aktualan softver, jaki pristupi i sigurnosne kopije.

Vanjski test isplati se kod shopova, portala, vlastitih razvoja, sučelja prema internim sustavima i svugdje gdje klijenti ili norme traže neovisan dokaz.

## Kako PHP SOS konkretno pomaže?

- Postavljamo redovita skeniranja i procjenjujemo rezultate, uključujući lažne uzbune zbog backportova.
- Pomažemo otkloniti temelje prije nego što novac ode u pentest.
- Zajedno sa specijaliziranim partnerima provodimo [sigurnosne audite i penetracijske testove](https://phpsos.de/hr/leistungen/sicherheitsaudit-penetrationstest/) s usuglašenim opsegom i naknadnim testom.
- Podržavamo uspostavu mjesta za prijavu ranjivosti i datoteke security.txt.

## Zaključak

Skeniranje, pentest i bug bounty su stupnjevi, a ne konkurenti. Tko počne redovitim skeniranjima, otkloni temelje i zatim ciljano daje testirati, za svoj proračun dobiva najviše sigurnosti. Bug bounty je slobodni program za organizacije kojima je obveza već zadovoljena.


## Česta pitanja

**Koja je razlika između pentesta i skeniranja ranjivosti?**  
Skeniranje ranjivosti automatizirano provjerava jesu li prepoznatljive poznate ranjivosti ili pogrešne konfiguracije. Penetracijski test ide dalje: stručnjaci u dogovorenom okviru pokušavaju ranjivosti stvarno iskoristiti i povezati te procjenjuju posljedice.

**Otkriva li skener je li moj poslužitelj zakrpan protiv PHP2Shella?**  
Samo ograničeno. Mnogi skeneri čitaju prikazanu verziju PHP-a. Ako distribucija instalira backport, broj često ostaje isti, a skener javlja ranjivost koja je odavno zatvorena. Obrnuto, može se prikazati novi broj dok stari procesi još rade.

**Je li program bug bounty nešto za male tvrtke?**  
Najčešće još ne. Bug bounty pretpostavlja da se prijave brzo procjenjuju i ranjivosti žurno otklanjaju. Dobar ulaz je jednostavna smjernica za prijavu ranjivosti s datotekom security.txt.

**Smijem li svoju web-stranicu sam provjeriti skenerom?**  
Vlastite sustave u pravilu da, ako ste za to ovlašteni. Ako je web-stranica kod pružatelja hostinga, unaprijed razjasnite jesu li skeniranja dopuštena ili ih treba najaviti. Tuđe sustave provjeravate samo uz pisano dopuštenje operatera.

**Koliko često treba provoditi pentest?**  
Čvrstog pravila nema. Uobičajen je test prije pokretanja nove aplikacije, nakon većih izmjena i u redovitim razmacima koje određuju Vaš rizik i eventualno zahtjevi klijenata ili normi.

## Izvori

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