Ce que le guide de sécurité d'Astral révèle sur la puissance des SBOM
Ritesh Noronha
Il y a un dicton dans la communauté SBOM auquel nous revenons sans cesse : les SBOM ne sont pas une solution miracle. C'est vrai. Ils ne corrigeront pas votre organigramme, n'imposeront pas la 2FA et n'empêcheront pas un initié malveillant de publier une mauvaise version.
Mais après avoir lu la remarquable analyse détaillée d'Astral sur la manière dont ils sécurisent Ruff, uv et ty, quelque chose nous a frappés : dans notre analyse, environ 60 % des pratiques qu'ils décrivent peuvent être directement mises en œuvre, renforcées ou rendues auditables grâce aux SBOM, aux attestations et aux artefacts connexes de la chaîne d'approvisionnement.
Ce n'est pas tout. Mais c'est beaucoup — surtout quand on considère que la plupart de ce qu'Astral fait aujourd'hui nécessite une connaissance institutionnelle approfondie, une revue manuelle et des outils sur mesure que peu de projets peuvent reproduire.
Voici notre analyse des points où les SBOM recoupent les pratiques d'Astral, de ceux où ils ne les recoupent pas, et des raisons pour lesquelles cette estimation compte davantage que le reste qui dépend encore de contrôles humains et organisationnels.
Visibilité des dépendances : la base
La section la plus native SBOM de l’article d’Astral porte sur la sécurité des dépendances. Ils décrivent l’utilisation de Dependabot et Renovate pour les mises à jour, le maintien de liens sociaux avec les mainteneurs en amont, une approche prudente quant à l’ajout de nouvelles dépendances, et même le soutien financier aux projets dont ils dépendent via leur OSS Fund.
Tout cela commence par une question fondamentale : de quoi dépendez-vous réellement ?
Un SBOM peut y répondre, s’il est généré avec une couverture suffisante. Un document CycloneDX ou SPDX bien produit pour uv ne se contente pas de lister les dépendances Cargo directes — il peut capturer les dépendances transitives, les bibliothèques vendorisées, les outils de build et les composants spécifiques à la plateforme que l’audit manuel a tendance à manquer. Chez Interlynk, notre plateforme de gestion des SBOM ingère ces documents et offre une visibilité continue sur le graphe de dépendances, ce qui permet de :
Suivre les tendances du nombre de dépendances au fil des versions (réduisez-vous réellement votre surface d’attaque ?)
Signaler les composants qui introduisent des blobs binaires ou qui entraînent des dépendances transitives excessives
Identifier les projets en amont orphelins ou non maintenus avant qu’ils ne deviennent des risques
Prioriser les projets en amont qui méritent un soutien financier en fonction de leur criticité réelle dans votre arbre de dépendances
Ce qu’Astral fait grâce aux connaissances institutionnelles et aux liens sociaux, les SBOM peuvent le rendre plus reproductible et vérifiable — ce qui est particulièrement important à mesure que les organisations dépassent la capacité d’une seule équipe à conserver des modèles mentaux de leur chaîne d’approvisionnement.
Périodes de refroidissement des dépendances : une politique que les SBOM peuvent appliquer
L’une des pratiques les plus intéressantes décrites par Astral est le délai de dépendance (« dependency cooldowns ») — retarder délibérément l’adoption de nouvelles versions de dépendances afin d’éviter la période où des paquets temporairement compromis sont les plus dangereux. Ils soulignent que Renovate, Dependabot et uv prennent tous en charge ces délais.
Il s’agit d’une politique de gestion des risques que les SBOM peuvent aider à rendre applicable. Une plateforme comme Interlynk récupère directement les métadonnées de publication les plus récentes depuis les gestionnaires de paquets — PyPI, crates.io, npm et d’autres — et peut définir des politiques qui signalent ou bloquent les composants adoptés trop tôt après leur publication. Plutôt que de s’appuyer uniquement sur des configurations Renovate ou Dependabot qui peuvent dériver ou être contournées, cela crée une couche d’application continue et auditable : si un composant de votre SBOM a été publié il y a 12 heures et que votre politique de délai exige 72 heures, la politique peut le détecter tant que le composant et la version sont capturés et que les métadonnées de publication sont disponibles.
Intégrité des versions : là où les SBOM et les attestations convergent
La section sécurité des versions d'Astral décrit les attestations Sigstore, les versions immuables, le Trusted Publishing et les sommes de contrôle intégrées dans leur installateur autonome. Ce sont tous des mécanismes permettant d'établir qu'un artefact est authentique — qu'il provient d'un processus de build connu et qu'il n'a pas été altéré.
Les SBOM s'intègrent naturellement dans cette chaîne. En pratique, l'artefact est généralement le sujet de l'attestation, tandis que le SBOM est joint ou référencé comme la déclaration signée concernant cet artefact. Bien fait, cela répond simultanément à trois questions :
Que contient cet artefact ? (l'inventaire des composants du SBOM)
D'où vient-il ? (l'identité du builder de l'attestation et la référence du workflow)
A-t-il été altéré ? (la signature cryptographique liant les deux)
Astral génère déjà des attestations Sigstore pour ses versions binaires et Docker. Associer celles-ci à des SBOM — et rendre ces SBOM disponibles via une plateforme de gestion — permettrait aux consommateurs en aval de vérifier non seulement qu'ils ont obtenu une version légitime de uv, mais aussi d'inspecter ce qui a été intégré dans cette version. Cela est particulièrement pertinent pour les utilisateurs d'Astral dans les secteurs réglementés où la documentation de provenance n'est pas facultative.
Chez Interlynk, c'est fondamental.
Le CI/CD comme chaîne d’approvisionnement : le SBOM de build
Une grande partie du travail de sécurité le plus poussé d’Astral cible leurs pipelines CI/CD — épinglage par hachage des GitHub Actions, examen manuel des actions pour les décisions modifiables, isolation des secrets dans les environnements de déploiement, interdiction des déclencheurs de workflow dangereux. Ce sont des tâches exigeantes en main-d’œuvre et en compétences élevées.
CycloneDX a introduit formulation dans la version 1.5 et a continué à l’étendre depuis, donnant au format un moyen de décrire les pipelines de build sous forme de données structurées — les outils, actions, environnements et configurations impliqués dans la production d’un artefact. Cela en est encore aux débuts dans l’écosystème, mais la direction est claire : les processus de build eux-mêmes sont des composants de la chaîne d’approvisionnement et doivent être inventoriés comme tels.
Un SBOM qui inclut des données de formulation pourrait rendre certaines parties du durcissement CI/CD d’Astral plus auditables par les consommateurs en aval, là où les outils le permettent. Au lieu de s’appuyer entièrement sur le récit d’un projet, les consommateurs pourraient examiner des métadonnées de build structurées aux côtés d’autres artefacts de la chaîne d’approvisionnement. Cela crée aussi de la responsabilité : si votre SBOM de build montre une action non épinglée, votre score de qualité SBOM baisse — ce qui est exactement le type de signal que notre outil de qualité SBOM sbomqs est conçu pour mettre en évidence.
Gestion des vulnérabilités au cœur des dépendances
Astral décrit le maintien de liens sociaux avec des projets comme la Python Security Response Team et PyPA afin de partager des informations sur les vulnérabilités au-delà des frontières des projets — par exemple, lorsqu’un signalement concernant pip affecte également uv.
Il s’agit d’un processus social qui résout un problème de données. Avec les SBOM, la corrélation des vulnérabilités entre projets devient beaucoup plus systématique. Si pip et uv partagent tous deux un composant commun, et que ce composant possède un CVE, une plateforme de gestion des vulnérabilités compatible SBOM peut signaler les deux projets simultanément. Cela ne remplace pas les listes de diffusion, les relations de confiance ou la divulgation coordonnée, mais cela réduit la part de dépendance à leur égard.
Chez Interlynk, notre couche de renseignement sur les vulnérabilités fait exactement cela. Nous mettons en correspondance les composants SBOM avec la NVD, l’OSV et les avis des éditeurs à l’aide des PURL et des CPE, et nous traitons les cas limites difficiles — faux positifs liés aux backports de distributions, forks vendorisés avec un versionnage non standard, lacunes de couverture CPE pour les composants embarqués et de niche — qui rendent la correspondance naïve des vulnérabilités peu fiable.
Le VEX (Vulnerability Exploitability eXchange) ajoute ici une couche supplémentaire. Lorsqu’Astral détermine qu’un CVE dans une dépendance n’affecte pas réellement uv parce que le chemin de code vulnérable n’est pas atteignable, cette évaluation peut être capturée sous forme de déclaration VEX jointe au SBOM. Cela transforme une décision de triage ponctuelle en un artefact réutilisable et lisible par machine, dont bénéficie chaque consommateur en aval.
Les 40 % restants : ce que les SBOM ne couvrent pas — et pourquoi c’est justement le but
C’est ici que l’honnêteté du « pas une solution miracle » prend toute son importance. Dans notre analyse, une part substantielle de la posture de sécurité d’Astral se situe clairement en dehors du périmètre des SBOM :
Contrôles organisationnels — Imposer la 2FA, limiter les privilèges d’administration, interdire aux administrateurs de contourner les protections. Ce sont des problèmes de gestion des identités et des accès.
Politiques de déclenchement CI/CD — Interdire
pull_request_targetetworkflow_runà l’échelle de l’organisation. Cela relève de la gouvernance de la plateforme.Approbation à deux personnes pour les mises en production — Un contrôle de processus humain qu’aucun format de document ne peut remplacer.
Pas de mise en cache dans les builds de publication — Une décision de politique de build.
Isolation de GitHub App — Un modèle architectural pour séparer les opérations privilégiées du CI/CD.
Les SBOM ne prétendent pas résoudre ces problèmes, et quiconque vous dit le contraire vend quelque chose. Le bon modèle mental est celui des couches : les contrôles organisationnels garantissent la sécurité du processus, les SBOM documentent le contenu, les attestations authentifient les affirmations concernant les artefacts, et la gestion des vulnérabilités évalue si ce contenu est sûr. Chaque couche renforce les autres. Aucune couche, à elle seule, n’est suffisante. Mais sans la couche SBOM, les autres couches en disent moins sur ce qui se trouve réellement à l’intérieur de l’artefact que vous sécurisez.
La vue d’ensemble : 60 % c’est beaucoup
Ce qui rend le billet d’Astral impressionnant est aussi ce qui le rend sobre : l’ampleur des efforts manuels, des connaissances institutionnelles et des outils sur mesure nécessaires pour sécuriser un projet open source bien doté en ressources. La plupart des projets — en particulier dans les domaines du firmware embarqué et de l’IoT avec lesquels nous travaillons chez Interlynk — n’ont pas les ressources pour reproduire cela.
Les SBOM ne vous mèneront pas à 100 %. Rien ne le fera. La sécurité est faite de couches, et quiconque promet une solution miracle ignore la part qui nécessite encore du jugement humain, de la discipline organisationnelle et des contrôles au niveau de la plateforme.
Mais la partie que les SBOM couvrent — visibilité des dépendances, corrélation des vulnérabilités, provenance des versions, application des périodes de refroidissement, auditabilité des builds, triage piloté par VEX — représente la partie de la sécurité de la chaîne d’approvisionnement qui peut être automatisée, mesurée et surveillée en continu plutôt que de reposer sur des efforts individuels héroïques. Et pour la grande majorité des projets qui ne peuvent pas égaler l’investissement d’Astral, c’est souvent la différence entre avoir une posture de sécurité et n’avoir qu’un espoir.
Les SBOM ne sont pas une solution miracle. Ils sont la fondation qui rend tout le reste vérifiable.