Derfor hører leverandørkjedesikkerhet hjemme i CI-en din

1:53

Produksjonsbygget ditt er ikke bygget på laptopen din

De fleste team går ut fra at koden de testet lokalt, er koden som leveres. Kilden er den samme, men programvaren er det ofte ikke. Et bygg er kildekode pluss alt det henter og alt rundt det på tidspunktet det kjører, og svært lite av det ligger fast.

Ufestede avhengigheter løses forskjellig

Versjonsområder for avhengigheter er normen. I npm godtar ^1.0.4 enhver senere 1.x-utgivelse, så den samme package.json installerer forskjellige versjoner på forskjellige dager. En lockfile fester dem, men bare hvis den er committet og bygget følger den: npm ci feiler når lockfilen og package.json ikke stemmer overens, mens npm install i det stille kan oppdatere lockfilen. Mange prosjekter committer ikke noen i det hele tatt. Det gjør heller ikke Express 5.2.1, et mye brukt nettrammeverk.

Selv en festet versjon er et navn, ikke en fil. Dokumentasjonen til pip forklarer at versjonsfesting alene ikke hindrer en pakkeindeks i å levere forskjellige filer for samme versjon, og derfor tilbyr den hash-checking mode.

Tiden endrer inndataene

Registre endrer seg mellom bygg. Nye versjoner publiseres, gamle trekkes tilbake, og et versjonsområde som ble trygt oppløst på mandag, kan plukke opp en kompromittert utgivelse på tirsdag. Container-tagger flytter seg også: Dockers egen dokumentasjon advarer om at image-tagger kan endres, og at en utgiver kan oppdatere en tagg til å peke på et nytt image, så FROM node:20 er ikke det samme base-imaget fra én måned til den neste med mindre du fester det med digest.

Tiden havner også inne i utdataene. Prosjektet Reproducible Builds kaller tidsstempler den største kilden til problemer med reproduserbarhet, fordi så mange verktøy skriver gjeldende dato og klokkeslett inn i det de bygger.

Miljøet er annerledes

• Operativsystem og arkitektur. En laptop med macOS og ARM og en CI-runner med Linux og x86-64 installerer forskjellige ferdigbygde binærfiler for samme pakke. Mange npm-verktøy leveres nå som plattformspesifikke pakker som pakker inn en kompilert binærfil.
• Verktøykjeder. Versjoner av kompilator, kjøretid og pakkebehandler glir fra hverandre mellom maskiner med mindre alle er festet.
• Cacher. Maskinen din og CI-en din gjenoppretter forskjellige cacher, bygget på forskjellige tidspunkter fra forskjellige oppløsninger.
• Installasjonsskript og byggesteg. Post-install-hooks, setup-actions og byggeskript laster ned verktøy og data under bygging. Ingenting av det dukker opp i et manifest.
• Konfigurasjon. Miljøvariabler, byggeflagg og hemmeligheter finnes i CI og ingen andre steder.

Prosjektet Reproducible Builds definerer et reproduserbart bygg som et bygg der hvem som helst, med samme kildekode, byggemiljø og byggeinstruksjoner, kan gjenskape bit-for-bit identiske kopier av alle angitte artefakter. Den definisjonen viser hvor mye som må holdes konstant. De fleste teams bygg kommer ikke dit, og de som gjør det, har jobbet hardt for det. Inntil du er der, er den eneste pålitelige beskrivelsen av hva som ble levert, den som ble registrert mens bygget som ble levert, kjørte.

1:18

Hvor du kan sjekke, og hva hvert sted kan se

Sikkerhetssjekker kan kjøre på fire steder. Hvert av dem har sin oppgave, men bare ett ser bygget som faktisk produserte utgivelsen din.

En skanning av repositoriet rapporterer det prosjektet deklarerer. En skanning av det ferdige artefaktet rapporterer det den kan gjenkjenne inni det. Ingen av dem så bygget skje. Express 5.2.1 committer ingen lockfile, så en skanner som pekes mot en ren utsjekk, har ingen av prosjektets npm-avhengigheter å løse og rapporterer det andre den gjenkjenner. Pek det samme verktøyet mot en installert kopi av samme repositorium, og ett cataloger-flagg endrer svaret igjen. Hva som kommer tilbake, avhenger av hva som var installert før skanningen, og det er nettopp den delen en skanning ikke kontrollerer. Siden om SBOM-er fra bygget forklarer hvorfor skanninger er uenige, og hva det endrer å registrere bygget.

Pipelinen er et mål i seg selv

CI er der kildekode, avhengigheter og hemmeligheter møtes, og det gjør den verdt å angripe.

• tj-actions/changed-files (2025). En mye brukt GitHub Action ble kompromittert og skrev CI-hemmeligheter inn i byggelogger.
• Codecov Bash Uploader (2021). Et endret skript, kjørt i kundenes CI, sendte miljøvariabler til en angripers server.
• Shai-Hulud-ormen i npm (2025). Kompromitterte pakker stjal påloggingsinformasjon ved installasjon og brukte den til å publisere flere kompromitterte pakker.
• xz utils (2024). En bakdør ble skjult i release-tarballer og i selve byggeprosessen, ikke i den synlige kildekoden.

Alle disse kjørte kode under et bygg eller en installasjon. En repositorieskanning kjørt før dem, eller en artefaktskanning kjørt etter dem, ville ikke ha sett hva byggeprosessen gjorde. Kontroller som overvåker og begrenser hva en jobb kan nå, må sitte der jobben kjører. Det gjelder også for interne apper og apper med lav profil: Slike angrep går etter pipelinen og pakkene alle apper deler, ikke etter hva en app gjør. Se leverandørkjedesikkerhet for intern programvare og programvare med lav risiko.

Mer kode, flere avhengigheter, færre som leser dem

AI-kodeagenter skriver og endrer kode raskere enn team klarer å gå gjennom hver linje, og de legger til avhengigheter underveis. De navngir også pakker som ikke finnes: En studie fra USENIX Security 2025 av 576 000 genererte kodeeksempler fant andeler hallusinerte pakker på minst 5,2 % for kommersielle modeller og 21,7 % for modeller med åpen kildekode. En angriper som registrerer ett av disse navnene, blir installert av det neste bygget som stoler på det.

Hver endring, uansett hvem eller hva som skrev den, går gjennom bygget på vei til produksjon. Det gjør bygget til det ene kontrollpunktet som ikke er avhengig av at noen har sett på den.

Bevis må beskrive det som ble levert

Regelverk og kunder ber om bevis, ikke intensjoner. EUs Cyber Resilience Act ber produsenter identifisere og dokumentere komponentene i produktene sine og håndtere sårbarheter i dem gjennom produktets støtteperiode. En SBOM generert fra et manifest beskriver det prosjektet ba om. En SBOM registrert fra bygget beskriver det som gikk inn i utgivelsen du er ansvarlig for. Når en ny sårbarhet publiseres, forteller den andre deg hvilke utgivelser som er berørt. Les hva CRA krever.

Hva «i CI» bør bety

Å kjøre en skanner som et CI-steg er en begynnelse, men den ser fortsatt på filer etter at de har kommet. Gjort ordentlig betyr «i CI» dette:

1. Registrer, ikke utled. Fang opp hver pakke og nedlasting jobben faktisk henter, inkludert transitive avhengigheter og alt som gjenopprettes fra en cache.
2. Si hvor fullstendig registreringen er. En SBOM bør angi om den dekker alt jobben hentet, ikke bare liste opp det den fant.
3. Kontroller egress. Bestem hvilke verter en jobb kan nå, og stopp resten før en kompromittert avhengighet kan ringe hjem.
4. Fortsett å følge med etter utgivelsen. Sjekk det som er levert, på nytt etter hvert som nye sårbarheter dukker opp, og gjør funn om til rettinger.

Det er dette CRACI gjør. Det er en runner for GitHub Actions-jobbene dine, så det registrerer hva hvert bygg henter inn, bruker egress-policyen og overvåker det du har levert. Å flytte en workflow er én linje: runs-on: craci. Se slik fungerer CRACI.

Det CI ikke erstatter

Å legge leverandørkjedesikkerhet inn i bygget gjør ikke andre lag valgfrie.

• Utviklermaskiner har fortsatt påloggingsinformasjon og kjører installasjonsskript. Beskytt dem også; en kompromittert laptop kan pushe kode før noe bygg kjører.
• Kodegjennomgang og statisk analyse finner feil i din egen kode, og det gjør ikke en registrering av avhengigheter.
• Festing, lockfiler og digester er fortsatt god praksis. De gjør avstanden mellom bygg mindre; å registrere bygget forteller deg hva som skjedde uansett.

Bygget er ikke det eneste stedet å sjekke. Det er det eneste stedet som ser programvaren du faktisk leverer.