npm v12 Breekt CI: Install Scripts Standaard Uit

npm v12 werd uitgebracht op 8 juli 2026 en heeft stilletjes een langdurige aanname doorbroken: npm install voert niet langer automatisch code uit die pakketauteurs meebundelen. Installatiescripts staan nu standaard uit, tenzij u ze expliciet goedkeurt. Als uw CI-pipeline afhankelijk is van pakketten zoals sharp, esbuild of node-sass, staat er waarschijnlijk al een buildfout in de wachtrij. Het lastige is dat ontbrekende native binaries niet altijd de build laten falen. U kunt een groene CI-run krijgen die pas later, tijdens runtime, ontploft.

Wat er werkelijk veranderde in npm v12

De changelog van 8 juli bevestigt dat npm v12 de uitvoering van scripts tijdens installatie omzet van automatisch naar expliciete goedkeuring. Dit gaat verder dan de gebruikelijke postinstall-scripts. Dit wordt nu standaard geblokkeerd:

De binding.gyp-wijziging is degene die teams vaak verrast. Een pakket heeft geen duidelijk postinstall-script nodig om code uit te voeren tijdens installatie. Als het een binding.gyp bevat, startte node-gyp vroeger automatisch een build. Die route is nu afgesloten.

Waarom GitHub nu de trekker overhaalde

De aanvalscijfers van 2025-2026 maakten "afwachten" onrealistisch. Sonatype's 2026-rapport markeerde meer dan 454.600 nieuwe kwaadaardige pakketten in 2025, waarvan meer dan 99% van npm kwam. Alleen al Q4 2025 rapporteerde 394.877 nieuwe malwarepakketten: een stijging van 476% vergeleken met de drie kwartalen daarvoor gecombineerd.

Twee incidenten in het bijzonder duwden dit over de streep. De "Shai-Hulud"-worm van september 2025 injecteerde kwaadaardige postinstall-scripts in populaire pakketten, wat eindigde met meer dan 500 gecompromitteerde pakketten die werden verwijderd. De sluwere was "Miasma" (ook wel "Phantom Gyp" genoemd), die Chainguard documenteerde als 57 pakketten treffend over 286 kwaadaardige versies. Miasma vertrouwde niet op duidelijke postinstall-scripts. Het misbruikte binding.gyp en node-gyp-gedrag om code uit te voeren zonder de gebruikelijke alarmen te triggeren. Scanners die alleen naar verdachte postinstall-scripts keken, misten het.

Waarom het belangrijk is: Het risico was niet beperkt tot "pakketten met postinstall". Het was elke dependency die native compilatie kon triggeren. npm v12 blokkeert standaard dat hele aanvalspad.

Het probleem van stille fouten in CI-pipelines

Hier kunnen upgrades naar npm v12 lelijk worden. Het blokkeren van een installatiescript zorgt er niet per se voor dat npm ci faalt.

bashCopy
npm ci
# ✅ Exit code 0
# ✅ node_modules gevuld
# ❌ Native binaries ontbreken of zijn niet-functioneel

npm ci kan nog steeds slagen omdat de JavaScript-onderdelen normaal installeren. De native buildstap die vroeger tijdens installatie liep, gebeurt simpelweg nooit. Uw pipeline blijft doorlopen. Uw tests kunnen zelfs slagen als ze de native codepaden niet raken. Dan probeert productie een afbeelding te verkleinen met sharp, en plotseling is het duidelijk dat de binary nooit werd gebouwd.

javascriptCopy
// Deze import slaagt
const sharp = require('sharp');

// Dit faalt tijdens runtime
sharp('input.jpg').resize(300, 200).toFile('output.jpg');
// Error: Could not load the "sharp" module using the linux-x64 runtime

Om dit vroeg op te vangen, heeft u smoke tests nodig die native modules daadwerkelijk gebruiken, niet alleen importeren.

javascriptCopy
// ci-smoke-test.js
const sharp = require('sharp');
const canvas = require('canvas');

// Gebruik daadwerkelijk de native bindings
await sharp(Buffer.from([0x89, 0x50, 0x4e, 0x47])).metadata;
console.log('sharp: OK');

const ctx = canvas.createCanvas(1, 1).getContext('2d');
console.log('canvas: OK');

Voer zoiets uit na npm ci om stille fouten op te vangen voordat ze productie bereiken. Wat vaak wordt gemist: het importeren van een native module kan slagen zelfs als de onderliggende binary kapot is. U moet er daadwerkelijk gebruik van maken.

Het migratiepad: allowScripts en approve-scripts

npm v12 voegt een goedkeuringsworkflow op projectniveau toe via het nieuwe allowScripts-veld in package.json. De approve-scripts documentatie doorloopt de workflow van begin tot eind.

bashCopy
# Stap 1: Identificeer pakketten met niet-beoordeelde installatiescripts
npm approve-scripts --allow-scripts-pending

Dit toont pakketten die installatiescripts hebben maar nog niet op uw allowlist staan. Beoordeel elk zorgvuldig. In de meeste gevallen zijn de verrassingen transitieve dependencies die uw team niet direct heeft gekozen.

bashCopy
# Stap 2: Keur vertrouwde pakketten goed
npm approve-scripts sharp
npm approve-scripts esbuild
npm approve-scripts @prisma/client

Goedkeuringen zijn standaard versie-gepind. Dus als sharp een nieuwe versie uitbrengt, erft deze niet automatisch goedkeuring. Dat is het punt: het dwingt een bewuste hercontrole af.

jsonCopy
{
  "allowScripts": {
    "sharp@0.33.4": true,
    "esbuild@0.21.5": true,
    "@prisma/client@5.15.0": true,
    "suspicious-package@1.0.0": false
  }
}

De versiepinning doet hier het echte beveiligingswerk. Als een aanvaller een maintainer-account compromitteert en een kwaadaardige update verstuurt, krijgt die update niet automatisch code-uitvoering in uw omgeving. Het verschijnt in --allow-scripts-pending, en uw team kan onderzoeken voordat het goedkeurt.

Pakketten die uw build zullen breken

Deze categorieën hebben meestal expliciete goedkeuring nodig om correct te werken:

Native beeldverwerking: sharp, canvas, jimp (met native bindings), imagemagick

Build tools met native componenten: esbuild, swc, node-sass, sass (met native compiler)

Database drivers: better-sqlite3, sqlite3, pg-native, oracledb

Cryptografie: argon2, bcrypt, sodium-native

Systeemintegratie: fsevents (macOS file watching), node-pty, serialport

Monorepo tooling: Pakketten die prepare-scripts gebruiken voor git dependencies

yamlCopy
#.github/workflows/ci.yml
- name: Install dependencies
  run: npm ci

- name: Verify native modules
  run: node scripts/verify-native-modules.js

- name: Run tests
  run: npm test

Die verificatiestap tussen installatie en test is wat de "groene build, kapotte runtime"-situatie voorkomt. Laat het verificatiescript elke native module importeren en daadwerkelijk gebruiken waarvan uw app afhankelijk is.

De parallelle token-deprecatie

De installatiebeveiligingswijzigingen van npm v12 landen naast een andere brekende verschuiving: 2FA-bypass granular access tokens (GATs) worden uitgefaseerd.

De vervanging is trusted publishing via OIDC. In plaats van langlevende tokens in CI-secrets, vraagt de workflow kortlevende credentials aan en publiceert met provenance-attestaties.

yamlCopy
## GitHub Actions trusted publishing
jobs:
  publish:
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          registry-url: 'https://registry.npmjs.org'
      - run: npm publish --provenance --access public

De id-token: write-permissie laat de workflow een OIDC-token aanvragen. npm controleert het tegen uw trustedstedpublisher-configuratie, geeft een kortlevende credential uit en voegt provenance-metadata toe aan het gepubliceerde pakket.

Geen langlevende tokens meer in repository-secrets. Geen onzekerheid meer over of een token dat jaren geleden werd aangemaakt nog ergens rondzweeft.

Waarom het belangrijk is: Samen verschuiven installatiescript-goedkeuringen en trusted publishing npm naar een ander beveiligingsmodel. Code-uitvoering heeft expliciete goedkeuring nodig. Publiceren heeft cryptografisch bewijs nodig dat het van de juiste CI-pipeline kwam.

Voorbereiden vóór de gedwongen upgrade

npm 11.16+ levert deze gedragingen achter waarschuwingen, zodat teams nu kunnen beginnen zonder volledig over te schakelen naar npm v12.

bashCopy
## Schakel npm v12-gedrag in npm 11.16+ in
npm config set allow-scripts false
npm config set allow-git none
npm config set allow-remote none

Voer uw volledige CI-pipeline uit met die instellingen. Kijk wat er breekt. Bouw allowScripts uit. Verwijder dan de configuratie-overrides en commit de package.json-updates.

bashCopy
## Audit huidige dependencies
npm approve-scripts --allow-scripts-pending > scripts-to-review.txt

# Beoordeel elk pakket
cat scripts-to-review.txt | while read pkg; do
  npm view "$pkg" repository.url
  npm view "$pkg" scripts
done

Het doel is simpel: zorg dat allowScripts klaar en getest is voordat npm v12 de standaard wordt in uw CI-omgeving. De meeste CI-providers updaten Node.js-images vrij snel na een grote npm-release.

De moeite waard om in de gaten te houden

• Augustus 2026 GAT-capaciteitsverwijdering: Test publicatieworkflows nu als uw team nog steeds op granular access tokens vertrouwt
• npm provenance-adoptiepercentages: Verwacht dat meer registries en scanners provenance als vereiste gaan behandelen, niet als nice-to-have
• Ecosystem allowScripts-lijsten: Door de community onderhouden lijsten van pakketten die scripts nodig hebben zullen waarschijnlijk verschijnen, vergelijkbaar met hoe DefinitelyTyped werkt voor TypeScript
• CI-provider Node.js image-updates: Volg wanneer GitHub Actions, GitLab CI en CircleCI overgaan naar Node-versies die npm v12 bundelen
• Alternatieve pakketbeheerders: Yarn en pnpm kunnen dezelfde richting opgaan, wat dit het nieuwe normaal zou maken in het hele ecosysteem

Uw volgende stap

Begin hier
Voer npm approve-scripts --allow-scripts-pending uit op uw hoofdproject en zoek naar installatiescripts die uw team nooit heeft beoordeeld.

Snelle winst

• Voeg een native module smoke test toe aan CI voordat de hoofdtestsuite draait
• Schakel npm v12-gedrag in npm 11.16+ in op een feature branch en voer volledige CI uit om fouten vroeg te ontdekken

Diepgaande analyse

• Beoordeel uw allowScripts-items voor versiepinning en vermijd te brede goedkeuringen
• Stap over van langlevende npm-tokens naar trusted publishing met OIDC vóór de deadline van januari 2027

Nuttige bronnen

• npm approve-scripts documentatie - Officiële CLI-referentie voor de goedkeuringsworkflow
• npm deny-scripts documentatie - Weiger expliciet scripts voor pakketten die u heeft beoordeeld en afgewezen
• Trusted publishing setup guide - Stapsgewijze OIDC-configuratie voor grote CI-providers
• GitHub's npm security roadmap - Context over het volledige beveiligingsinitiatief dat deze wijzigingen aanstuurt

Het grotere plaatje

npm v12 is een verschuiving van impliciet vertrouwen naar expliciete goedkeuring. Meer dan een decennium lang werkte het JavaScript-ecosysteem op de aanname dat pakketauteurs willekeurige code konden uitvoeren tijdens installatie. Dat maakte veel legitieme workflows mogelijk, maar het hielp ook een wereld te ondersteunen waarin 454.600 kwaadaardige pakketten in één jaar kunnen verschijnen.

Er zijn echte kortetermijnkosten: kapotte builds, migratie-inspanning en extra CI-stappen. Het voordeel is langetermijn: code-uitvoering vereist nu een bewuste beslissing, niet alleen npm install.

Teams die nu beginnen, door hun allowScripts-lijsten te bouwen en native-module-verificatie toe te voegen in CI, zullen meestal soepel overgaan. Teams die wachten tot npm v12 hun productiepipeline raakt, zijn degenen die het meest waarschijnlijk een pijnlijke week doorbrengen met het ontwarren van "alles slaagde, maar niets werkt."