[{"data":1,"prerenderedAt":128},["ShallowReactive",2],{"seo-verification":3,"blog-securiser-chaine-approvisionnement-npm-ci-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"title":9,"excerpt":10,"readTime":11,"views":12,"isPinned":13,"publishedAt":14,"category":15,"categories":21,"featuredImage":23,"bgImage":24,"posterImage":25,"relatedSolution":23,"intro":26,"sections":27,"ctaTitle":73,"ctaBody":74,"ctaButton":75,"ctaUrl":76,"relatedPosts":77},202,"securiser-chaine-approvisionnement-npm-ci","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.",7,0,false,"2026-08-01T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":20},4,"Développement","developpement","bg-warning\u002F10 text-warning","dev",[22],{"id":16,"name":17,"slug":18,"color":19,"icon":20},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.",[28,32,42,45,67,70],{"type":29,"title":30,"body":31},"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":33,"title":34,"items":35},"ul","Mesures concrètes à mettre en place",[36,37,38,39,40,41],"**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":29,"title":43,"body":44},"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":46,"title":47,"steps":48},"steps","Durcir votre pipeline CI étape par étape",[49,52,55,58,61,64],{"title":50,"body":51},"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":53,"body":54},"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":56,"body":57},"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":59,"body":60},"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":62,"body":63},"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":65,"body":66},"É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":68,"body":69},"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":29,"title":71,"body":72},"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",[78,97,115],{"id":79,"slug":80,"title":81,"excerpt":82,"readTime":83,"views":84,"isPinned":13,"publishedAt":85,"category":86,"categories":91,"featuredImage":23,"bgImage":24,"posterImage":93,"relatedSolution":94},99,"gitea-vs-gitlab","Gitea vs GitLab : quelle forge Git self-hosted sur VPS ?","Gitea vs GitLab self-hosted : empreinte memoire, CI\u002FCD, registres et scalabilite compares pour choisir votre forge Git sur VPS.",8,263,"2026-03-13T00:00:00+00:00",{"id":87,"name":88,"slug":89,"color":90,"icon":89},5,"Comparatif","comparatif","bg-info\u002F10 text-info",[92],{"id":87,"name":88,"slug":89,"color":90,"icon":89},"\u002Fblog\u002Fcovers\u002Fgitea-vs-gitlab-poster.svg",{"categorySlug":95,"appSlug":96},"self-hosting","gitea",{"id":98,"slug":99,"title":100,"excerpt":101,"readTime":83,"views":102,"isPinned":13,"publishedAt":103,"category":104,"categories":109,"featuredImage":23,"bgImage":24,"posterImage":111,"relatedSolution":112},108,"securiser-vps-crowdsec","Sécuriser votre VPS avec CrowdSec","Deployez CrowdSec sur votre VPS pour bloquer les attaques grace a une detection comportementale et une blocklist communautaire mutualisee.",596,"2026-03-04T00:00:00+00:00",{"id":83,"name":105,"slug":106,"color":107,"icon":108},"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[110],{"id":83,"name":105,"slug":106,"color":107,"icon":108},"\u002Fblog\u002Fcovers\u002Fsecuriser-vps-crowdsec-poster.svg",{"categorySlug":113,"appSlug":114},"securite","crowdsec",{"id":116,"slug":117,"title":118,"excerpt":119,"readTime":83,"views":120,"isPinned":13,"publishedAt":121,"category":122,"categories":123,"featuredImage":23,"bgImage":24,"posterImage":125,"relatedSolution":126},43,"deployer-nodejs-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.",591,"2026-05-08T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":20},[124],{"id":16,"name":17,"slug":18,"color":19,"icon":20},"\u002Fblog\u002Fcovers\u002Fdeployer-nodejs-vps-poster.svg",{"categorySlug":18,"appSlug":127},"nodejs",1785606655162]