Därför hör säkerhet i leveranskedjan hemma i din CI

1:53

Ditt produktionsbygge är inte bygget på din laptop

De flesta team utgår från att koden de testade lokalt är koden som levereras. Källkoden är densamma, men programvaran är det ofta inte. Ett bygge är källkod plus allt det hämtar och allt runt omkring när det körs, och mycket lite av det är fast.

Olåsta beroenden löses olika

Versionsintervall är normen. I npm accepterar ^1.0.4 varje senare 1.x-release, så samma package.json installerar olika versioner olika dagar. En lockfile låser dem, men bara om den är incheckad och bygget följer den: npm ci misslyckas när lockfilen och package.json inte stämmer överens, medan npm install i tysthet kan uppdatera lockfilen. Många projekt checkar inte in någon alls. Express 5.2.1, ett allmänt använt webbramverk, gör det inte.

Även en låst version är ett namn, inte en fil. pips dokumentation förklarar att enbart versionslåsning inte hindrar ett paketindex från att servera olika filer för samma version, och det är därför pip erbjuder ett läge för hashkontroll.

Tiden ändrar indata

Register ändras mellan byggen. Nya versioner publiceras, gamla dras tillbaka, och ett intervall som löstes säkert på måndagen kan fånga en komprometterad release på tisdagen. Containertaggar flyttas också: Dockers egen dokumentation varnar för att avbildstaggar är föränderliga, så att en utgivare kan uppdatera en tagg till att peka på en ny avbild. Därför är FROM node:20 inte samma basavbild från en månad till nästa, om du inte låser den med en digest.

Tiden hamnar också i resultatet. Projektet Reproducible Builds kallar tidsstämplar för den största källan till problem med reproducerbarhet, eftersom så många verktyg skriver in aktuellt datum och aktuell tid i det de bygger.

Miljön är annorlunda

• Operativsystem och arkitektur. En laptop med macOS och ARM och en CI-runner med Linux och x86-64 installerar olika förbyggda binärer för samma paket. Många npm-verktyg levereras nu som plattformsspecifika paket som omsluter en kompilerad binär.
• Verktygskedjor. Versioner av kompilatorer, körmiljöer och pakethanterare glider isär mellan maskiner om inte alla är låsta.
• Cachar. Din maskin och din CI återställer olika cachar, byggda vid olika tidpunkter med olika lösta beroenden.
• Installationsskript och byggsteg. Hookar efter installation, setup-actions och byggskript laddar ner verktyg och data under bygget. Inget av det syns i ett manifest.
• Konfiguration. Miljövariabler, byggflaggor och hemligheter finns i CI och ingen annanstans.

Projektet Reproducible Builds definierar ett reproducerbart bygge som ett där vem som helst, utifrån samma källkod, byggmiljö och bygginstruktioner, kan återskapa bit för bit identiska kopior av alla angivna artefakter. Definitionen visar hur mycket som måste hållas konstant. De flesta teams byggen når inte dit, och de som gör det har jobbat hårt för det. Tills du är där är den enda tillförlitliga redogörelsen för vad som levererades den som registrerades medan det levererade bygget kördes.

1:18

Var du kan kontrollera, och vad varje plats kan se

Säkerhetskontroller kan köras på fyra platser. Var och en har sin uppgift, men bara en av dem ser bygget som faktiskt producerade din release.

En skanning av repot rapporterar vad projektet deklarerar. En skanning av den färdiga artefakten rapporterar vad den kan känna igen i den. Ingen av dem såg bygget ske. Express 5.2.1 checkar inte in någon lockfile, så en skanner som pekas mot en ren utcheckning har inga av projektets npm-beroenden att lösa och rapporterar det annat den känner igen. Peka samma verktyg mot en installerad kopia av samma repo så ändrar en enda flagga för en katalogiserare svaret igen. Vad som kommer tillbaka beror på vad som hade installerats före skanningen, vilket är just den del som en skanning inte styr. Sidan om SBOM:er från bygget tar upp varför skanningar är oense och vad en registrering av bygget ändrar.

Pipelinen är ett mål i sig

CI är platsen där källkod, beroenden och hemligheter möts, vilket gör den värd att angripa.

• tj-actions/changed-files (2025). En allmänt använd GitHub Action komprometterades och skrev ut CI-hemligheter i byggloggar.
• Codecov Bash Uploader (2021). Ett ändrat skript, som kördes i kundernas CI, skickade miljövariabler till en angripares server.
• npm-masken Shai-Hulud (2025). Komprometterade paket stal inloggningsuppgifter vid installation och använde dem för att publicera fler komprometterade paket.
• xz utils (2024). En bakdörr gömdes i release-arkiven och i själva byggprocessen, inte i den synliga källkoden.

Alla dessa körde kod under ett bygge eller en installation. En skanning av repot före dem, eller en skanning av artefakten efter dem, hade inte sett vad byggprocessen gjorde. Kontroller som bevakar och begränsar vad ett jobb kan nå måste sitta där jobbet körs. Det gäller även interna appar och appar med låg profil: attacker som dessa går på pipelinen och paketen som alla appar delar, inte på vad en app gör. Se säkerhet i leveranskedjan för intern programvara och programvara med låg risk.

Mer kod, fler beroenden, färre som läser dem

AI-kodningsagenter skriver och ändrar kod snabbare än team hinner granska varje rad, och de lägger till beroenden längs vägen. De namnger också paket som inte finns: en studie från USENIX Security 2025 av 576 000 genererade kodexempel fann andelar hallucinerade paket på minst 5,2 % för kommersiella modeller och 21,7 % för modeller med öppen källkod. En angripare som registrerar ett av de namnen blir installerad av nästa bygge som litar på det.

Varje ändring, oavsett vem eller vad som skrev den, passerar bygget på väg till produktion. Det gör bygget till den enda kontrollpunkt som inte är beroende av att någon har tittat.

Bevisen måste beskriva det som levererades

Regelverk och kunder efterfrågar bevis, inte avsikter. EU:s Cyber Resilience Act kräver att tillverkare identifierar och dokumenterar komponenterna i sina produkter och hanterar sårbarheter i dem under produktens supportperiod. En SBOM som genereras från ett manifest beskriver vad projektet bad om. En SBOM som registreras från bygget beskriver vad som ingick i releasen du ansvarar för. När en ny sårbarhet publiceras visar den andra SBOM:en vilka releaser som berörs. Läs vad CRA kräver.

Vad "i CI" bör betyda

Att köra en skanner som ett CI-steg är en början, men den tittar ändå på filer efter att de har kommit in. Rätt utfört betyder i CI:

1. Registrera, gissa inte. Fånga varje paket och varje nedladdning som jobbet faktiskt hämtar, inklusive transitiva beroenden och allt som återställs från en cache.
2. Ange hur komplett registreringen är. En SBOM ska ange om den täcker allt som jobbet hämtade, inte bara lista det den hittade.
3. Kontrollera utgående trafik. Bestäm vilka värdar ett jobb får nå, och stoppa resten innan ett komprometterat beroende kan ringa hem.
4. Fortsätt bevaka efter releasen. Kontrollera det som levererats på nytt när nya sårbarheter dyker upp, och omvandla fynd till åtgärder.

Det här är vad CRACI gör. Det är en runner för dina GitHub Actions-jobb, så den registrerar vad varje bygge drar in, tillämpar egress-policyn och bevakar det du har levererat. Att flytta ett arbetsflöde kräver en rad: runs-on: craci. Se så fungerar CRACI.

Vad CI inte ersätter

Att lägga säkerheten i leveranskedjan i bygget gör inte andra lager valfria.

• Utvecklarnas datorer har fortfarande inloggningsuppgifter och kör installationsskript. Skydda dem också; en komprometterad laptop kan pusha kod innan något bygge körs.
• Kodgranskning och statisk analys hittar brister i din egen kod, vilket en registrering av beroenden inte gör.
• Låsning, lockfiler och digests är fortfarande god praxis. De minskar skillnaden mellan byggen; registreringen av bygget visar vad som hände ändå.

Bygget är inte den enda platsen att kontrollera på. Det är den enda platsen som ser programvaran du faktiskt levererar.