Un director node_modules instalat direct pe server aduce cod pe care nu l-ai auditat, scripturi care rulează cu drepturile aplicației și versiuni care nu coincid cu cele testate. După valul de pachete compromise din 2025, întrebarea nu mai e teoretică.
Un npm install rulat pe producție descarcă sute de pachete și execută scripturile lor preinstall și postinstall cu utilizatorul aplicației. Dacă unul e compromis, atacatorul are acces la variabilele de mediu, la fișierele .env și la rețeaua internă. Fără lockfile respectat strict primești versiuni diferite de cele testate în CI, deci un bug de pe server nu se reproduce nicăieri. Cache-ul npm poate păstra token-uri de registru privat, iar devDependencies aduc compilatoare și unelte de test pe o mașină care ar trebui să ruleze doar aplicația.
npm ci refuză să ruleze fără package-lock.json, șterge node_modules și instalează exact versiunile din lockfile, deci obții același arbore ca în CI. --omit=dev exclude devDependencies. --ignore-scripts oprește preinstall și postinstall, vectorul folosit de Shai-Hulud în noiembrie 2025. Nici așa nu elimini riscul supply-chain: chalk și debug erau dependențe de producție când au fost compromise. Controlul real e să nu instalezi deloc pe server, ci să construiești o singură dată în CI, unde scanezi pachetele.
OUG 155/2024, care transpune NIS2 și e aprobată prin Legea 124/2025, cere entităților înregistrate la DNSC măsuri pentru securitatea lanțului de aprovizionare, inclusiv pentru componentele software terțe. Un proces de build reproductibil, cu lockfile și fără instalări ad-hoc pe producție, e dovada cea mai simplă că știi ce cod rulează. Dacă aplicația prelucrează date personale, art. 32 GDPR cere măsuri tehnice adecvate, iar ANSPDCP verifică exact acest control la un incident.
| Pas | În CI | Pe producție | Motiv |
|---|---|---|---|
| Rezolvare versiuni (npm install) | Da | Nu | Versiunile se decid o singură dată, în lockfile |
| Scripturi preinstall / postinstall | Da, controlat | Nu | Vectorul atacurilor supply-chain din 2025 |
| Build (tsc, bundler) | Da | Nu | Compilatoarele nu au loc pe runtime |
| Rulare aplicație | Nu | Da | Doar artefacte și dependențe de producție |
npm ci --omit=dev --ignore-scriptsignore-scripts=true
fund=falseFROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts
COPY . .
RUN npm run build && npm prune --omit=dev
FROM node:22-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
CMD ["node", "dist/server.js"]Echipa rula npm install la fiecare deploy, direct pe server. După ce a mutat build-ul în GitHub Actions și a livrat doar directorul dist plus dependențele de producție, a dispărut o clasă întreagă de erori de tip „merge la mine, nu merge pe server”.
Un pachet de dezvoltare compromis a fost prins în CI de scanerul de dependențe, înainte de deploy. Pentru că serverul de producție nu avea npm și nici devDependencies, incidentul s-a oprit la pipeline, fără să atingă datele clienților.
Da. Multe pachete native nu mai compilează la instalare: sharp, de pildă, livrează binare prin dependențe opționale de la versiunea 0.33, deci --ignore-scripts nu îl afectează, dar --omit=optional l-ar rupe. Pentru pachetele care chiar au nevoie de scriptul lor, rulezi npm ci --ignore-scripts pe tot arborele, apoi npm rebuild <pachet> explicit. Așa lista scripturilor permise rămâne scurtă și cunoscută.
npm ci cere lockfile, șterge node_modules și instalează exact versiunile fixate, fără să modifice package-lock.json. npm install rezolvă versiunile din nou și poate rescrie lockfile-ul, deci două rulări pot da arbori diferiți. Pe producție și în CI folosești întotdeauna npm ci.
Da, pentru că numărul de pachete declarate direct nu spune nimic despre arborele complet, care ajunge frecvent la sute de dependențe tranzitive. Un Dockerfile multi-stage sau un pipeline simplu de build costă câteva ore o singură dată.
Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.