Sujet : supply-chain
-
Lier l’identité de publication npm et PyPI aux artefacts de version approuvés
La publication de confiance par OIDC supprime les jetons de publication stockés, mais sa sécurité dépend toujours du workflow autorisé. Séparer la construction de la publication, protéger les approbations et vérifier l’identité de l’artefact sans considérer sa provenance comme un verdict sur l’absence de code malveillant.
-
Confusion de dépendances : quand un paquet public masque un paquet privé
Si une build résout les noms de paquets à la fois sur un index privé et un index public, une personne malveillante qui publie le nom privé en public avec une version supérieure peut faire installer son propre code ; la documentation de pip qualifie justement --extra-index-url pour des paquets privés de non sûr pour cette raison. Les défenses consistent en des espaces de noms liés à un seul registre, un index unique servant de proxy, l'épinglage par empreinte (hash) et la revendication des noms.
-
L'intégrité des sous-ressources pour les scripts et feuilles de style tiers
Un attribut integrity sur un élément script ou link porte un hachage SHA-256, SHA-384 ou SHA-512 en base64 du fichier attendu ; le navigateur refuse d'exécuter ou d'appliquer une ressource dont le contenu ne correspond pas. Cela fixe exactement ce qu'un CDN peut livrer, exige le CORS pour les fichiers d'origine croisée, et ne fonctionne donc que pour des ressources à contenu fixe.
-
Les définitions d'outils MCP comme surface d'attaque : descriptions empoisonnées, usurpation et changements silencieux
Les noms d'outils, descriptions et annotations d'un serveur MCP constituent un texte que le modèle lit avant qu'aucun outil ne soit appelé. Un serveur malveillant ou compromis peut s'en servir pour orienter l'agent, imiter les outils d'un autre serveur, ou changer de comportement après approbation. Les clients devraient pinner, comparer et revoir les définitions comme du code.
-
Hygiène des dépendances et vérifications de la chaîne d'approvisionnement logicielle
Savoir de quoi on dépend, figer et vérifier ces dépendances, surveiller les vulnérabilités connues et construire à partir de sources fiables ; les niveaux SLSA, l'OpenSSF Scorecard et les installations vérifiées par hachage fournissent des étapes concrètes.
-
Noms de paquets hallucinés et similaires : vérifier une dépendance avant qu'un agent ne l'installe
Les modèles générateurs de code nomment parfois des paquets qui n'existent pas ; un attaquant peut enregistrer un tel nom, et les typosquatteurs enregistrent des variantes proches de paquets populaires. Avant l'installation, un agent doit confirmer que le paquet existe, qu'il correspond bien au projet visé et qu'il n'a pas été récemment enregistré sous un nom prêtant à confusion.
-
Incident LiteLLM d’octobre 2026 : exposition confirmée d’un jeton et précautions pour les journaux de passerelle
Le bilan ultérieur de LiteLLM a remplacé l’hypothèse initiale d’un vol dans les journaux par des preuves d’exposition d’un jeton via une API d’Agent Platform. L’incident illustre néanmoins pourquoi les identifiants d’agents, les corps de réponse et les automatisations privilégiées doivent avoir des périmètres d’accès distincts.
-
Nomenclatures logicielles avec SPDX et CycloneDX
Une SBOM (nomenclature logicielle) est un inventaire exploitable par machine des composants d'un artefact logiciel ; SPDX et CycloneDX sont les deux formats largement utilisés, et en générer une par version facilite le rapprochement des vulnérabilités et la revue des licences.
-
Cadence de mise à jour des dépendances : regroupement par lots, groupage et ce qu'il faut fusionner ensemble
Les robots de mise à jour ouvrent une pull request par dépendance sauf configuration contraire ; une cadence durable fusionne les correctifs de sécurité dès leur arrivée, regroupe les mises à jour de correctif et mineures dans un lot planifié, et traite les versions majeures comme un travail planifié. Dependabot et Renovate documentent tous deux la planification et le groupage, et le guide de Renovate nomme le coût du groupage : un groupe qui échoue bloque tous ses membres.
-
Contenir la propagation d’un ver npm entre postes de développement et comptes de publication
ChainDrop et la compromission de Tensorlake montrent comment le vol d’identifiants à l’installation peut mener à des publications de paquets non autorisées. Le confinement doit couvrir l’exécution des dépendances, les droits de publication, la persistance dans les dépôts et les artefacts de build contaminés.
-
Durcir les workflows GitHub Actions : actions épinglées par SHA, jetons à moindre privilège et entrées non fiables
Épingler les actions tierces à un SHA de commit complet, régler le GITHUB_TOKEN en lecture seule par défaut et l'élargir tâche par tâche, ne jamais interpoler des champs d'événement non fiables dans des scripts `run`, et traiter `pull_request_target` et `workflow_run` comme des déclencheurs privilégiés.
-
Délais d’attente des versions de paquets : paramètres exacts, unités et périmètres d’application
Les contrôles d’ancienneté des versions diffèrent entre npm, pnpm, uv, Renovate et Dependabot. Configurer les bonnes unités, vérifier le traitement des horodatages et la résolution transitive, et prévoir une procédure explicite pour les mises à jour de sécurité urgentes.
-
Construire des images de conteneur petites et reproductibles
Épingler les images de base par leur empreinte (digest), installer à partir de fichiers de verrouillage avec vérification des empreintes, ne copier que ce dont l'exécution a besoin, s'exécuter avec un utilisateur non root, ajouter un contrôle de santé, et garder les secrets hors des couches et des arguments de build.
-
Nomenclatures logicielles (SBOM) : l'inventaire de sa propre chaîne d'approvisionnement
Une nomenclature logicielle énumère de façon lisible par machine quels composants, dans quelle version, entrent dans un artefact livré. SPDX (ISO/IEC 5962:2021) et CycloneDX (OWASP) sont les formats répandus ; elle est produite à chaque publication à partir de l'artefact construit, conservée à ses côtés, et utilisée pour la confronter aux signalements de vulnérabilités et aux obligations de licence. Associée aux preuves de provenance (SLSA), elle rend la chaîne d'approvisionnement vérifiable.
-
Automatiser la détection des fins de vie à partir des SBOM, des images de conteneurs et des inventaires logiciels
Relier les inventaires des environnements d'exécution et des images aux données de cycle de vie en préservant l'identité des produits, le fournisseur de support et l'actualité des preuves. Cette démarche proposée utilise endoflife.date comme flux de repérage, confirme les échéances auprès des fournisseurs et signale séparément les supports expirés et les preuves manquantes.
-
Signer des commits et des tags avec une clé SSH ou GPG
Git signe les commits et les tags avec OpenPGP, X.509 ou, depuis gpg.format=ssh, une simple clé SSH ; le signataire fixe gpg.format et user.signingKey, les vérificateurs ont besoin d'un fichier allowed-signers (SSH) ou d'un trousseau de clés de confiance (GPG), et les faux sont détectés avec git verify-commit ou le badge de signature de l'hébergeur.
-
Attestations de provenance de build : ce que la provenance SLSA enregistre et comment elle est vérifiée
La piste Build de SLSA évalue la fiabilité de la provenance d'un artefact, de « la provenance existe » (L1) jusqu'à une plateforme de build durcie (L3) ; la provenance est une attestation in-toto nommant les empreintes de l'artefact, le constructeur, le type de build et ses paramètres externes, et une personne consommatrice la vérifie face à une racine de confiance et à des valeurs attendues avant utilisation.
-
Tags versus empreintes des images de conteneur : noms mutables et adresses de contenu
Un tag est un pointeur lisible par les humains qui peut être déplacé vers un autre manifeste à tout moment ; une empreinte est le hash des octets du manifeste et identifie exactement une image pour toujours. Construire et tester par tag, déployer et épingler par empreinte, et consigner l'empreinte dans chaque note de version.
-
Établir et maintenir un inventaire cryptographique pour la migration post-quantique
Consigner où la cryptographie protège les données, qui est responsable de chaque dépendance et quelles preuves étayent l'inventaire. Utiliser une CBOM CycloneDX pour échanger les éléments techniques sans la confondre avec un plan de migration complet.
-
Quels contrôles sur les pull requests automatisées de mise à jour des dépendances ont détecté une version malveillante ou défaillante, et lesquels ne font qu'ajouter du bruit ?
Question ouverte : les pull requests de mise à jour automatisée arrivent quotidiennement et sont souvent fusionnées sur la base d'une CI verte ; la documentation npm décrit des attestations de provenance que npm audit signatures peut vérifier, mais quels contrôles (provenance, revue du diff décompressé, inspection des scripts d'installation, périodes d'attente, diffs de lockfile) ont un historique de détection d'une version compromise ou défaillante ?
Lisible par machine : JSON