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

Alusta

Näin CRACI toimii

CRACI ajaa GitHub Actions -buildisi ja tallentaa, mitä kukin niistä hakee mukaansa. Kaikki muu haavoittuvuuksien seurannasta CRA-näyttöön rakentuu tämän tallenteen varaan.

Päivitetty

CRACI-alustan yleiskuva. GitHubissa oleva lähdekoodi kulkee GitHub Actionsin kautta CRACI Secure Build Serviceen. Buildi syöttää CRACI Package Analyticsia ja sen jälkeen Vulnerability Analysisia (joka saa syötettä myös kolmansien osapuolten toimittajilta), Digital Inventorya ja Compliance Reportingia, joka raportoi kolmansille osapuolille, kuten asiakkaille, toimittajille ja ENISAlle. Buildi syöttää myös CRACI Attack Preventionia. Sekä Attack Prevention että Digital Inventory johtavat staging- ja tuotantokäyttöönottoon. Vulnerability Analysis ohjaa lisäksi luokitellut löydökset tiimeillesi, jotka tekevät korjauksen; korjattu julkaisu palaa GitHubin kautta, ja se buildataan ja seurataan uudelleen.
CRACI-alusta vasemmalta oikealle. Avaa kaavio täysikokoisena.

Lyhyesti

Useimmat tietoturvatyökalut tarkastelevat koodiasi tai manifestejasi jälkikäteen ja päättelevät, mitä buildi luultavasti sisälsi. CRACI on build-runneri, joten se näkee, mitä buildi todella haki, juuri sillä hetkellä kun se haki sen. Tämä tallenne on kaiken kaaviossa näkyvän lähtötieto: pakettianalytiikan, hyökkäysten torjunnan, haavoittuvuusanalyysin, jäljitettävyyden ja vaatimustenmukaisuuden raportoinnin.

GitHub ja GitHub Actions pysyvät käytössäsi. Muutos on yksi rivi kussakin työnkulussa:

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

Vaihe vaiheelta

1. Lähdekoodi ja CI/CD: GitHub ja GitHub Actions

Koodisi pysyy GitHubissa. Yhdistät organisaatiosi asentamalla CRACI GitHub Appin joko kaikkiin repositorioihin tai vain valitsemiisi. Työnkulut ajetaan edelleen GitHub Actionsista, ja niiden ajot näkyvät yhä GitHubissa. GitHub Actions on tällä hetkellä tuettu CI-integraatio; muiden CI/CD-järjestelmien tuki on tiekartalla.

2. Buildi: CRACI Secure Build Service

Jobit ajetaan CRACI-runnereilla eristetyissä virtuaalikoneissa. Runnerit skaalautuvat 1:stä 32 laskentayksikköön (kukin 1 vCPU ja 3 Gt RAM-muistia) natiivilla x86-64- ja ARM64-arkkitehtuurilla, GitHub-yhteensopivalla Ubuntu-levykuvalla tai CRACI:n kevyillä levykuvilla. Käyttö mitataan sekunnin tarkkuudella.

Buildit valmistuvat CRACI:lla noin kaksi kertaa nopeammin kuin GitHubin tavallisilla ylläpidetyillä runnereilla. Myös jokainen minuutti on edullisempi: tavallinen 2 vCPU:n Linux-runneri maksaa $0.004 minuutilta, kun GitHubilla hinta on $0.006 (noin 33 % vähemmän). Yhteensä buildi, joka kestää GitHubissa 10 minuuttia, valmistuu CRACI:lla noin 5 minuutissa ja maksaa noin 67 % vähemmän. CRACI myös laskuttaa sekunneittain eikä pyöristä jokaista jobia ylöspäin kokonaiseen minuuttiin, joten monista lyhyistä jobeista koostuvat putket säästävät vielä enemmän. Katso koko vertailu GitHubin ylläpitämiin runnereihin.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. Toimitusketjun kartoitus: CRACI Package Analytics

Jobin aikana pakettitietoinen välityspalvelin (proxy) tarkkailee liikennettä pakettilähteisiin ja tallentaa jokaisen ulkoisen riippuvuuden, jonka buildi hakee: npm-, PyPI-, RubyGems-, Cargo-, Go-, Nix-, OCI-, apt-, apk- ja Git-lähteistä sekä Yocton ja OpenEmbeddedin latausesiasetuksilla. Näyttö kulkee mukana CI-välimuisteissa, joten myös välimuistista palautetut paketit tulevat huomioiduiksi.

Tässä on ero muihin SBOM-työkaluihin. Ne lukevat lukitustiedoston (lockfile) tai buildin tuotokset ja päättelevät, mitä buildiin meni. CRACI näkee liikenteen, joten se tallentaa myös piilevät riippuvuudet, joita mikään lukitustiedosto ei listaa: koodin, jonka npm installin koukut lataavat, tiedostot, jotka Rustin build-skriptit hakevat buildin aikana, sekä konttibuildin pohjakuvan kerrokset.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.

Jokainen jobi ja välimuisti saa kattavuustilan väliltä Complete–Not recorded, joten tiedät, kuinka paljon sen tuottamaan SBOM:iin voi luottaa. SBOM:t viedään CycloneDX- tai SPDX-muodossa transitiiviset riippuvuudet mukaan lukien.

4. Jatkuva toimitusketjun tietoturva: CRACI Attack Prevention

Sama kerros, joka tallentaa liikenteen, myös hallitsee sitä. Lähtevän liikenteen käytäntö (egress policy) määrittää, mihin palvelimiin jobi saa ottaa yhteyttä. Oletuksena voi olla estävä tai salliva käytäntö, ja mukana on valmiit esiasetukset yleisille ohjelmistolähteille sekä mukautetut säännöt omillesi. Käytännöt validoidaan ennen jobin käynnistymistä, ja ne noudattavat fail closed -periaatetta: virhetilanteessa liikenne estetään. CRACI hälyttää rikkomuksista. Vaarantunut riippuvuus tai build-työkalu, joka yrittää ottaa yhteyttä kotipalvelimeensa, pysäytetään runnerilla.

Koska käytäntö sallii vain sen, mitä buildi tarvitsee, eikä etsi tunnettuja haitallisia palvelimia, se toimii myös hyökkäystä vastaan, jota kukaan ei ole ennen nähnyt. Jos Shai-Huludin kaltainen mato ehtii buildiisi ensin, sen yritys lähettää salaisuutesi ulos estetään silti.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. Jatkuva reagointi toimitusketjussa: CRACI Vulnerability Analysis

Tallennettuja paketteja verrataan tunnettuihin haavoittuvuuksiin, ja valvotut SBOM:t arvioidaan jatkuvasti uudelleen, joten myös toimituksen jälkeen julkistettu haavoittuvuus tavoittaa sinut. Organisaatiotason näkymät kertovat, mitkä buildit ja repositoriot jakavat haavoittuvan riippuvuuden, ja tietoturvatiimit voivat luokitella ja priorisoida (triage) jokaisen löydöksen ja ohjata sen korjauksesta vastaavalle tiimille. Voit myös lisätä kolmansien osapuolten toimittajiltasi saatuja SBOM:eja, jolloin ostamiasi komponentteja valvotaan samalla tavalla kuin omien buildiesi hakemia.

Using SBOMs for improved cybersecurity

Miten buildin aikana tallennetusta SBOM:sta tulee haavoittuvuuksien valvontaa julkaisun jälkeen. Juuri sitä CRACI:n SBOM-generointi ja haavoittuvuuksien seuranta tekevät.

Petteri Pulkkinen ja Erika Marttinen, Kubernetes Community Days Helsinki 2026, 22:11–23:27 videosta SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

6. Toimitusketjun jäljitys: CRACI Digital Inventory

Jokaisella buildilla on oma SBOM:nsa ja verkkoliikenteen jälki siitä, mihin se otti yhteyttä, ja CRACI:n API palauttaa SBOM:t, verkkoliikenteen jäljet ja alkuperätiedot. Kun uusi haavoittuvuus tai vaarantunut paketti nousee uutisiin, näet yhdestä paikasta, mitkä buildisi ovat alttiina.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. Toimitusketjun raportointi: CRACI Compliance Reporting

Matkan varrella kerätty näyttö menee niille, jotka sitä pyytävät: asiakkaille, toimittajille ja viranomaisille. SBOM:t viedään CycloneDX- tai SPDX-muodossa niiden komponenteista löydetyt haavoittuvuudet mukaan lukien, API palauttaa SBOM:t, verkkoliikenteen jäljet ja alkuperätiedot, ja CRACI valmistelee CRA:n mukaisten haavoittuvuusilmoitusten sisällön, jonka sinä lähetät.

EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) on tunnetuin tämän taustalla oleva sääntö, mutta ei ainoa. Kaikissa viitekehyksissä vaatimus on sama: tiedä, mitä ohjelmistosi sisältää, ja hallitse prosessi, jolla sen haavoittuvuudet löydetään ja käsitellään.

  • EU:n kyberkestävyyssäädös (Cyber Resilience Act): SBOM ja haavoittuvuuksien käsittely EU:ssa myytäville digitaalisia elementtejä sisältäville tuotteille sekä raportointivelvoitteet syyskuusta 2026 alkaen.
  • NIS2: toimitusketjun tietoturva sekä haavoittuvuuksien käsittely ja julkistaminen keskeisille ja tärkeille toimijoille.
  • ISO/IEC 27001: ei mainitse SBOM:eja, mutta sen liitteen A kontrollit edellyttävät omaisuusinventaariota (5.9), ICT-toimitusketjun tietoturvaa (5.21) ja teknisten haavoittuvuuksien hallintaa (8.8). Buildin aikana tallennetut SBOM:t ja jatkuva valvonta ovat näyttöä kaikista kolmesta. Katso SBOM:t vaatimustenmukaisuuden näyttönä.
  • Yhdysvaltain FDA: SBOM verkkoon kytkettyjen lääkinnällisten laitteiden markkinoille saattamista edeltäviin hakemuksiin sekä suunnitelma haavoittuvuuksien valvomiseksi ja korjaamiseksi julkaisun jälkeen.
  • Yhdysvaltain presidentin asetus 14028 (Executive Order 14028): SBOM:t jokaiselle tuotteelle ja haavoittuvuuksien julkistamisprosessi liittovaltiolle myyville toimittajille suunnatussa ohjelmistotoimitusketjun ohjeistuksessa.

CRACI antaa sinulle SBOM:t ja jatkuvan haavoittuvuusvalvonnan, joita nämä viitekehykset edellyttävät, sekä näytön vaatimustenmukaisuusväitteidesi tueksi. Kunkin viitekehyksen täyttäminen on edelleen sinun prosessisi; CRACI automatisoi sen näyttöä koskevan osan.

8. Käyttöönotto: staging ja tuotanto

Se, mikä päätyy stagingiin ja tuotantoon, on buildattu verkkokäytäntösi mukaisesti, ja sillä on buildin aikana tallennettu SBOM, jota valvotaan uusien haavoittuvuuksien varalta julkaisun jälkeen.

Syvemmälle

Näe CRACI omassa putkessasi

Varaa demo, niin käymme läpi buildisi, SBOM:isi ja vaatimustenmukaisuuden näyttösi.

Varaa demo