Vuonna 2026 raportoitiin päivässä 131% enemmän CVE:itä kuin edellisenä vuonna.

Riippuvuudet

Reachability-analyysi (reachability analysis)

Reachability-analyysi tarkistaa, voiko koodisi oikeasti kutsua riippuvuuden haavoittuvaa funktiota. Paketissa voi olla vika, johon sovelluksesi ei koskaan koske, ja reachability-analyysi siirtää tällaiset löydökset listalla alemmas, jotta tiimit voivat keskittyä niihin, joita voidaan hyödyntää.

Päivitetty

Miksi sitä tarvitaan

SCA-skannaus vertaa pakettiversioita tietoturvatiedotteisiin. Se tietää, että versiossa on vika, mutta ei sitä, käyttääkö sovelluksesi viallista osaa. Kirjasto, jossa on satoja funktioita ja yksi haavoittuva jäsennin, raportoidaan samalla tavalla kutsuitpa jäsennintä tai et, ja suuressa riippuvuuspuussa tästä kertyy jono, jota kukaan ei ehdi purkaa.

Miten reachability-analyysi toimii

  1. Etsi haavoittuva koodi. Työkalun on tiedettävä, missä funktiossa haavoittuvuus on. Tietoturvatiedotteet eivät usein kerro sitä, joten toimittajat ylläpitävät omia tietojaan.
  2. Rakenna kutsugraafi. Se kuvaa, mitkä funktiot kutsuvat mitäkin, omasta koodistasi riippuvuuksiin asti.
  3. Etsi polku. Jos kutsuketju johtaa koodistasi haavoittuvaan funktioon, löydös on saavutettavissa. Jos ei, se merkitään saavuttamattomaksi ja priorisoidaan alemmas.

Reachability-analyysin tasot

Taso Mihin se vastaa Kompromissi
Riippuvuus Tuodaanko pakettia lainkaan? Edullinen, ja poistaa vain käyttämättömät riippuvuudet
Funktio Voiko kutsupolku saavuttaa haavoittuvan funktion? Yleisin tavoite, ja vaatii kutsugraafin sekä funktiokohtaiset haavoittuvuustiedot
Ajonaikainen Latautuiko tai suoritettiinko tämä koodi tuotannossa? Näyttöä oikeasta liikenteestä, mutta vain siitä, mitä ajettiin seurannan aikana

Todellinen hyödyntäminen vaatii muutakin kuin polun. Syötteen on päästävä funktioon muodossa, joka laukaisee vian, ja sitä harva työkalu pystyy arvioimaan.

Missä reachability-analyysi jää vajaaksi

  • Saavuttamaton ei tarkoita turvallista. Se tarkoittaa, ettei työkalu löytänyt polkua. Reflektio, dynaamiset importit ja lisäosien lataus voivat luoda polkuja, joita staattinen analyysi ei näe.
  • Kielten kattavuus vaihtelee. Staattisesti käännettyjä kieliä on helpompi jäljittää kuin dynaamisia, ja työkalut eroavat siinä, mitkä ekosysteemit saavat funktiotason analyysin.
  • Haavoittuvuustiedot ovat puutteellisia. Jos kukaan ei ole yhdistänyt tietoturvatiedotetta funktioon, työkalulla ei ole mitään etsittävää.
  • Tulos muuttuu koodisi mukana. Tänään saavuttamaton löydös voi olla saavutettavissa seuraavan julkaisun jälkeen, joten vastaus on tarkistettava uudelleen.
  • Se priorisoi vain sen, mikä on tunnistettu. Komponenttia, jota skanneri ei koskaan löytänyt, ei voi analysoida. Ilman kattavaa inventaariota reachability-analyysi järjestää vain osan kokonaiskuvasta.

Miten sitä käytetään turvallisesti

  • Käytä sitä työn järjestämiseen, älä löydösten sivuuttamiseen. Korjaa saavutettavat löydökset ensin ja aikatauluta loput sen sijaan, että sulkisit ne.
  • Älä anna sen ohittaa aktiivista hyödyntämistä. Löydös, joka on CISA:n KEV-luettelossa tai jolla on korkea EPSS-pistemäärä, ansaitsee ihmisen tekemän päätöksen, vaikka se olisi merkitty saavuttamattomaksi.
  • Ole varovainen internetiin näkyvien palveluiden kanssa. Väärän vastauksen hinta on suurin siellä, missä hyökkääjät pääsevät suoraan käsiksi.
  • Kirjaa perustelut. Jos päätät, ettei löydös koske sinua, VEX-lausunto säilyttää päätöksen ja kertoo asiakkaillesi miksi.

Miten reachability-analyysi sovitetaan yhteen vakavuuden, hyödyntämistietojen ja liiketoimintakontekstin kanssa, kerrotaan oppaassa näin priorisoit haavoittuvuudet.

Mitkä työkalut tarjoavat reachability-analyysia?

Monet kaupalliset SCA-työkalut tarjoavat, muun muassa Snyk, Endor Labs, Mend, Checkmarx, Semgrep ja Aikido, ja syvyys vaihtelee kielittäin. Go-kielen govulncheck on ilmainen esimerkki yhdestä ekosysteemistä. Katso parhaiden SCA-työkalujen vertailu nähdäksesi, mitä kukin kattaa.

Mihin CRACI sopii

CRACI ei tarjoa reachability-analyysia. Se toimii sitä edeltävässä vaiheessa: sen tietämisessä, mitä buildissa ylipäätään on. Se on GitHub Actions -runneri, joka tallentaa jokaisen paketin, jonka kukin jobi hakee, myös piilotetut riippuvuudet, jotka jäävät lukitustiedostoja skannaavilta työkaluilta huomaamatta, ja arvioi toimitettujen versioiden SBOM:t jatkuvasti uudelleen sitä mukaa kuin uusia haavoittuvuuksia julkaistaan. Jos reachability-analyysi on tärkein prioriteettisi, käytä siihen tehtyä työkalua CRACI:n rinnalla. Katso miten CRACI sopii SCA-työkalujesi rinnalle.

Reachability-analyysi: usein kysytyt kysymykset

Mitä reachability-analyysi on SCA:ssa?

Se tarkistaa, voiko koodisi oikeasti kutsua riippuvuuden haavoittuvaa funktiota, jotta löydökset, joihin koodistasi ei ole polkua, voidaan priorisoida alemmas.

Onko reachability-analyysi tarkka?

Se on hyödyllinen mutta ei todiste. Saavutettavalla löydöksellä on todellinen polku, kun taas saavuttamaton tarkoittaa vain, ettei työkalu löytänyt polkua. Reflektio, dynaaminen lataus ja puutteet haavoittuvuustiedoissa voivat kaikki piilottaa polun.

Voiko saavuttamattomat haavoittuvuudet jättää huomiotta?

Älä jätä niitä suoraan huomiotta. Aikatauluta ne saavutettavien löydösten jälkeen, tarkista ne uudelleen koodimuutosten jälkeen ja kiinnitä erityistä huomiota kaikkeen, mitä hyödynnetään aktiivisesti tai mikä toimii internetiin näkyvässä palvelussa.

Mitä eroa on reachability-analyysillä ja hyödynnettävyydellä?

Reachability-analyysi kysyy, pääseekö koodi haavoittuvaan funktioon. Hyödynnettävyys kysyy, voiko hyökkääjä käyttää tätä polkua vahingon tekemiseen. Vika voi olla saavutettavissa mutta silti hyödyntämiskelvoton sinun ympäristössäsi.

Vähentääkö reachability-analyysi hälytyksiä?

Kyllä, se on sen päätarkoitus. Kuinka paljon, riippuu kielestä, työkalusta ja siitä, kuinka suurta osaa kustakin riippuvuudesta koodisi käyttää.

Aloita buildin kattavasta kokonaiskuvasta

Näe jokainen paketti, jonka GitHub Actions -jobi oikeasti haki, ennen kuin päätät, mikä on korjaamisen arvoista.

Varaa demo