CRACI ja Dependabot

Pidä Dependabot. Tässä on, mitä se kattaa.

Jos koodisi on GitHubissa, käytät todennäköisesti jo Dependabotia. Se tekee kolme hyödyllistä asiaa. Dependabot-hälytykset kertovat, kun repositoriosi riippuvuus vastaa tunnettua haavoittuvuutta. Tietoturvapäivitykset avaavat pull requesteja, jotka päivittävät haavoittuvat riippuvuudet. Versiopäivitykset pitävät riippuvuudet ajan tasalla silloinkin, kun mikään ei ole haavoittuva.

Kaikki tämä perustuu GitHubin riippuvuusgraafiin, joka jäsentää repositoriosi manifestit ja lukitustiedostot. GitHub voi viedä tämän graafin SPDX-muotoisena SBOM:na. Go-, Gradle- ja Maven-ekosysteemeille valmiit actionit voivat lähettää buildin aikana ratkaistut riippuvuudet dependency submission API:n kautta.

Riippuvuuksien paikkaamisessa vähällä vaivalla Dependabotia on vaikea voittaa, eikä CRACI avaa pull requesteja. CRACI tuo toisen puolen: kirjauksen siitä, mitä kukin buildi oikeasti haki, uusien haavoittuvuuksien varalta seurattuna, joten tiedät, mihin toimitettuihin buildeihin uusi tietoturvatiedote vaikuttaa ja mitkä päivitys-pull requestit kannattaa yhdistää ensin.

Kysymykset, joihin Dependabot ei vastaa

Dependabot on rakennettu repositorion ympärille. Se skannaa oletushaaran ja nojaa manifesteihisi ja lukitustiedostoihisi. GitHubin dokumentaatio sanoo tämän suoraan: hälytykset eivät havaitse jokaista tietoturvaongelmaa, manifesti- ja lukitustiedostot kannattaa pitää ajan tasalla tarkan havaitsemisen vuoksi, ja vain GitHubin tarkistamat tietoturvatiedotteet laukaisevat hälytyksiä.

Jäljelle jää kysymyksiä, joita tietoturva- tai compliance-vastaavalta lopulta kysytään:

• Mitä julkaisun 4.2 buildi oikeasti latasi, mukaan lukien työkalut ja kuvat, joita ei ole missään manifestissa?
• Pystyikö buildi ajon aikana ottamaan yhteyden mihin tahansa internetin palvelimeen?
• Pystytkö todistamaan, että asiakkaan saama binääri tuli juuri siitä buildista?
• Pystytkö tuottamaan tämän näytön auditoijalle kuukausia myöhemmin?

Näihin vastaaminen vaatii näkymän buildin sisältä, ja siellä CRACI toimii.

Mitä CRACI tuo lisää

Näkyvyys buildin aikana

CRACI on GitHub Actions -yhteensopiva runneri. Vaihdat runs-on-arvoksi craci, ja jobisi ajetaan CRACI:lla eristetyissä virtuaalikoneissa, ja ajot näkyvät edelleen GitHubin käyttöliittymässä. Jokaisen jobin aikana paketit tunnistava välityspalvelin (proxy) tallentaa liikenteen pakettilähteisiin: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk ja Git-lähteet sekä latausesiasetukset. CI-välimuisteista palautetut paketit siirtyvät mukaan, koska riippuvuuksien näyttö kulkee välimuistin mukana.

Jokainen SBOM ilmoittaa kattavuutensa jobi- ja välimuistikohtaisesti: Complete, Complete with connections, Incomplete, Unavailable tai Not recorded. Se on eri asia kuin graafi, joka on vain niin hyvä kuin sen jäsentämät tiedostot.

Ero näkyy käytännössä. GitHubin riippuvuusgraafin vienti muodostetaan siitä, mitä GitHub tietää repositoriosta, joten se voi listata komponentteja, joita mikään tiedostopohjainen skanneri ei löydä, ja se kuvaa oletushaaraa eikä buildaamaasi committia. Kumpikaan käytös ei ole väärin sille, mihin graafi on suunniteltu. Ne osoittavat, miksi repositorionäkymä ja buildikirjaus ovat eri asioita. (CRACI:a ei voi verrata samalla tavalla, koska se tallentaa buildeja eikä skannaa hakemistoja.)

Hallinta ajon aikana

Dependabot kertoo haavoittuvasta paketista sen jälkeen, kun se on manifestissasi. Sillä ei ole sananvaltaa siihen, mihin buildi saa yhteyden. CRACI:lla on, koska se ajaa buildin. Egress-käytännöt ovat oletuksena estäviä tai oletuksena sallivia, ja niissä on 24 sisäänrakennettua ohjelmistolähteiden esiasetusta, tyypitetyt mukautetut lähteet npm:lle, PyPI:lle, aptille, apk:lle, Go-välityspalvelimelle, Nixille, Cargolle, OCI-rekistereille ja Gitille sekä eksplisiittiset TLS-, TCP-, UDP- ja ICMP-säännöt. Käytännöt validoidaan ennen jobin alkua, ne toimivat fail closed -periaatteella ja laukaisevat hälytyksen rikkomuksesta.

Alkuperätiedot

CRACI generoi SBOM:n omassa runnerissaan siitä, mitä jobi haki. API palauttaa SBOM:t, verkkoliikenteen jäljet ja alkuperätiedot (provenance).

Vaatimustenmukaisuuden näyttö

Säädökset, kuten EU:n kyberkestävyyssäädös, edellyttävät valmistajilta tietoa siitä, mitä kussakin tuotejulkaisussa on, ja sen haavoittuvuuksien käsittelyä. CRACI kokoaa haavoittuvuudet buildeista ja repositorioista, arvioi seurattuja SBOM:eja jatkuvasti uudelleen uusien tietoturvatiedotteiden ilmestyessä ja vie SBOM:t CycloneDX- tai SPDX-muotoon haavoittuvuuksineen. Se automatisoi merkittävän osan siitä ohjelmistotoimitusketjun näkyvyydestä ja näytöstä, jota yritykset tarvitsevat laajempaan CRA-vaatimustenmukaisuusprosessiinsa. Lue lisää siitä, mikä CRA on, ja CRA-näytöstä.

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

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

Miten tiimit käyttävät molempia

• Dependabot pitää oletushaaran riippuvuudet paikattuina ja avaa pull requesteja, kun tietoturvatiedotteita julkaistaan.
• CRACI ajaa GitHub Actions -jobit, tallentaa, mitä kukin buildi haki, rajaa, mihin buildit saavat yhteyden, seuraa kunkin buildin hakemia riippuvuuksia uusien haavoittuvuuksien varalta ja säilyttää julkaisun näytön.

Mitään ei tarvitse siirtää. Dependabot jatkaa toimintaansa repositorioissasi, ja työnkulkusi jatkavat ajoaan GitHub Actionsissa, vain eri runnerilla.

CRACI ja Dependabot: yleisiä kysymyksiä

Mitä kumpikin työkalu kattaa, SBOM:t, hinnoittelu ja vaatimustenmukaisuus

Korvaako CRACI Dependabotin?

Ei. Pidä Dependabot päällä. Se merkitsee repositorioidesi haavoittuvat riippuvuudet ja avaa pull requesteja, jotka päivittävät ne. CRACI ajaa GitHub Actions -jobisi ja tallentaa, mitä kukin buildi oikeasti haki, hallitsee, mihin buildit saavat yhteyden, ja seuraa toimitettua ohjelmistoa uusien haavoittuvuuksien varalta.

Korvaavatko CRACI:n haavoittuvuusnäkymät Dependabot-hälytykset?

Eivät. Ne vastaavat eri kysymykseen. Dependabot-hälytykset koskevat yhden repositorion oletushaaraa. CRACI kokoaa haavoittuvuudet buildeista ja repositorioista ja arvioi seurattuja SBOM:eja jatkuvasti uudelleen, joten näet, millä buildeilla on yhteinen haavoittuva riippuvuus, ja tietoturvatiimit voivat tehdä löydösten triagen ja lähettää ne korjauksesta vastaavalle tiimille. Käytäntöportit voivat estää buildin; kynnysarvohälytykset ovat tiekartalla.

Avaako CRACI pull requesteja kuten Dependabot?

Ei. Dependabotin tietoturvapäivitykset ja versiopäivitykset avaavat pull requesteja; CRACI ei. CRACI tuo lisäksi buildikirjauksen, joten kun uusi tietoturvatiedote julkaistaan, tiedät, mihin toimitettuihin buildeihin se vaikuttaa ja mitkä päivitys-pull requestit kannattaa yhdistää ensin.

Miten GitHubin ja CRACI:n SBOM:t eroavat?

GitHub vie riippuvuusgraafin SPDX-muotoisena SBOM:na, joka muodostetaan repositorion manifesteista ja lukitustiedostoista sekä dependency submission API:sta, ja se kuvaa oletushaaraa. CRACI tallentaa SBOM:n jokaisen buildin aikana ja vie sen CycloneDX- tai SPDX-muotoon jobi- ja välimuistikohtaisen kattavuustilan kanssa, joka kertoo, jäikö tallennukseen aukko.

Auttaako CRACI, kun riippuvuutta ei ole missään manifestissa?

Kyllä, jos buildi hakee sen pakettilähteestä. Koska CRACI tallentaa liikenteen jobin aikana, skriptin lataama työkalu tai välimuistista palautettu paketti näkyy silti buildikirjauksessa, ja SBOM:n kattavuustila kertoo, jos jotakin ei voitu tallentaa.

Mitä Dependabot ja CRACI maksavat?

Dependabotin tietoturvapäivitykset ja versiopäivitykset sisältyvät jokaiseen GitHubin tilaukseen, myös Free-tilaukseen (syyskuussa 2026). CRACI veloittaa vain build-minuuteista: $0.002 vCPU-minuutilta ($0.004 oletuskokoiselle 2 vCPU:n runnerille), mitattuna sekunneittain, ilman kuukausimaksua ja ilman SBOM-kohtaista maksua. Katso voimassa olevat ehdot hinnoittelusta.

Onko CRACI vain tiimeille, joilla on vaatimustenmukaisuusvaatimuksia?

Ei, mutta niissä näyttö maksaa itsensä takaisin parhaiten. Jos myyt ohjelmistoja EU:hun, EU:n kyberkestävyyssäädös (Cyber Resilience Act) tekee julkaisukohtaisesta komponentti-inventaariosta ja haavoittuvuuksien käsittelystä osan työtä. Kaikille muillekin tieto siitä, mitä buildisi hakevat, on silti toimitusketjupoikkeamiin reagoinnin perusta. Varaa demo ja näe buildikirjaus yhdestä omasta työnkulustasi.