À compter du 8 décembre 2026, GitHub va désactiver les alertes générées par Dependabot sur la majorité des dépôts qui n’ont pas connu d’activité durant la dernière année. Cette mesure vise, selon l’annonce de GitHub, à maintenir la performance et la fiabilité du système face à la croissance rapide du volume de vulnérabilités découvertes. Rassurez-vous, les alertes existantes ne sont pas effacées ; elles sont archivées et peuvent être restaurées à tout moment.

Pour qu’un dépôt soit considéré comme actif, GitHub prend en compte plusieurs actions : un simple push vers n’importe quelle branche ou un tag, la création même du dépôt ou l’activation des alertes Dependabot. Si vous poussez du code dans le dépôt, les alertes sont automatiquement rétablies et le compteur d’un an repart à zéro. Cette règle s’applique à tous les plans de github.com et à GitHub Enterprise Cloud avec résidence des données, bien que GitHub Enterprise Server soit exclu de ce changement.

Ce nouveau mécanisme oblige les équipes à gérer activement leur code. Si un dépôt est mis en veille, les alertes de sécurité disparaissent temporairement, ce qui pourrait masquer des failles critiques si l’on ne surveille pas l’état de l’activité. En parallèle, les administrateurs conservent des moyens sophistiqués pour éviter cette désactivation. Un dépôt bénéficiant d’une configuration de sécurité imposée qui active Dependabot ne sera pas touché par cette pause.

Maîtriser la sécurité à l’échelle de l’organisation

Pour les grandes structures, la gestion des alertes ne se limite plus à un simple interrupteur. GitHub permet de bâtir des configurations de sécurité personnalisées, une fonctionnalité utile pour répondre aux exigences de conformité spécifiques à une entité donnée. On peut créer des ensembles d’options d’activation pour les produits de sécurité de GitHub, comme Code Security ou Secret Protection.

Ces configurations permettent, par exemple, de définir finement comment Dependabot doit opérer au sein d’un ensemble de dépôts. Dans le cadre de ces réglages avancés, il est possible de choisir si l’on veut activer, désactiver, ou conserver l’état actuel des alertes de dépendance. On y trouve d’autres options importantes, telles que l’analyse de graphe de dépendances ou l’analyse de la portée (reachability analysis).

Il y a aussi la possibilité d’appliquer ces règles de manière contraignante. En choisissant « Enforce » dans la section Politique, les propriétaires de dépôts sont empêchés de modifier les fonctionnalités qui ont été activées ou désactivées par la configuration organisationnelle. C’est un garde-fou utile quand la politique de sécurité doit être uniforme.

Affiner la gestion des notifications et des alertes

Au-delà du calendrier d’inactivité, les développeurs ont des leviers pour affiner la gestion des notifications. Les règles d’auto-triage de Dependabot permettent de gérer le flux d’alertes à grande échelle ; on peut décider d’ignorer automatiquement certaines notifications ou de les remettre en attente (snooze). De plus, ces règles permettent de spécifier quels types d’alertes doivent déclencher une pull request automatique.

Pour rappel, lorsque les alertes sont actives pour un dépôt, GitHub notifie par défaut les personnes disposant des droits d’écriture, de maintenance ou d’administrateur. Toutefois, il est possible d’élargir cette visibilité à d’autres équipes ou contributeurs. Les analyses de sécurité sont effectuées en lecture seule, ce qui signifie que GitHub ne divulgue jamais publiquement de dépendances non sécurisées pour un quelconque dépôt.

L’utilisation de fonctionnalités avancées telles que Secret Protection ou Code Security sur des dépôts privés ou internes implique des coûts, car ces options requièrent des licences GitHub Advanced Security.

Sources

• Configuring Dependabot alerts – GitHub Docs, docs.github.com
• Creating a custom security configuration – GitHub Docs, docs.github.com
• Dependabot alerts will pause on inactive repositories, GitHub, 10 novembre 2026