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- japostinstall-skriptitnpm install-komennon aikana (npm docs). Mitään, mitä nämä skriptit lataavat, ei näypackage-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.lockkirjaa 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- jacargo build-tuloste sekäcurl- taiwget-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ä
curljawget.
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.