# Tunkeutumistesti, Bug Bounty vai haavoittuvuusskannaus? Valitkaa sopiva tarkastusmenetelmä

> Tunkeutumistesti vai haavoittuvuusskannaus, vai heti Bug Bounty? Mitä kukin menetelmä löytää, missä se on sokea ja missä järjestyksessä ne sopivat pk-yritykselle.

Lähde: https://phpsos.de/fi/blog/pentest-bugbounty-scan/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** Tunkeutumistesti vai haavoittuvuusskannaus ei ole joko–tai-kysymys vaan järjestyksen kysymys. Haavoittuvuusskannaus löytää automaattisesti tunnettuja aukkoja ja virheellisiä asetuksia, nopeasti ja edullisesti, mutta vääriä hälytyksiä ja sokeita pisteitä sisältäen. Tunkeutumistesti tarkastaa kohdennetusti, mitä hyökkääjä voisi todella saavuttaa. Bug Bounty -ohjelma avaa tarkastuksen ulkopuolisille tutkijoille ja kannattaa vasta, kun skannaukset ja tunkeutumistestit ovat rutiinia. Useimmille pk-yrityksille järjestys on: skannatkaa säännöllisesti, korjatkaa löydökset, teettäkää kohdennettu testi, perustakaa haavoittuvuuksille ilmoituspiste.

## Miksi kysymys esitetään PHP2Shellin jälkeen uudelleen

Joka tarkistaa verkkosivustonsa PHP2Shellin jälkeen verkkoskannerilla, voi saada hämmentäviä tuloksia. Skanneri ilmoittaa ehkä kriittisestä aukosta, vaikka hosting-yritys on vahvistanut korjauksen. Toinen ei ilmoita mitään, vaikka palvelin käyttää yhä vanhaa PHP-versiota, koska versiotieto on piilotettu.

Syy on toimintatavassa. Monet skannerit päättelevät haavoittuvuuden näytetystä versiosta. Jakelut asentavat kuitenkin backportit muuttamatta versionumeroa; raporttien mukaan esimerkiksi Ubuntu 24.04 näyttää päivityksen jälkeenkin 8.3.6. Miksi näin on, selittää sivu [Miksi php -v näyttää päivityksen jälkeen saman numeron](https://phpsos.de/fi/blog/php-v-zeigt-alte-nummer/). Luotettavan todisteen antaa paketin muutosloki, katso [PHP-version ja korjaustilan tarkistaminen oikein](https://phpsos.de/fi/php2shell/php-version-pruefen/).

Se ei ole argumentti skannereita vastaan vaan niiden puolesta, kunhan tunnette niiden rajat ja yhdistätte ne muihin menetelmiin.

## Tunkeutumistesti vai haavoittuvuusskannaus: kolme menetelmää vertailussa

| Kriteeri | Haavoittuvuusskannaus | Tunkeutumistesti | Bug Bounty |
|---|---|---|---|
| Kuka tarkastaa? | Automaattinen työkalu | Toimeksiannetut asiantuntijat | Ulkopuoliset tutkijat, usein alustan kautta |
| Mitä löytyy? | Tunnetut aukot, vanhentuneet versiot, virheelliset asetukset | Hyödynnettävät haavoittuvuudet, logiikkavirheet, ketjutukset | Mitä tutkijat löytävät ja ilmoittavat, usein epätavallista |
| Syvyys | Laaja mutta pinnallinen | Syvä sovitun laajuuden sisällä | Vaihtelee, riippuu osallistujista |
| Väärät hälytykset | Usein | Harvoin, löydökset todistetaan | Paljon ilmoituksia, jotka on arvioitava |
| Suunniteltavuus | Korkea, toistettavissa vapaasti | Korkea, kiinteä ajanjakso ja laajuus | Matala, ilmoituksia tulee jatkuvasti |
| Edellytykset yrityksessä | Joku, joka arvioi tulokset | Sovittu laajuus, testiympäristö tai huoltoikkuna | Kypsä prosessi arviointiin, korjaukseen ja palkitsemiseen |
| Tyypillinen käyttö | Jatkuvasti, esim. kuukausittain tai muutosten jälkeen | Ennen käyttöönottoa, suurempien muutosten jälkeen, säännöllisesti | Täydentävästi kypsissä, näkyvillä olevissa sovelluksissa |

Mikään menetelmistä ei korvaa muita. Skannaus näyttää paljon lyhyessä ajassa, tunkeutumistesti näyttää, mikä todella merkitsee, ja Bug Bounty löytää sen, mitä kukaan ei ole ajatellut.

Skannereiden kohdalla kannattaa lisäksi katsoa tarkemmin skannauksen tyyppiä. Ulkopuolelta tehty skannaus näkee vain sen, minkä jokainen kävijä näkee, ja joutuu usein arvaamaan versioita palvelimen vastauksista. Todennettu skannaus, jossa työkalu lukee omilla tunnuksillaan palvelimelle asennetut paketit, antaa selvästi luotettavampia tuloksia, erityisesti PHP:n todellisen paketin tilan osalta. Se edellyttää kuitenkin, että luotte siihen rajoitetun pääsyn ja suojaatte sen hyvin. Omien PHP-sovellusten riippuvuuksille on puolestaan omia tarkastustyökaluja, esimerkiksi `composer audit` Composer-paketeille.

## Pk-yritykselle järkevä järjestys

1. **Luettelo ja skannaus:** Tietäkää ensin, mitä verkkosivustoja ja palvelimia on, sitten skannatkaa säännöllisesti. Älkää ottako löydöksiä käyttöön tarkistamatta, vaan arvioikaa ne.
2. **Korjatkaa perusasiat:** Poistakaa vanhentunut ohjelmisto, puuttuvat päivitykset ja ilmeiset virheelliset asetukset. Tunkeutumistestin tilaaminen päivittämättömille järjestelmille on budjetin hukkaamista.
3. **Kohdennettu tunkeutumistesti:** Tärkeimmille sovelluksille, esimerkiksi verkkokauppa, asiakasportaali tai rajapinnat, selkeästi sovitulla laajuudella ja uusintatestillä.
4. **Koodin tarkastus omille kehityksille:** Joka ylläpitää omia PHP-sovelluksia, täydentää testin lähdekoodin läpikäynnillä. Miten se etenee, kuvaa kirjoitus [Tietoturvakoodikatselmointi PHP-projekteille](https://phpsos.de/fi/blog/sicherheits-code-review-php/).
5. **Ilmoituspiste haavoittuvuuksille:** Ohje siitä, miten ulkopuoliset voivat ilmoittaa aukoista, ja RFC 9116:n mukainen security.txt-tiedosto osoitteessa `/.well-known/security.txt` yhteystiedoin ja voimassaoloaikoineen.
6. **Bug Bounty, kun perusteet ovat kunnossa:** Vasta kun ilmoitukset arvioidaan luotettavasti ja aukot korjataan ripeästi.

Jotta tästä tulee pysyvä toimintatapa, kannattaa katsoa [Haavoittuvuuksien hallinta pk-yrityksessä](https://phpsos.de/fi/blog/schwachstellenmanagement-mittelstand/).

## Mitä mikään menetelmistä ei tee

Mikään tarkastusmenetelmä ei todista järjestelmän olevan turvallinen. Se näyttää vain, mitä tiettynä ajankohtana tietyillä menetelmillä löydettiin. Puhdas tunkeutumistestin raportti keväältä ei kerro mitään aukosta kuten PHP2Shell, joka tulee tietoon lokakuussa.

Samoin skannaus tai tunkeutumistesti ei vastaa kysymykseen, onko palvelin jo vaarantunut. Siihen tarvitaan jälkien etsintä itse järjestelmästä: prosessit, tiedostot, cron-työt, tilit, yhteydet. Se on oma tehtävänsä omine menetelmineen.

> **Tärkeää:**
> Teettäkää tarkastus vain järjestelmille, joihin teillä on oikeus, ja selvittäkää hostatuissa järjestelmissä palveluntarjoajan säännöt etukäteen. Tunkeutumistesti edellyttää kirjallista toimeksiantoa, jossa on laajuus, ajanjakso ja yhteyshenkilöt.

## Milloin ette tarvitse ulkopuolista testiä

Yksinkertaiselle yrityksen verkkosivustolle ilman arkaluonteisia tietoja sisältäviä lomakkeita, hosting-yrityksellä joka asentaa päivitykset luotettavasti, riittää usein säännöllinen skannaus ja tulosten kriittinen arviointi. Tunkeutumistesti olisi tässä yleensä suhteeton. Tärkeämpiä ovat ajantasainen ohjelmisto, vahvat käyttöoikeudet ja varmuuskopiot.

Ulkopuolinen testi kannattaa verkkokaupoissa, portaaleissa, omissa kehityksissä, sisäisten järjestelmien rajapinnoissa ja kaikkialla, missä asiakkaat tai standardit vaativat riippumattoman todisteen.

## Miten PHP SOS auttaa konkreettisesti?

- Otamme käyttöön säännölliset skannaukset ja arvioimme tulokset, backporttien aiheuttamat väärät hälytykset mukaan lukien.
- Autamme korjaamaan perusasiat ennen kuin rahaa käytetään tunkeutumistestiin.
- Toteutamme erikoistuneiden kumppanien kanssa [tietoturva-auditoinnit ja tunkeutumistestit](https://phpsos.de/fi/leistungen/sicherheitsaudit-penetrationstest/) sovitulla laajuudella ja uusintatestillä.
- Tuemme haavoittuvuuksien ilmoituspisteen ja security.txt-tiedoston perustamisessa.

## Yhteenveto

Skannaus, tunkeutumistesti ja Bug Bounty ovat portaita, eivät kilpailijoita. Joka aloittaa säännöllisistä skannauksista, korjaa perusasiat ja teettää sitten kohdennetun testin, saa budjetillaan eniten turvaa. Bug Bounty on lisäpuoli organisaatioille, joiden perusvelvoitteet ovat jo kunnossa.


## Usein kysytyt kysymykset

**Mitä eroa on tunkeutumistestillä ja haavoittuvuusskannauksella?**  
Haavoittuvuusskannaus tarkastaa automaattisesti, ovatko tunnetut aukot tai virheelliset asetukset havaittavissa. Tunkeutumistesti (penetration test) menee pidemmälle: asiantuntijat yrittävät sovitussa kehyksessä todella hyödyntää haavoittuvuuksia ja ketjuttaa niitä sekä arvioivat seuraukset.

**Selvittääkö skanneri, onko palvelimeni päivitetty PHP2Shelliä vastaan?**  
Vain rajoitetusti. Monet skannerit lukevat näytetyn PHP-version. Jos jakelu asentaa backportin, numero pysyy usein samana, ja skanneri ilmoittaa aukon, joka on jo kauan sitten suljettu. Toisaalta voidaan näyttää uusi numero, vaikka vanhat prosessit ovat vielä käynnissä.

**Sopiiko Bug Bounty -ohjelma pienille yrityksille?**  
Yleensä ei vielä. Bug Bounty edellyttää, että ilmoitukset arvioidaan nopeasti ja aukot korjataan ripeästi. Hyvä alku on yksinkertainen haavoittuvuuksien ilmoittamista koskeva ohje security.txt-tiedostoineen.

**Saanko tarkistaa verkkosivustoni itse skannerilla?**  
Omat järjestelmänne yleensä kyllä, jos teillä on siihen oikeus. Jos verkkosivusto on hosting-yrityksellä, selvittäkää etukäteen, ovatko skannaukset sallittuja tai ilmoitettava. Vieraita järjestelmiä tarkistatte vain ylläpitäjän kirjallisella luvalla.

**Kuinka usein tunkeutumistesti pitäisi tehdä?**  
Kiinteää sääntöä ei ole. Tavallista on testi ennen uuden sovelluksen käyttöönottoa, suurempien muutosten jälkeen ja säännöllisin väliajoin, jotka määräytyvät riskinne sekä mahdollisten asiakkaiden tai standardien vaatimusten mukaan.

## Lähteet

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