[{"data":1,"prerenderedAt":148},["ShallowReactive",2],{"seo-verification":3,"blog-securiser-chaine-approvisionnement-npm-ci-ma-fr":6,"promo-bar-likely":20},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-securiser-chaine-approvisionnement-npm-ci-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":20,"publishedAt":21,"updatedAt":22,"category":23,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":80,"ctaBody":81,"ctaButton":82,"ctaUrl":83,"relatedPosts":84},202,"securiser-chaine-approvisionnement-npm-ci",{"fr":10,"en":12,"ar":13,"es":14},"securing-your-npm-ci-supply-chain-after-asyncapi","تأمين-سلسلة-توريد-npm-في-ci-بعد-حادثة-asyncapi","proteger-la-cadena-de-suministro-npm-tras-asyncapi","Sécuriser votre chaîne CI npm après AsyncAPI","Lockfile, vérification de hashes, SLSA et SCA automatisé : comment durcir votre pipeline CI après l'incident AsyncAPI de juillet 2026.",4,1,false,true,"2026-08-01T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":17,"name":24,"slug":25,"color":26,"icon":27},"Développement","developpement","bg-warning\u002F10 text-warning","dev",[29],{"id":17,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fsecuriser-chaine-approvisionnement-npm-ci-poster.svg","En juillet 2026, plusieurs packages du projet AsyncAPI ont été publiés sur npm avec des signatures OIDC valides — les outils de détection habituels n'ont rien vu. Cet incident a démontré qu'une chaîne CI qui ne vérifie que le lockfile ou la signature reste vulnérable à une compromission amont. Voici comment ajouter les couches de contrôle qui manquaient.",[35,39,49,52,74,77],{"type":36,"title":37,"body":38},"h2","Ce que l'incident AsyncAPI a changé","Pendant deux semaines de juillet 2026, cinq versions de packages AsyncAPI ont circulé avec une provenance OIDC signée — un mécanisme introduit précisément pour garantir l'origine d'un package. Les attaquants avaient compromis le pipeline de publication, pas la clé de signature. Résultat : `npm audit signatures` retournait un résultat propre, et les gestionnaires de dépendances ne levaient aucune alerte. Cela change la manière dont on doit penser la sécurité des dépendances : la signature prouve l'intégrité du paquet au moment de sa publication, pas l'intégrité du processus qui l'a produit.",{"type":40,"title":41,"items":42},"ul","Mesures concrètes à mettre en place",[43,44,45,46,47,48],"**Politique --frozen-lockfile** — interdire toute modification silencieuse du package-lock.json en CI (`npm ci` l'impose nativement, `--frozen-lockfile` pour yarn\u002Fpnpm).","**Vérification des hashes en CI** — ajouter un job qui compare les hashes SHA-512 du lockfile aux registres npm et détecte toute divergence.","**SCA automatisé** — intégrer un scanner de composition logicielle (OWASP Dependency-Check, Trivy, Snyk) comme étape bloquante du pipeline.","**Provenance SLSA niveau 2 minimum** — lors de vos publications, générer et attacher les attestations SLSA ; lors de vos consommations, vérifier que les packages critiques en disposent.","**Surveillance des digests d'image** — ancrer chaque image Docker sur son digest sha256 plutôt que sur un tag flottant.","**Alertes sur les nouvelles versions non planifiées** — configurer Dependabot ou Renovate pour notifier toute version publiée hors de votre fenêtre habituelle.",{"type":36,"title":50,"body":51},"Ce que le lockfile garantit — et ce qu'il ne garantit pas","Le package-lock.json enregistre la version exacte et le hash de chaque dépendance résolue. Il empêche une montée de version silencieuse lors d'un `npm install` ultérieur. Ce qu'il ne fait pas : vérifier que le contenu du package correspondant n'a pas changé côté registry après sa résolution initiale, ni que le pipeline qui a produit le package était lui-même sain. Le lockfile est un instantané de ce que vous avez résolu un jour donné — pas une garantie sur la chaîne de fabrication amont.",{"type":53,"title":54,"steps":55},"steps","Durcir votre pipeline CI étape par étape",[56,59,62,65,68,71],{"title":57,"body":58},"Passer à `npm ci` et bannir `npm install` en CI","Remplacez tout `npm install` dans vos workflows par `npm ci`. La commande refuse de s'exécuter si le package-lock.json est absent ou diverge du package.json. Ajoutez `--ignore-scripts` si votre arbre contient des postinstall tiers non audités.",{"title":60,"body":61},"Activer `npm audit` en mode bloquant","Ajoutez `npm audit --audit-level=high` après `npm ci` et avant le build. En GitHub Actions, l'étape échoue si un résultat de sévérité élevée est détecté. Différenciez les dépendances de développement avec `--omit=dev`.",{"title":63,"body":64},"Vérifier les hashes avec `npm audit signatures`","Depuis npm 8.8, `npm audit signatures` vérifie que chaque package installé possède une signature valide enregistrée dans le registry. Exécutez cette commande après `npm ci`. Elle ne détecte pas les cas AsyncAPI (signature valide mais pipeline compromis), mais constitue un premier filet.",{"title":66,"body":67},"Intégrer un scanner SCA (Trivy ou OWASP Dependency-Check)","Ajoutez un job SCA indépendant dans votre workflow CI. Trivy analyse le package-lock.json directement (`trivy fs --scanners vuln .`) sans nécessiter d'installation des dépendances. Configurez-le pour échouer sur les CVE de score CVSS supérieur à 7.",{"title":69,"body":70},"Consommer et émettre des attestations SLSA","Pour vos propres packages publiés, activez la provenance SLSA dans votre workflow de publication (GitHub Actions slsa-framework\u002Fslsa-github-generator). Pour les dépendances tierces, vérifiez les attestations des packages critiques via l'API Sigstore.",{"title":72,"body":73},"Épingler les actions CI et images sur leur digest sha256","Dans vos fichiers .github\u002Fworkflows\u002F*.yml ou .gitlab-ci.yml, remplacez les tags flottants par des digests sha256. Un tag flottant peut pointer vers une image différente le lendemain d'une compromission du registry.",{"type":75,"body":76},"tip","Ne jamais patcher une dépendance directement en production en modifiant node_modules à la main : le lockfile divergerait, et le prochain déploiement depuis CI réintroduirait le package d'origine. Toute correction passe par le lockfile versionné, rejoué par la CI.",{"type":36,"title":78,"body":79},"Intégration dans votre workflow Git hébergé","Ces contrôles sont des étapes de pipeline, pas des habitudes manuelles : ils appartiennent à votre ci.yml (GitHub Actions) ou à votre .gitlab-ci.yml, déclenchés à chaque push et sur chaque pull request. Sur un dépôt auto-hébergé (Gitea, GitLab CE), les mêmes recettes s'appliquent. Protégez votre branche principale avec une règle de merge conditionnel à la CI verte, et bloquez les merges si l'un de ces jobs SCA échoue.","Des environnements CI isolés pour vos pipelines de build","Déployez vos runners CI sur un VPS Cloud dédié : isolation réseau, contrôle total des dépendances système, et aucune ressource partagée avec d'autres tenants.","Solutions pour développeurs","\u002Fsolutions\u002Fdeveloppeurs",[85,108,131],{"id":86,"slug":87,"slugs":88,"title":92,"excerpt":93,"readTime":94,"views":95,"isPinned":19,"noindex":19,"publishedAt":96,"updatedAt":97,"category":98,"categories":103,"featuredImage":30,"bgImage":31,"posterImage":105,"relatedSolution":106},99,"gitea-vs-gitlab",{"fr":87,"en":89,"ar":90,"es":91},"gitea-vs-gitlab-which-self-hosted-git-forge-on-a-vps","gitea-مقابل-gitlab-أي-منصة-git-مستضافة-ذاتيا-على-vps","gitea-vs-gitlab-que-forja-git-self-hosted-en-vps","Gitea vs GitLab : quelle forge Git self-hosted sur VPS ?","Gitea vs GitLab self-hosted en 2026 : licences, empreinte mémoire, CI\u002FCD, migration et sécurité comparés pour choisir votre forge Git sur VPS.",10,3,"2026-03-13T00:00:00+00:00","2026-10-20T23:18:08+00:00",{"id":99,"name":100,"slug":101,"color":102,"icon":101},5,"Comparatif","comparatif","bg-info\u002F10 text-info",[104],{"id":99,"name":100,"slug":101,"color":102,"icon":101},"\u002Fblog\u002Fcovers\u002Fgitea-vs-gitlab-poster.svg",{"categorySlug":25,"appSlug":107},"gitea",{"id":109,"slug":110,"slugs":111,"title":115,"excerpt":116,"readTime":17,"views":117,"isPinned":19,"noindex":19,"publishedAt":118,"updatedAt":22,"category":119,"categories":125,"featuredImage":30,"bgImage":31,"posterImage":127,"relatedSolution":128},108,"securiser-vps-crowdsec",{"fr":110,"en":112,"ar":113,"es":114},"securing-your-vps-with-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","proteger-vps-con-crowdsec","Sécuriser votre VPS avec CrowdSec","Déployez CrowdSec sur votre VPS pour bloquer les attaques grâce à une détection comportementale et une blocklist communautaire mutualisée.",2,"2026-03-04T00:00:00+00:00",{"id":120,"name":121,"slug":122,"color":123,"icon":124},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[126],{"id":120,"name":121,"slug":122,"color":123,"icon":124},"\u002Fblog\u002Fcovers\u002Fsecuriser-vps-crowdsec-poster.svg",{"categorySlug":129,"appSlug":130},"cybersecurity","crowdsec",{"id":132,"slug":133,"slugs":134,"title":138,"excerpt":139,"readTime":120,"views":18,"isPinned":19,"noindex":19,"publishedAt":140,"updatedAt":141,"category":142,"categories":143,"featuredImage":30,"bgImage":31,"posterImage":145,"relatedSolution":146},43,"deployer-nodejs-vps",{"fr":133,"en":135,"ar":136,"es":137},"deploy-a-nodejs-application-on-a-vps","نشر-تطبيق-nodejs-على-vps","desplegar-una-aplicacion-nodejs-en-un-vps","Déployer une application Node.js sur un VPS","Déployez une application Node.js en production sur un VPS : PM2, reverse proxy Nginx, SSL Let's Encrypt et démarrage automatique au boot.","2026-05-08T00:00:00+00:00","2026-11-08T01:13:12+00:00",{"id":17,"name":24,"slug":25,"color":26,"icon":27},[144],{"id":17,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-nodejs-vps-poster.svg",{"categorySlug":25,"appSlug":147},"nodejs-stack",1794270783372]