Waarom ketenbeveiliging in uw CI thuishoort

1:53

Uw productiebuild is niet de build op uw laptop

De meeste teams gaan ervan uit dat de code die ze lokaal hebben getest ook de code is die wordt geleverd. De broncode is hetzelfde, maar de software vaak niet. Een build is broncode plus alles wat hij ophaalt en alles wat eromheen zit op het moment dat hij draait, en daarvan ligt heel weinig vast.

Niet-vastgepinde afhankelijkheden worden anders opgelost

Versiebereiken zijn de norm. In npm accepteert ^1.0.4 elke latere 1.x-release, dus dezelfde package.json installeert op verschillende dagen verschillende versies. Een lockfile pint ze vast, maar alleen als er een is gecommit en de build zich eraan houdt: npm ci mislukt wanneer de lockfile en package.json niet overeenkomen, terwijl npm install de lockfile stilletjes kan bijwerken. Veel projecten committen er helemaal geen. Express 5.2.1, een veelgebruikt webframework, doet dat niet.

Zelfs een vastgepinde versie is een naam, geen bestand. De documentatie van pip legt uit dat versies vastpinnen alleen niet voorkomt dat een package index verschillende bestanden voor dezelfde versie serveert, en daarom biedt pip een modus met hashcontrole.

Tijd verandert de invoer

Registries veranderen tussen builds. Nieuwe versies worden gepubliceerd, oude worden teruggetrokken, en een bereik dat maandag veilig werd opgelost, kan dinsdag een gecompromitteerde release binnenhalen. Ook containertags verschuiven: de eigen documentatie van Docker waarschuwt dat imagetags veranderlijk zijn en dat een uitgever een tag naar een nieuwe image kan laten wijzen, dus FROM node:20 is van de ene maand op de andere niet dezelfde base image, tenzij u hem vastpint op digest.

Tijd komt ook in de uitvoer terecht. Het Reproducible Builds-project noemt timestamps de grootste bron van reproduceerbaarheidsproblemen, omdat zoveel tools de huidige datum en tijd vastleggen in wat ze bouwen.

De omgeving is anders

• Besturingssysteem en architectuur. Een laptop met macOS en ARM en een CI-runner met Linux en x86-64 installeren verschillende voorgecompileerde binaries voor hetzelfde pakket. Veel npm-tools worden nu geleverd als platformspecifieke pakketten om een gecompileerde binary heen.
• Toolchains. Versies van compilers, runtimes en pakketbeheerders lopen tussen machines uiteen, tenzij elk daarvan is vastgepind.
• Caches. Uw machine en uw CI zetten verschillende caches terug, gebouwd op verschillende momenten en uit verschillende resoluties.
• Installatiescripts en buildstappen. Post-install-hooks, setup-actions en buildscripts downloaden tijdens de build tools en gegevens. Niets daarvan staat in een manifest.
• Configuratie. Omgevingsvariabelen, buildvlaggen en secrets bestaan in CI en nergens anders.

Het Reproducible Builds-project definieert een reproduceerbare build als een build waarbij iedereen met dezelfde broncode, buildomgeving en buildinstructies bit voor bit identieke kopieën van alle opgegeven artefacten kan maken. Die definitie laat zien hoeveel er constant moet blijven. De builds van de meeste teams komen daar niet, en wie er wel komt, heeft er hard voor gewerkt. Tot die tijd is het enige betrouwbare verslag van wat is geleverd het verslag dat is vastgelegd terwijl de geleverde build draaide.

1:18

Waar u kunt controleren, en wat elke plek kan zien

Beveiligingscontroles kunnen op vier plekken draaien. Elke plek heeft een taak, maar slechts één ziet de build die uw release daadwerkelijk heeft opgeleverd.

Een scan van de repository rapporteert wat het project declareert. Een scan van het afgeronde artefact rapporteert wat hij daarin kan herkennen. Geen van beide heeft de build zien gebeuren. Express 5.2.1 commit geen lockfile, dus een scanner die op een schone checkout wordt gericht, heeft geen npm-afhankelijkheden van het project om op te lossen en rapporteert wat hij verder herkent. Richt dezelfde tool op een geïnstalleerde kopie van dezelfde repository, en één cataloger-vlag verandert het antwoord opnieuw. Wat eruit komt, hangt af van wat er vóór de scan was geïnstalleerd, en dat is precies het deel waar een scan geen controle over heeft. De pagina over SBOM's tijdens de build behandelt waarom scans van elkaar verschillen en wat het vastleggen van de build verandert.

De pipeline is op zichzelf een doelwit

In CI komen broncode, afhankelijkheden en secrets samen, en dat maakt het de moeite waard om aan te vallen.

• tj-actions/changed-files (2025). Een veelgebruikte GitHub Action werd gecompromitteerd en schreef CI-secrets weg in buildlogs.
• Codecov Bash Uploader (2021). Een gewijzigd script dat in de CI van klanten draaide, stuurde omgevingsvariabelen naar de server van een aanvaller.
• De Shai-Hulud-npm-worm (2025). Gecompromitteerde pakketten stalen bij de installatie inloggegevens en gebruikten die om meer gecompromitteerde pakketten te publiceren.
• xz utils (2024). Een backdoor was verborgen in release-tarballs en in het buildproces zelf, niet in de zichtbare broncode.

Elk van deze aanvallen voerde code uit tijdens een build of installatie. Een repositoryscan die eraan voorafging, of een artefactscan erna, had niet gezien wat het buildproces deed. Controles die in de gaten houden en beperken wat een job kan bereiken, moeten zitten waar de job draait. Dat geldt ook voor interne apps en apps met een laag profiel: aanvallen als deze richten zich op de pipeline en de pakketten die elke app deelt, niet op wat een app doet. Zie ketenbeveiliging voor interne software en software met een laag risico.

Meer code, meer afhankelijkheden, minder mensen die ze lezen

AI-codeeragents schrijven en wijzigen code sneller dan teams elke regel kunnen beoordelen, en ze voegen onderweg afhankelijkheden toe. Ze noemen ook pakketten die niet bestaan: een USENIX Security 2025-studie van 576.000 gegenereerde codevoorbeelden vond percentages gehallucineerde pakketten van ten minste 5,2% voor commerciële modellen en 21,7% voor open-sourcemodellen. De code van een aanvaller die zo'n naam registreert, wordt geïnstalleerd door de volgende build die erop vertrouwt.

Elke wijziging, wie of wat die ook heeft geschreven, gaat op weg naar productie door de build. Dat maakt de build het enige controlepunt dat er niet van afhangt of iemand heeft gekeken.

Bewijs moet beschrijven wat is geleverd

Regelgeving en klanten vragen om bewijs, niet om intenties. De EU Cyber Resilience Act vraagt fabrikanten de componenten in hun producten te identificeren en te documenteren en kwetsbaarheden daarin af te handelen gedurende de ondersteuningsperiode van het product. Een SBOM die uit een manifest is gegenereerd, beschrijft waar het project om vroeg. Een SBOM die uit de build is vastgelegd, beschrijft wat er in de release is gegaan waarvoor u verantwoordelijk bent. Wanneer een nieuwe kwetsbaarheid wordt gepubliceerd, vertelt de tweede u welke releases zijn getroffen. Lees wat de CRA vereist.

Wat "in CI" zou moeten betekenen

Een scanner als CI-stap draaien is een begin, maar die kijkt nog steeds naar bestanden nadat ze zijn aangekomen. Goed gedaan betekent "in CI":

1. Leg vast, leid niet af. Registreer elk pakket en elke download die de job daadwerkelijk ophaalt, inclusief transitieve afhankelijkheden en alles wat uit een cache is teruggezet.
2. Vermeld hoe volledig de vastlegging is. Een SBOM moet aangeven of hij alles dekt wat de job heeft opgehaald, en niet alleen opsommen wat hij heeft gevonden.
3. Beheers egress. Bepaal welke hosts een job mag bereiken en houd de rest tegen voordat een gecompromitteerde afhankelijkheid naar huis kan bellen.
4. Blijf na de release opletten. Controleer wat is geleverd opnieuw zodra er nieuwe kwetsbaarheden verschijnen, en zet bevindingen om in oplossingen.

Dit is wat CRACI doet. Het is een runner voor uw GitHub Actions-jobs, dus het legt vast wat elke build binnenhaalt, past het egressbeleid toe en monitort wat u hebt geleverd. Een workflow overzetten is één regel: runs-on: craci. Zie hoe CRACI werkt.

Wat CI niet vervangt

Ketenbeveiliging in de build onderbrengen maakt andere lagen niet optioneel.

• Ontwikkelaarsmachines bevatten nog steeds inloggegevens en draaien installatiescripts. Bescherm ze ook; een gecompromitteerde laptop kan code pushen voordat er een build draait.
• Code review en statische analyse vinden fouten in uw eigen code, en dat doet een vastlegging van afhankelijkheden niet.
• Vastpinnen, lockfiles en digests blijven goed gebruik. Ze verkleinen het verschil tussen builds; het vastleggen van de build vertelt u hoe dan ook wat er is gebeurd.

De build is niet de enige plek om te controleren. Het is wel de enige plek die de software ziet die u echt levert.