Pourquoi tout le monde devrait utiliser un cooldown des dépendances

• Le cooldown des dépendances (dependency cooldown) est une mesure de sécurité simple et efficace qui peut atténuer la plupart des attaques de la chaîne d’approvisionnement open source
• Les attaquants compromettent généralement des projets open source populaires pour diffuser du code malveillant, mais, dans la majorité des cas, la fenêtre d’exposition des attaques est courte, souvent inférieure à une semaine
• En configurant un cooldown qui impose une attente après la publication d’une nouvelle version (par exemple 7 jours), on peut réduire fortement le risque d’infection lié aux mises à jour automatiques
• Dependabot, Renovate, pnpm, etc. prennent déjà en charge nativement cette fonctionnalité de cooldown, avec une configuration simple et sans coût supplémentaire
• Si ce mécanisme est fourni par défaut au niveau des gestionnaires de paquets, il peut contribuer à renforcer la sécurité de la chaîne d’approvisionnement tout en réduisant les alertes inutiles

---

Structure et problèmes des attaques de la chaîne d’approvisionnement

• La plupart des attaques de la chaîne d’approvisionnement (supply chain attack) suivent le même schéma
  • l’attaquant obtient un accès en exploitant le vol d’identifiants d’un projet open source populaire ou des vulnérabilités CI/CD
  • il téléverse des modifications malveillantes sur des canaux de distribution (PyPI, npm, etc.)
  • les utilisateurs installent la version infectée à cause des mises à jour automatiques ou d’un verrouillage de version insuffisant
  • un fournisseur de sécurité détecte le problème et émet une alerte, puis le registre de paquets supprime la version concernée
• L’intervalle entre les étapes (1) et (2) est long, mais les étapes (2) à (5) sont gérées en quelques heures à quelques jours, ce qui laisse une courte période d’activité aux attaquants
• Fenêtre d’opportunité observée sur des cas majeurs des 18 derniers mois
  • xz-utils : environ 5 semaines
  • Ultralytics : 12 heures (étape 1), 1 heure (étape 2)
  • tj-actions : 3 jours
  • chalk : moins de 12 heures
  • Nx : 4 heures
  • rspack : 1 heure
  • num2words : moins de 12 heures
  • Kong Ingress Controller : environ 10 jours
  • web3.js : 5 heures
• Parmi ces cas, 8 ont eu une durée d’attaque inférieure à une semaine, et la plupart auraient pu être bloqués par un cooldown

Concept et efficacité du cooldown

• Le cooldown consiste à retarder l’utilisation d’une nouvelle dépendance pendant une durée définie après sa publication
  • pendant cette période, les fournisseurs de sécurité peuvent détecter si elle est malveillante
• Avantages
  • c’est une approche empiriquement efficace, capable de bloquer la majorité des attaques à grande échelle
  • la mise en œuvre est très simple et la plupart des outils permettent une configuration gratuite
  • exemple avec Dependabot

    version: 2
    - package-ecosystem: github-actions
      directory: /
      schedule:
        interval: weekly
      cooldown:
        default-days: 7
    

  • cela encourage de bons comportements chez les fournisseurs de sécurité : se concentrer sur une détection rapide plutôt que sur des alertes excessives ou la recherche de visibilité

Conclusion et recommandations

• Dans 8 cas sur 10, la durée de l’attaque était d’une semaine ou moins, et un cooldown de 7 jours aurait suffi à bloquer la plupart d’entre eux
• Avec un cooldown de 14 jours, tous les cas sauf xz-utils auraient pu être évités
• Le cooldown n’est pas une solution parfaite, mais c’est un moyen simple de réduire de 80 à 90 % le risque d’exposition
• Au-delà de Dependabot et Renovate, il faut aussi améliorer les choses pour que les gestionnaires de paquets intègrent nativement le cooldown par défaut
• La sécurité de la chaîne d’approvisionnement n’est pas seulement un problème technique, c’est aussi une question de structure de confiance sociale, mais le cooldown reste une mesure d’atténuation réaliste et utile