123% meer gemelde CVE's per dag in 2026 dan vorig jaar.

Beveiliging

Uw app heeft een laag risico. Uw buildpipeline niet.

Als uw software intern, niche of onopvallend is, is het redelijk om beveiliging laag op de lijst te zetten. Aanvallen op de softwareketen kijken niet naar wat uw app doet. Ze gaan af op de pipeline en de pakketten die elke app deelt.

Bijgewerkt op

De redenering klopt, tot op zekere hoogte

We horen het vaak, en het komt meestal voort uit een verstandige gedachte. De app is een intern dashboard, een datapipeline of een kleine service met een handvol gebruikers. Hij bevat niets wat een aanvaller wil hebben. Het beveiligingsbudget gaat eerst naar het product voor klanten.

Die logica klopt voor de applicatie. Ze klopt niet voor de manier waarop de applicatie wordt gebouwd. Elk team heeft, wat het ook levert, een CI-pipeline met inloggegevens erin en een afhankelijkheidsboom die het niet zelf heeft geschreven. Die zijn de aanval waard omdat ze worden gedeeld, en een compromittering daar bereikt alles waar die inloggegevens bij kunnen: uw registries, uw cloudaccounts en uw andere repositories.

Aanvallen die zich niets aantrokken van wat de app deed

Geen van deze incidenten was gericht op een bepaald soort applicatie. Elk ervan bereikte teams via een tool of pakket waarmee ze software bouwden.

tj-actions/changed-files, 2025

Een veelgebruikte GitHub Action die gewijzigde bestanden detecteert, werd gecompromitteerd. Volgens CISA stonden er tussen 12 en 15 maart 2025 kwaadaardige versies online, en legde de compromittering secrets bloot, waaronder toegangssleutels, persoonlijke toegangstokens van GitHub, npm-tokens en private RSA-sleutels. Wiz meldde dat de code het geheugen van de CI-runner dumpte, waardoor de secrets op publieke repositories in workflowlogs terechtkwamen. Workflows die via een versietag naar de action verwezen, voerden de kwaadaardige code uit, ongeacht wat de repository bevatte.

Shai-Hulud-npm-worm, 2025

In september 2025 waarschuwde CISA voor een zichzelf vermenigvuldigende worm die meer dan 500 npm-pakketten had gecompromitteerd. De worm verzamelde persoonlijke toegangstokens van GitHub en cloud-API-sleutels voor AWS, Google Cloud en Azure. Palo Alto Networks Unit 42 beschreef hoe hij gestolen npm-tokens gebruikte om geïnfecteerde versies van de andere pakketten van het slachtoffer te publiceren, en hoe een latere golf tijdens pre-install draaide, waardoor zijn bereik in CI/CD-pipelines groter werd.

Shai-Hulud and other supply chain attacks

Hoe de npm-worm Shai-Hulud bij installatie inloggegevens stal en die gebruikte om meer gecompromitteerde pakketten te publiceren, met de eerdere aanvallen waarop hij volgt.

Petteri Pulkkinen en Erika Marttinen op Kubernetes Community Days Helsinki 2026, 4:30 tot 7:57 van SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

Codecov Bash Uploader, 2021

Een aanvaller wist via een fout in het Docker-imagebuildproces van Codecov inloggegevens te bemachtigen en wijzigde het Bash Uploader-script dat veel teams in CI draaiden. Van 31 januari tot 1 april 2021 kon het gewijzigde script omgevingsvariabelen, waaronder inloggegevens, tokens en sleutels die in de CI-omgeving beschikbaar waren, naar een derde partij sturen. Het werd ontdekt toen een klant merkte dat de checksum van het script niet klopte.

xz utils, 2024

Er werd kwaadaardige code ingebouwd in XZ Utils-versies 5.6.0 en 5.6.1, een bibliotheek voor datacompressie die in Linux-distributies aanwezig kan zijn. CISA adviseerde terug te gaan naar een niet-gecompromitteerde versie zoals 5.4.6 en te zoeken naar kwaadaardige activiteit. Een compressiebibliotheek is zo ongeveer de minst spectaculaire afhankelijkheid die er is, en toch was die een doelwit.

event-stream, 2018

Iemand die zich voordeed als behulpzame maintainer nam het populaire npm-pakket event-stream over en voegde in versie 3.3.6 een kwaadaardige afhankelijkheid toe, flatmap-stream. Het npm-team meldde dat de payload gericht was op één specifieke applicatie, de bitcoinwallet Copay. Alle anderen die event-stream installeerden, kregen de kwaadaardige code ook.

Wat deze incidenten gemeen hebben

  • Ze gebeurden tijdens de build of de installatie. De kwaadaardige code draaide op machines van ontwikkelaars en CI-runners, niet in de productieapp.
  • Ze gingen af op inloggegevens. Tokens en sleutels in de pipeline waren de buit, omdat ze deuren openen buiten het project dat wordt gebouwd.
  • Ze kwamen binnen via vertrouwde namen. Een bekende action, een bekend pakket, een bekend script. Niemand koos ervoor malware te installeren.
  • De eerste vraag daarna was steeds dezelfde. Heeft een van onze builds de slechte versie binnengehaald, en waar kon die bij? Teams zonder record van wat elke build gebruikte, moesten dat reconstrueren.

Wat minimale inspanning inhoudt

U hebt geen beveiligingsteam nodig om de basis te dekken. Het meeste advies van GitHub en CISA past in een korte lijst:

  1. Pin GitHub Actions van derden vast op een volledige commit-SHA in plaats van een tag, zodat een verplaatste tag niet kan veranderen wat er draait.
  2. Commit lockfiles en pin versies van afhankelijkheden vast op bekende goede releases.
  3. Geef CI-tokens de minimale rechten waarmee ze nog werken, en roteer ze wanneer een incident iets raakt wat u gebruikt.
  4. Vereis phishingbestendige meervoudige authenticatie op accounts van ontwikkelaars en voor publicatie.
  5. Houd bij wat elke build heeft geïnstalleerd, zodat u "waren we getroffen?" kunt beantwoorden met gegevens in plaats van uit het geheugen.

De eerste vier zijn configuratie. De vijfde is degene die de meeste kleine teams overslaan, omdat er tooling voor nodig is.

Wat CRACI met weinig moeite toevoegt

CRACI neemt het vastleggen voor zijn rekening en voegt een netwerkgrens toe, zonder dat u uw app of uw workflows hoeft te wijzigen.

  • Eén regel per job. Wijzig runs-on in craci. Uw GitHub Actions-workflows blijven zoals ze zijn, en runs verschijnen nog steeds in GitHub.
  • Een SBOM van elke build. CRACI legt de pakketten vast die elke job daadwerkelijk binnenhaalt, inclusief pakketten die uit caches zijn teruggezet, en exporteert het resultaat in CycloneDX of SPDX.
  • Een netwerktrace per job. Wanneer een incident bekend wordt, kunt u controleren welke builds het getroffen pakket hebben binnengehaald en waarmee elke job verbinding heeft gemaakt.
  • Een egressbeleid dat u op default deny kunt zetten. Sta de pakketbronnen toe die een job nodig heeft, en een gecompromitteerde stap heeft minder plekken om naartoe te sturen wat hij vindt. Beleid blokkeert bij een fout (fail closed), en overtredingen leiden tot een alert.
  • Doorlopende herbeoordeling. Gemonitorde SBOM's worden opnieuw gecontroleerd zodra er nieuwe kwetsbaarheden worden gepubliceerd, zodat een oude build niet "schoon" blijft alleen omdat niemand heeft gekeken.

Om duidelijk te zijn over de grenzen: een egressbeleid had niet voorkomen dat de tj-actions-compromittering secrets naar een publiek log schreef, en geen enkele tool maakt een gelekt token ongedaan. Vastpinnen en roteren blijven belangrijk. Wat CRACI verandert, is hoe snel u kunt beantwoorden of u blootgesteld was, en hoe ver een gecompromitteerde stap kan reiken.

Voor een eerste werkende workflow installeert u de GitHub App en wijzigt u één regel in runs-on: craci.

Wat het kost

CRACI brengt alleen buildminuten in rekening: $0.002 per vCPU-minuut ($0.004 voor een standaardrunner met 2 vCPU), per seconde gemeten, zonder maandbedrag en zonder kosten per SBOM. Zie prijzen voor de volledige voorwaarden. Startups die in aanmerking komen, kunnen zich aanmelden voor het startupprogramma voor minimaal 100k gratis buildminuten en persoonlijke onboarding.

Als u software in de EU verkoopt, is het ook de moeite waard om na te gaan of de Cyber Resilience Act op u van toepassing is. Onze gids over de CRA legt de scope en de deadlines uit.

Zie wat uw build werkelijk binnenhaalt

Boek een demo en draai een van uw workflows op CRACI. U krijgt een SBOM en een netwerktrace voor de job, zonder wijziging aan uw app.

Demo boeken