Dépendances

Le dépôt contient six projets Node.js avec chacun son package.json et son package-lock.json, plus des images Docker et des actions GitHub. Les mises à jour sont proposées automatiquement par Dependabot, les vulnérabilités sont bloquées par npm audit et Trivy en CI, et quelques dépendances restent à suivre à la main.

#Inventaire

La version de Node.js est fixée à la majeure 22 par .nvmrc, et chaque package.json exige >=22.12.0 (engines). Les images Docker du backend, du frontend web et de la blockchain locale partent de node:22-bookworm-slim (argument NODE_IMAGE).

La CI installe toujours avec npm ci : le package-lock.json fait foi, et une divergence avec le package.json fait échouer l'installation. Un fichier de verrouillage modifié doit donc être commité avec le package.json correspondant.

#Dependabot

La configuration est dans .github/dependabot.yml.

#Délai de publication

cooldown.default-days: 5 fait attendre cinq jours après la publication d'une version avant de la proposer. Une version compromise ou défectueuse est le plus souvent retirée de l'annuaire npm dans ce délai : c'est une protection contre les attaques par la chaîne d'approvisionnement, au prix de cinq jours de retard sur les correctifs. Un correctif de sécurité urgent se fait à la main, sans attendre Dependabot.

#Ce que Dependabot ne surveille pas

#Vulnérabilités

#En CI

--omit=dev limite l'audit aux dépendances embarquées en production. Une vulnérabilité dans un outil de développement (ESLint, Jest, TypeScript) n'est donc pas bloquante ; elle reste visible avec un npm audit complet et dans les alertes Dependabot de GitHub.

#Exception pour smart-contract

Le seuil est critique, et non haut, pour smart-contract/. La justification, consignée dans l'ADR 0004 (voir Smart contract et portefeuille intégré) :

• les alertes hautes viennent de dépendances transitives de @chainlink/contracts ;
• il s'agit des sources Solidity d'OpenZeppelin 4.x, que les contrats n'importent pas (ils importent OpenZeppelin 5.x), et d'outils JavaScript (ethers v5, ws, tmp) ;
• aucune n'est incluse dans le bytecode déployé, et aucune n'est exécutée par le backend, qui utilise ethers v6 et ses propres ABI JSON.

Cette exception doit être réexaminée à chaque mise à jour de @chainlink/contracts : si une alerte haute touche un fichier effectivement importé par BlockLucky.sol (VRFConsumerBaseV2Plus, VRFV2PlusClient, AutomationCompatibleInterface), elle doit être traitée comme bloquante.

#Exceptions documentées

Une vulnérabilité non corrigeable (aucune version corrigée publiée) ou sans impact réel ne se contourne pas en baissant un seuil. Elle se documente :

1. vérifier que le code vulnérable est atteignable depuis le code du projet ;
2. sinon, écrire la justification dans un ADR ou dans la pull request, avec le numéro d'alerte (GHSA ou CVE) ;
3. pour Slither, consigner le constat dans slither.db.json avec la justification dans Sécurité du contrat ;
4. prévoir une date de réexamen.

#Politique de mise à jour

#Pull requests Dependabot en attente

À la date de rédaction, les branches distantes dependabot/... montrent notamment des majeures, proposées hors des groupes : TypeScript 7 pour le web, le mobile et les contrats, @babel/core 8 et eslint-config-universe 16 pour le mobile, PostgreSQL 16 et Redis 8.10 pour Compose, nginx-unprivileged 1.31 pour l'Office de Tourisme. Elles sont à traiter une par une selon le tableau ci-dessus.

#Mettre à jour à la main

Dans le dossier du projet :

npm outdated
npm install <paquet>@<version>
npm run typecheck && npm run lint && npm test

Vérifier ensuite que seuls package.json et package-lock.json ont changé, et que l'audit passe :

npm audit --omit=dev --audit-level=high

#Ajouter une dépendance

Avant d'ajouter un paquet :

Pour le site de l'Office de Tourisme et le navigateur en général, aucun paquet servi depuis un CDN : la politique de sécurité de contenu le bloquerait. Le code tiers est copié dans le dépôt avec sa licence.