Skannaat jo riippuvuutesi. Tässä on se, mitä skanneri ei näe.

Missä nykyinen pinosi on hyvä

Jos sinulla on SCA ja SBOM-generointi käytössä, olet jo tehnyt vaikean organisatorisen työn: riippuvuuksia seurataan, tietoturvatiedotteet tavoittavat kehittäjät, ja luovutettava tiedosto on olemassa, kun joku kysyy. Pidä se.

• GitHubin riippuvuusgraafi ja Dependabot ovat monilla tiimeillä oletuksena päällä. GitHub kuvaa riippuvuusgraafia yhteenvedoksi repositorioon tallennetuista manifesti- ja lukitustiedostoista sekä riippuvuuksista, jotka repositoriolle on lähetetty dependency submission API:n kautta. Dependabot-hälytykset perustuvat siihen ja ilmoittavat sinulle, kun uusi tietoturvatiedote julkaistaan tai kun riippuvuusgraafisi muuttuu.
• Kaupallinen SCA, kuten Snyk, generoi myös SBOM:ja. Sen snyk sbom -komento lukee manifestitiedostot ja niiden lukitustiedostot ja tuottaa CycloneDX:n tai SPDX:n. Syyskuussa 2026 Snykin dokumentaation mukaan se on saatavilla vain Snyk Enterprise -pakettien asiakkaille.
• Avoimen lähdekoodin generaattorit, kuten Syft, Trivy ja cdxgen, ovat ilmaisia, nopeita ja helppoja lisätä CI:hin. Syft kuvaa itseään työkaluksi, joka generoi Software Bill of Materials -luettelon (SBOM) konttikuvista ja tiedostojärjestelmistä.

Näiden työkalujen vahvuuksia ovat nopea palaute pull requestiin, laaja ekosysteemikattavuus ja korjaustyönkulku, jonka kehittäjät jo tuntevat. CRACI ei korvaa sitä tänään. Sen haavoittuvuuksien seuranta kokoaa löydökset buildeista ja repositorioista ja arvioi seuratut SBOM:t uudelleen, kun uusia haavoittuvuuksia ilmenee. Tietoturvatiimit voivat tehdä löydöksille triagen ja ohjata ne oikealle tiimille. Käytäntöportit voivat estää buildin; haavoittuvuus-webhookit ovat tiekartalla.

Skanneri vai tallentaja

Jokainen yllä mainittu työkalu on skanneri. Osoitat sen lähdekoodipuuhun, lukitustiedostoon tai konttikuvaan, ja se päättelee, mitä buildiin meni. Se toimii, kun tiedostot kertovat koko tarinan. Se vaikeutuu, kun ne eivät kerro:

• Repositoriossa ei ole lukitustiedostoa, joten versiot ratkaistaan asennushetkellä.
• Buildi palauttaa paketteja CI-välimuistista, jota mikään manifesti ei mainitse.
• Buildin vaihe lataa työkalun, käyttöjärjestelmäpaketin tai binäärin suoraan.
• npm-asennuskoukku tai Rustin build-skripti hakee lisää koodia asennuksen aikana, samaa reittiä kuin Shai-Hulud-mato käytti.
• Konttibuildi hakee pohjakuvan ja sen käyttöjärjestelmäkerrokset, joita mikään kielen lukitustiedosto ei listaa.
• Toimittamasi tuote on käännetty binääri, ja sen vieressä oleva manifesti listaa tuskin mitään.

CRACI on tallentaja: se näkee liikenteen, skannerit eivät. Se ajaa buildin omalla GitHub Actions -yhteensopivalla runnerillaan, ja pakettitietoinen välityspalvelin (proxy) tarkkailee liikennettä pakettilähteisiin jobin ajon aikana, joten nämä piilossa olevat riippuvuudet päätyvät SBOM:iin. Välimuistista palautetut paketit kantavat näyttönsä mukanaan. craci scan ./dir -komentoa ei ole, koska hakemiston skannaaminen jälkikäteen on juuri se vaihe, jonka välttämiseksi CRACI on olemassa.

Mistä skannaus riippuu

Skannerin tulos riippuu työkalusta ja siitä, mihin se osoitetaan. Syft, Trivy, cdxgen, Microsoft SBOM Tool, GitHubin riippuvuusgraafin vienti ja Socket CLI päättelevät kukin listan siitä, mitä ne pystyvät lukemaan. Alla olevat mallit perustuvat siihen, miten näiden työkalujen on dokumentoitu toimivan.

Mikään komponentti ei löydy kaikilla työkaluilla

Jokainen generaattori päättää itse, mikä lasketaan komponentiksi ja mihin tiedostoihin luotetaan, joten sama checkout antaa jokaiselle eri listan. GitHubin riippuvuusgraafin vienti toimii taas toisin: se rakennetaan siitä, mitä GitHub tietää repositoriosta, eikä tiedostoista, joita skanneri lukee, ja se lukee oletushaaran eikä kiinnitettyä committia.

Ei lukitustiedostoa, ei riippuvuuksia

Express 5.2.1 ei committaa lukitustiedostoa. Kun generaattori, joka ratkaisee riippuvuudet lukitustiedostoista tai asennetusta puusta, osoitetaan puhtaaseen checkoutiin, sen edessä ei ole kumpaakaan, joten yksikään package.json-tiedostossa ilmoitetuista npm-riippuvuuksista ei päädy dokumenttiin. Mikään työkalu ei ole rikki. Se, sisältääkö SBOM ylipäätään riippuvuuksia, ei ratkea työkalusta. Se ratkeaa siitä, ajoiko joku ensin asennuksen.

Yksi lippu muuttaa vastauksen

Syftin oletusarvoinen hakemistoskannaus raportoi sen, mitä projekti ilmoittaa, ei sitä, mitä levylle on asennettu. Saman express-julkaisun asennetussa checkoutissa yksi katalogoijan lippu ratkaisee, näkyvätkö asennetut npm-paketit listassa lainkaan. Sama työkalu, sama versio, sama puu.

Tuote on binääri

anthropics/claude-code-repositoriossa versiossa v2.1.259 ei ole minkäänlaista riippuvuusmanifestia tai lukitustiedostoa. Sen julkaistu npm-paketti ilmoittaa nolla ajonaikaista riippuvuutta ja käärii valmiiksi käännetyn natiivibinäärin kahdeksan alustapaketin kautta. @openai/codex 0.149.1 on samanlainen. Manifestin lukijalla ei ole juuri mitään kuvattavaa, kun taas ajettava ohjelma on käännetty binääri, joten se, mitä kukin työkalu palauttaa, kertoo enemmän työkalusta kuin projektista.

Sama paketti, eri versiot

Silloinkin kun kaksi työkalua löytää saman asian, ne eivät aina ole yhtä mieltä siitä, mikä se on. Yksi voi kiinnittää GitHub Actionin commitin SHA-tunnisteeseen, kun taas toinen raportoi julkaisutagin. Väärään versioon perustuva haavoittuvuushaku palauttaa varman väärän vastauksen.

Mihin CRACI sopii SCA:si rinnalla

Pidä SCA pull requesteissa. Se on oikea paikka havaita haavoittuva versio ennen yhdistämistä. Lisää CRACI sinne, missä kysymys koskee buildia eikä muutosta:

• Mitä tämä julkaisu todella sisälsi? Tallennettu SBOM kattaa npm-, PyPI-, RubyGems-, Composer-, Cargo-, Go-, Nix-, OCI-, apt-, apk- ja Git-lähteet sekä latausesiasetukset, transitiiviset riippuvuudet mukaan lukien. Myös JFrog Artifactoryn npm- ja PyPI-peilit toimivat.
• Voimmeko luottaa listaan? Jokaisella jobilla ja välimuistilla on kattavuustila, joten puutteellinen tallenne näkyy eikä jää huomaamatta vajaaksi.
• Koskeeko uusi tietoturvatiedote meitä? Seuratut SBOM:t arvioidaan uudelleen, kun uusia haavoittuvuuksia julkaistaan, ja löydökset kootaan buildeista ja repositorioista.

SBOM:n voi ladata CycloneDX-muodossa julkisen REST API:n kautta yhdessä jobin verkkojäljen ja alkuperätietojen kanssa, joten se voi syöttää mitä tahansa CycloneDX:ää lukevaa työkalua, myös jo käyttämääsi SCA:ta. Käyttöönotto on yksi rivi työnkulussa: vaihda runs-on arvoon craci. GitHub Actions on tuettu CI tänään; GitLab CI, Jenkins ja muut CI-järjestelmät ovat tiekartalla.

Inventaario siitä, mitä on käytössä missäkin

CRACI:n inventaarionäkymä näyttää tarkalleen, mitkä ohjelmistoversiot ovat käytössä missäkin tuotteessa, maailmanlaajuisesti. Kun uusi haavoittuvuus julkaistaan, näet, missä tuotteissa haavoittuva versio on, eikä sinun tarvitse koota sitä julkaisutiedoista ja taulukoista.

Lue lisää aiheista SBOM-generointi buildin aikana ja haavoittuvuuksien seuranta.

Mitä CRACI korvaa ja mitä ei, kerrotaan sivulla mitä CRACI korvaa.