Python résistant aux logiciels malveillants sans les devinettes

Nous aimons Python. C'est l'un des langages de programmation les plus populaires de la planète, et ce pour une bonne raison : il est lisible, flexible, puissant et soutenu par l'une des communautés open-source les plus dynamiques qui soient. PyPI est un triomphe de l'infrastructure publique - il héberge plus d'un demi-million de paquets - un témoignage incroyable de la façon dont l'open source peut s'étendre et favoriser l'innovation.

Mais cette échelle s'accompagne d'une certaine complexité. Et aujourd'hui, la complexité est un problème de sécurité.

L'open source peut être sûr. Mais se contenter par défaut de "faire confiance à ce qui se trouve sur PyPI" n'est plus suffisant, surtout lorsque les attaquants savent que chaque système de construction, carnet de notes et pipeline CI n'est qu'à une installation de pip d'une mauvaise journée.

Les attaquants l'ont remarqué. Ils n'ont pas besoin de jours 0 quand tout ce qu'il faut, c'est compromettre les informations d'identification d'un mainteneur, ou télécharger un paquet qui semble juste assez proche de quelque chose de populaire.

C'est pourquoi nous avons créé les bibliothèques Chainguard pour Python : pour changer la façon dont les gens construisent, distribuent et consomment les paquets open-source - en commençant par Python.

L'Open Source n'est pas insécurisé, mais les valeurs par défaut le sont

Voici la réalité actuelle : Le système d'empaquetage de Python n'a pas été conçu en tenant compte des menaces modernes qui pèsent sur la chaîne d'approvisionnement. Ce n'est pas une critique à l'égard de PyPI ou de ses responsables - ils ont accompli un travail incroyable pour faire évoluer l'infrastructure et lutter contre les abus - mais le modèle de menace a changé.

Mais nous pensons également que le choix par défaut de "tout ce qui se trouve sur PyPI" n'est plus suffisant, en particulier lorsque les pipelines tirent le code automatiquement, que les dépendances transitives s'étendent sur 12 couches et qu'une seule version compromise peut infecter des milliers de systèmes avant qu'elle ne soit remarquée.

Ce n'est pas de la théorie. D'après nos recherches, la reconstruction des paquets à partir des sources et la vérification de la provenance auraient empêché 98 % des paquets malveillants connus d'être utilisés en production.

Nous avons donc entrepris d'inverser le modèle. Au lieu de "détecter et répondre", nous nous assurons que les paquets malveillants n'entrent jamais dans la production.

Sécuriser chaque étape de la chaîne d'approvisionnement

Voici comment cela fonctionne :

• Nous reconstruisons les paquets Python les plus populaires à partir de leurs dépôts en amont. Nous nous assurons que chaque paquet a un code source disponible que vous pouvez lire et auditer.

• Nous le faisons dans un environnement de construction durci SLSA de niveau 2, avec une isolation et une reproductibilité totales.

• Nous attachons un SBOM signé à chaque paquet que nous publions, afin que vous sachiez exactement ce qu'il contient et d'où il vient.

• Nous verrouillons chaque étape du cycle de construction et de distribution : approvisionnement, compilation, signature, conditionnement et publication.

Si nous ne pouvons pas trouver un tag ou un commit correspondant à une version dans la version amont d'un paquet, nous ne le construisons pas. C'est aussi simple que cela.

Quand la confiance s'effondre : les leçons de num2words

Vous avez peut-être vu la récente compromission du paquet num2words. Il s'agit d'un utilitaire bien connu qui convertit les nombres en mots (pensez à 42 → "quarante-deux"). Au début du mois, un acteur malveillant a eu accès au compte PyPI du mainteneur et a publié une version rétroactive qui a exfiltré les informations d'identification des environnements de CI. StepSecurity présente l'analyse complète ici.

Voici la partie la plus importante : cette version malveillante n'a jamais été introduite dans Chainguard Libraries. Nous avons essayé de trouver un tag ou un commit dans le repo du projet en amont ; cependant, aucun tag de ce type n'existait, et par conséquent, nous n'avons pas publié cette version. C'est aussi simple que cela.

Pas d'alerte. Pas de brouillage de patch.

Si vous utilisez les bibliothèques Chainguard pour Python, vos constructions sont propres. Votre risque est minimisé. Et vous ne serez pas réveillé par une nouvelle alerte de la chaîne d'approvisionnement.

Pas seulement sécurisées par défaut - construites pour être vérifiables

Avec les bibliothèques Chainguard pour Python, vous n'obtenez pas seulement des bibliothèques plus sécurisées. Vous obtenez :

✅ des paquets reconstruits à partir des sources

✅ une provenance vérifiable

✅ des constructions conformes à SLSA

✅ des SBOM signés

Et le plus important : des paquets résistants aux logiciels malveillants auxquels vous pouvez réellement faire confiance.

Il ne s'agit pas d'une enveloppe. Il s'agit d'une refonte fondamentale de la façon dont les bibliothèques Python sont construites et livrées - fondée sur les principes de l'open-source, mais avec des mécanismes de livraison renforcés.

Nous avons prouvé que cela fonctionnait à grande échelle en Java. Nous le faisons maintenant en Python - et d'autres écosystèmes sont à venir. Et avec les bibliothèques Chainguard, vous obtenez un système qui fonctionne parce qu'il est ennuyeux - des constructions prévisibles, une provenance vérifiable, et rien que vous n'ayez demandé.

Vous écrivez du Python. Nous nous assurons qu'il peut être exécuté en toute sécurité. Contactez-nous dès aujourd'hui pour en savoir plus.