A partir de 2024, nous avons de plus en plus d’avis de sécurité concernant Python. La plupart du temps il s’agit de composants serveurs, de modules exotiques ou expérimentaux, qui ne touchent pas les programmeur mainstream, mais il ne faudrait pas rater une vulnérabilité concernant un composant majeur. Le problème avec les mises à jour Python c’est qu’elles peuvent littéralement ‘casser’ l’environnement de développement, provoquant des incohérences entre scripts, composants (par exemple mamba, libmambapy …) et modules. Ce type de mauvaise expérience présente un risque non négligeable d’occurrence, avec un risque de blocage de la production.

Article édité en Janvier 2026.

1. Les avis de sécurité

Il existe quelques sources publiques pour être informés des avis de sécurité, notamment le CERT-FR (Computer Emergency Response Team) ou le CERT-EU. Mais avec le risque d’une submersion d’informations, car il ne me semble pas qu’il y ait un outil de recherche évident. Une première option serait de récupérer et filtrer les flux RSS proposés par les deux sites. Mais nous n’en aurons pas besoin car les avis du CERT font ouvent référence à plusieurs vulnérabilités de Python et à d’autres sources :

• La liste security-announce@python.org [ https://mail.python.org/archives/list/security-announce@python.org/ ] qui informe sur les avis de sécurité affectant Python et pip.
• Le site CVE (Common Vulnerabilities and Exposures)  qui est un dictionnaire [ https://www.cve.org/ ] regroupant des vulnérabilités informatiques, il est possible de faire une recherche (par exemple avec le mot clé ‘Python’), mais l’avenir de ce site semble incertain (cf. Wikipedia).
• Une alternative au CVE est le site EUVD (EU Vulnerability Database) qui est Européen [ https://euvd.enisa.europa.eu/ ]. EUVD permet également de faire une recherche par mot clés, mais qui réfère souvent à des avis CVE.

Et j’en oublie certainement, si nous travaillons dans une organisation qui diffuse les avis par une chaine SSI c’est c’est plus facile, mais pour les autres il faudra avoir une démarche un peu plus active, d’où l’intérêt de ces pointeurs.

2. Une procédure de mise à jour

Une fois qu’une mise à jour a été décidée, il faut être très prudents. Il faut savoir aussi que les risques concernent à la fois les mises à jour ou des installations. Par défaut les commandes de mise à jour (en utilisant le canal conda-forge) sont :

• Pour conda nous avons les commandes : conda update --override-channels -n prod -c conda-forge --all pour une mise à jour et conda install --override-channels -n base -c conda-forge paquetage pour une installation de paquetages.
• Et pour mamba nous avons les commandes mamba update --all pour une mise à jour et mamba install --yes paquetage  pour une installation.

Ces commandes sont reprises dans les scripts install-base ou install-prod en mode mise à jour ou installation.

Si la mise à jour concerne une version majeure de Python (par exemple 12 à 14), je ne joue pas aux mises à jour, je préfère installer Python avec la nouvelle version, une fois que les disponibilités et les dépendances possibles entre paquetages ont été analysées. La question se pose si nous utilisons une sous-version intermédiaire de Python, susceptible de se mettre à jour. Par exemple une version 3.12.8 alors qu’il existe des sous versions ultérieures de la 3.12 (par exemple 3.12.12).

Dans ce cas il va falloir appliquer une série de commandes : conda config puis conda init. La dernière commande va afficher une série de scripts ou de fichiers qui sont vérifiés et éventuellement mis à jour par le système. S’il y a des modifications dans ces fichiers, il faudra quitter le shell, puis le relancer, dans le même environnement, puis utiliser la commande conda update conda.

Cette procédure en 3 étapes peut régler beaucoup de problèmes lors des installations ou des mises à jour de paquetages. Notamment des dépendances non résolues, des problèmes avec mamba, des scripts cassés …

Une fois que ce premier travail est fait, une mise à jour générale des paquetages peut être déclenchée. Si nous appliquons correctement cette procédure, les mises à jour ou les l’installations ont plus de chance d’aboutir. Dans l’exemple, en fin de processus, nous disposons d’un Python 3.12.12 (terminale) à partir d’une installation initiale en 3.12.8.

3. Conclusion

Au delà des questions de sécurité, j’ai constaté que parfois, ce type d’installation marche mieux qu’une installation directe en 3.12.12, encore une subtilité liée à des environnements complexes avec beaucoup d’interdépendances.