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

Piilotettu riippuvuus

Piilotettu riippuvuus on koodia, paketti tai tiedosto, jonka buildi lataa ja jota se käyttää mutta jota mikään lukitustiedosto tai manifesti ei listaa, joten useimmat SBOM:t eivät näe sitä.

Päivitetty viimeksi: 11. marraskuuta 2026

Piilotettu riippuvuus (hidden dependency) on koodia, paketti tai tiedosto, jonka buildi lataa ja jota se käyttää mutta jota mikään lukitustiedosto (lockfile) tai manifesti ei listaa. Koska useimmat SBOM-työkalut perustuvat näihin listoihin, piilotetut riippuvuudet puuttuvat useimmista SBOM:ista, ja juuri niiden kautta etenivät useat viimeaikaiset toimitusketjuhyökkäykset. Yleisessä ohjelmistokehityksessä ilmaus tarkoittaa myös moduulien välistä ilmoittamatonta kytkentää; tässä sillä tarkoitetaan toimitusketjun merkitystä.

Yleisiä piilotettuja riippuvuuksia

  • Asennuskoukut. npm ajaa paketin preinstall-, install- ja postinstall-skriptit npm install -komennon aikana (npm docs). Mitään, mitä nämä skriptit lataavat, ei näy package-lock.json-tiedostossa. Tätä reittiä käytti Shai-Hulud-mato.
  • Build-skriptit. Cargo kääntää ja ajaa craten build.rs-tiedoston juuri ennen craten buildia (Cargo book). Osa build-skripteistä lataa tässä vaiheessa C-kirjaston tai valmiiksi käännetyn binäärin, eikä Cargo.lock kirjaa sitä.
  • Peruskuvat. Konttibuildissa peruskuva ja sen käyttöjärjestelmäkerrokset tulevat rekisteristä, eivät minkään ohjelmointikielen lukitustiedostosta. Katso Docker-kuvien SBOM:t.
  • CI-vaiheet. Työnkulun setup-actionit ja curl | sh -asentimet hakevat työkaluja suoraan URL-osoitteesta ilman lukitustiedostoa, versiokiinnitystä tai tiivistettä, ellei tekijä lisää sellaista.

Repositorioon commitoitu koodi (vendoroidut riippuvuudet) on toinen tapa, jolla komponentit jäävät manifestien ulkopuolelle, mutta sitä ei haeta buildin aikana. "Phantom dependency" tarkoittaa taas eri asiaa: JavaScriptissä pakettia, jota koodisi käyttää ilmoittamatta sitä ja joka on saatavilla vain hoistingin kautta.

Miksi SBOM-työkalut ohittavat ne

Lukitustiedostoon perustuvat työkalut lukevat lukitustiedoston ilmoitetun listan, joten ne näkevät vain sen, mitä on ilmoitettu. Tulosteskannerit tarkastelevat valmista artefaktia ja päättelevät, mitä siihen meni, mikä on arvailua käännetyn koodin, kuten Rustin, kohdalla. Kumpikaan ei näe, mitä buildi haki matkan varrella. Täydellinen luettelo siitä, mitä kukin lähestymistapa ohittaa, välimuistit ja build-työkalut mukaan lukien, on sivulla avoimen lähdekoodin SBOM-generaattorit. Piilotettu riippuvuus on aukko SBOM:n kattavuudessa, jota SBOM itse ei pysty paljastamaan.

Kiinnittäminenkään ei ratkaise ongelmaa: lukitustiedosto voi olla täydellinen, ja sen kiinnittämä asennuskoukku voi silti ladata jotain uutta. Buildin aikana tehtävät haut ovat myös yksi syy siihen, miksi toistettavan buildin saavuttaminen on vaikeaa.

Miten ne löydetään

  • Etsi buildin lokista latauksia: npm install- ja cargo build -tuloste sekä curl- tai wget-rivit.
  • Vertaa lukitustiedostosta generoitua SBOM:ia paketteihin, jotka asennusvaihe raportoi.
  • Hae SBOM:istasi pakettia, jonka tiedät olevan peruskuvassasi, kuten libc6. Jos sitä ei löydy, kuvan kerrokset puuttuvat.
  • Hae työnkuluistasi grepillä curl ja wget.

Luotettava ratkaisu on kirjata, mitä buildi todella ottaa vastaan verkon yli, sen sijaan että se rekonstruoidaan jälkikäteen.

CRACI

CRACI näkee jokaiseen buildiin tulevan liikenteen, joten se kirjaa piilotetut riippuvuudet, jotka lukitustiedostoon perustuvat työkalut ohittavat. Kun se ei nähnyt kaikkea, esimerkiksi koska jobi salli liikennettä, joka kiertää sen pakettitietoisen välityspalvelimen, jobin kattavuustila kertoo sen. Sen egress-käytäntö myös ratkaisee, mihin palvelimiin buildi ylipäätään pääsee, joten curl | sh palvelimeen, jota käytäntö ei salli, epäonnistuu. Katso buildin aikana tallennetut SBOM:t.