OWASP SPVS : Leçons tirées de la sécurisation des logiciels Pipeline

Vérifiez l'intégralité du logiciel PipelineLes frictions, les réussites et les leçons tirées de l'adoption d'OWASP SPVS

Le OWASP Secure Pipeline Vérification Standard (SPVS) a atteint la version 1.0 en octobre 2025. Nous avons décidé d'utiliser standard dans l'ensemble de notre organisation pour les raisons expliquées ci-dessous.

Cet article relate honnêtement pourquoi nous avons entrepris cette aventure, comment nous l'avons adaptée, ce qui a été difficile, et ce que nous recommandons à quiconque emprunte le même chemin.

Pourquoi un Pipeline Standardet pourquoi maintenant

Pendant des années, les pirates informatiques ont ciblé les applications une par une.

Mais leurs tactiques ont changé.

Pourquoi faire des compromis sur une application quand on peut en faire des compromis sur l'ensemble ? pipeline qui en construit beaucoup ?

Sonatype suivi sur 512 000 nouveaux paquets malveillants rien qu’en 2024 156% d'augmentation d'une année sur l'autreEt chaque incident majeur de ces dernières années a touché un maillon différent de la chaîne de distribution des logiciels.

Chaque attaque exploitait une partie différente du pipeline:

• Créer des environnements
• Outils CI
• Dépendances
• Identifiants de développeur
• confiance du responsable
• Références modifiables aux artefacts

La plupart des organisations réagissent par des contrôles ponctuels.

• Un scanner en CI
• L'authentification à deux facteurs (2FA) sur le fournisseur d'identité
• Protection des succursales main

Nous aussi.

Ce qui manquait, c'était un moyen de demander :

Sommes-nous systématiquement couverts ?

Au lieu de:

Avons-nous pensé à réactiver X après le dernier incident ?

Étant donné que les fournisseurs de solutions de sécurité applicative sont directement visés, la compromission d'un seul fournisseur peut affecter tous les clients qui font confiance à ses produits. Pour nous, la pression est forte pour passer de contrôles réactifs à des contrôles systématiques. pipeline La protection n'était pas théorique.

Nous avons alors pu en faire l'expérience directe.

En mars 2026, le xygeni-action GitHub Action compromis impliqué:

• Clé privée d'une application GitHub compromise
• Une étiquette mutable empoisonnée
• Un implant C2 déguisé en télémétrie

Les règles de protection des succursales et autres contrôles techniques ont fonctionné, mais cela n'a pas suffi.

Bien que l'impact réel sur les clients ait été nul, les dommages causés à notre réputation exigent de la transparence et une réponse structurelle. Nous avons compris qu'en tant que fournisseur de solutions de sécurité logicielle, nous devions radicalement abandonner les contrôles ponctuels et ad hoc au profit d'une protection systématique de nos logiciels. pipelines.

Cela nous a motivés à adopter le OWASP SPVS standard comme projet prioritaire.

Qu’est-ce qu’une SPV et pourquoi sa structure est importante ?

L'histoire de l'origine est simple.

Lors de la conférence LASCON 2023, Farshad Abasi et Cameron Walters n'arrêtaient pas de se poser la même question :

Où se trouve l'ASVS pour pipelines?

OWASP ASVS avait donné à la sécurité des applications une approche complète et vérifiable standardIl n'existait rien d'équivalent pour CI/CD.

Il existait des cadres et des outils utiles, mais chacun ne couvrait qu'une partie du problème :

Chacun recouvrait une pièce.

Aucun ne couvrait l'ensemble.

Cette conversation a donné lieu à deux années de travail. En octobre 2025, le groupe de travail SPVS a publié v1.0:

• 127 exigences
• Couvrir l'intégralité du cycle de vie :
  • Plan
  • Développent
  • Intégrer
  • Libération
  • Fonctionner
• Organisé en trois niveaux de maturité :
  • Niveau 1 Fondamental
  • L2 Standard
  • Niveau 3 Avancé
• Associé à :
  • NISTSP 800-53
  • OWASP CI/CD Top 10
  • CWE

L'essentiel, c'est la structure.

Comme l'expliquent les auteurs de SPVS :

Vérifiez l'intégralité de votre texte pipelineIl ne s'agit pas d'un seul élément. C'est là que la plupart des organisations rencontrent des difficultés. Elles analysent les dépendances, mais négligent la gouvernance des versions. Elles signent les artefacts, mais ne modélisent pas les menaces qui pèsent sur eux. pipeline Ils supervisent l'architecture. Ils contrôlent la production, mais pas les environnements de compilation.

Telle était la thèse qui justifiait nos efforts.

Les points forts à un stade ne compensent pas les faiblesses à un autre. Un seul maillon suffit à briser la défense.

Un cycle de vie standard vous oblige à tous les vérifier, et le L1 → L2 → L3 La progression permet de le faire sans faire bouillir l'océan.

SPVS ne remplace ni SLSA, ni S2C2F, ni Scorecard, ni Sigstore. Il vous fournit le cadre qui vous indique la place de chacun d'eux.

Adaptation du Standard à notre organisation

Notre première étape a consisté en un audit complet de notre organisation et de notre infrastructure logicielle par rapport à chaque exigence.

Nous avons consigné l'audit dans une feuille Google Sheets alimentée par les sources officielles. Exigences SPVS CSV .

Nous avons utilisé trois vues principales :

• matrice des exigences
  Statut et propriétaire par contrôle.
• Carte thermique par dépôt
  Visibilité des lacunes au niveau du référentiel.
• Dashboard par étape et niveau
  Progrès réalisés dans les phases de planification, de développement, d'intégration, de déploiement et d'exploitation.

Nous avons également étendu notre réseau interne Directives techniques pour les logiciels sécurisés Pipelines pour couvrir chaque étape, de la planification à l'exécution.

Nous avons constaté que nous avions déjà largement atteint le niveau de maturité. L2C’était rassurant, bien que pas surprenant pour une entreprise dont le métier est la sécurité de la chaîne d’approvisionnement logicielle.

Cela a permis à la première phase de se concentrer sur la réduction des lacunes spécifiques plutôt que de construire des fondations à partir de zéro.

Mais une feuille de calcul n'est qu'un instantané.

SPVS en demande plus.

Certains contrôles nécessitent un examen régulier :

Effectuée manuellement à l'échelle de l'organisation, cette tâche représente une demi-journée de suivi des clics chaque trimestre, avec un risque réel d'omissions involontaires.

Ce genre de travail est soit automatisé, soit examiné seulement après qu'un incident grave se soit produit.

Nous avons donc construit xygeni-vcs-audit.

Il s'agit d'un outil interne qui s'exécute sous l'identité du propriétaire de l'organisation et produit un dossier trimestriel structuré couvrant :

• Liste des administrateurs
• Protection des succursales
• Couverture CODEOWNERS
• Hygiène du YAML du flux de travail
• Actions épinglées
• Explicite permissions
• pull_request_target gating
• Membre 2FA
• Applications GitHub installées
• Déployer les clés

Ce qui nécessitait auparavant une demi-journée d'exploration de feuilles de calcul se résume désormais à une simple commande générant du JSON et du Markdown.

L'examen trimestriel de 30 minutes entre les CISO et les administrateurs de l'organisation sont maintenant un decisRéunion d'information, et non réunion de collecte de données.

Les constats exploitables deviennent des problèmes en attente avec des SLA basés sur la gravité.

L'outil est pour l'instant interne, mais le principe est simple : un week-end de programmation avec l'API GitHub permet d'éliminer une grande partie des tâches manuelles récurrentes.

Nous avons également ajouté une politique de liste blanche couvrant :

• Administrateurs approuvés
• Applications approuvées
• Autorisations par fonction pour les dépôts et les flux de travail

Cette politique est stockée au format YAML dans le dépôt de l'outil et son application est soumise à l'examen des demandes de fusion par notre équipe de sécurité.

Toute modification de la liste blanche laisse une trace de révision, ce qui permet de générer automatiquement les preuves d'audit.

Pas de SaaS.
Aucun pack de règles tiers.
Aucune accréditation supplémentaire à gérer.

L'effet a été de transformer les contrôles ambitieux en contrôles de routine.

Au lieu de dire:

Nous devrions procéder à un audit trimestriel.

Nous pouvons maintenant dire :

L'audit de ce trimestre a été publié lundi.

Cela nous donne un mécanisme reproductible pour la détection de la dérive, comme l'exige le principe de bout en bout.

Les frictions que nous n'avions pas prévues

Les contrôles techniques, c'est la partie facile.

Les gens sont plus difficiles.

L'exemple le plus frappant était PROPRIÉTAIRES DE CODE.

Ajouter cette ligne à chaque dépôt semble trivial :

.github/workflows/ @xygeni/security

Un seul fichier.
Une ligne.

Mais cela signifiait que les ingénieurs qui intégraient automatiquement les modifications de flux de travail depuis des années devaient désormais se soumettre à un audit de sécurité.

Même les personnes soucieuses de leur sécurité ont protesté :

J'ai rédigé ce processus. Je le comprends. Pourquoi est-ce que j'attends ?

Il a fallu une véritable conversation pour comprendre le pourquoi.

Les flux de travail peuvent :

• Exfiltrer les identifiants
• Redirection des artefacts
• Empoisonner les consommateurs en aval

Un deuxième avis n'est pas synonyme de méfiance. C'est le même principe que la double vérification des modifications apportées aux bases de données en production.

L'incident lié à xygeni-action a été utile. Rien ne permet de mieux appréhender un contrôle que par un exemple concret de ce qui se produit lorsqu'il fait défaut.

D'autres frictions ont suivi le même schéma.

Nous avions utilisé une signature GPG commitNous l'avons intégré dès le départ dans nos principaux dépôts. SPVS l'a rendu obligatoire pour tous les dépôts et contributeurs.

Le modèle qui a fonctionné était le suivant :

• Présentez chaque contrôle en précisant la menace spécifique qu'il bloque.
• Testez-le sur un ou deux dépôts.
• Déployez-le avec des exceptions autorisées.
• Mettre fin aux exceptions selon un calendrier établi.

Il est intéressant de noter que les ingénieurs qui ont le plus résisté sont souvent devenus les plus fervents défenseurs une fois qu'ils en ont compris le raisonnement.

Il y a aussi un point plus profond.

Le principe de bout en bout s'applique ici.

Nous ne pouvions pas choisir les options. Renforcer la phase de compilation tout en laissant la gouvernance des versions souple aurait créé un faux sentiment de confiance, ce qui correspond précisément au mode de défaillance que les auteurs de SPVS dénoncent.

Chaque étape devait progresser simultanément, même lorsqu'un contrôle spécifique semblait disproportionné pris isolément.

Prix

Phase 1, axée sur Conformité L2Cela a nécessité environ un mois de travail d'ingénierie, réparti sur plusieurs tâches :

• DevOps
• Sécurité
• Réviseurs techniques

Notre taille nous permet de rendre cela possible, mais les résultats peuvent varier.

L'investissement est rapidement rentabilisé. Un seul incident de chaîne d'approvisionnement évité le couvre largement.

Cartographie de l'incident vers SPVS v1.0

Cartographier le incident d'action de l'oxygène La présentation de SPVS v1.0 a été instructive.

L'écart d'empoisonnement des étiquettes est important.

SPVS v1.0 ne comporte aucun contrôle explicite sur l'immuabilité des étiquettes ou des versions, et n'exige aucune étiquette signée.

V3.4.1Les objets signés sont ce qu'il y a de plus proche. Mais les objets signés aident les consommateurs à détecter les falsifications. Ils n'empêchent pas le déplacement d'une étiquette.

L'immuabilité des étiquettes, et sans doute la nécessité d'une signature, sont des critères importants. commitLes étiquettes signées et les étiquettes s sont des candidats naturels pour de futures révisions du SPVS.

Et ensuite ?

SPVS v1.5 est en préparation avec des commandes liées à l'IA, notamment :

• Provenance du code assisté par IA
• Guardrails pour les flux de travail CI qui appellent des LLM
• Examen des pistes pour les IA générées pull requests
• Défenses contre les menaces émergentes comme slopsquatting

Le slopsquatting désigne le fait, pour les attaquants, d'enregistrer des noms de paquets que les assistants de codage IA hallucinent.

Nous avons déjà tagué Claude-assisté commitLes demandes de fusion et les demandes de fusion sont conformes à nos directives internes de développement de l'IA ; cette adaptation devrait donc être progressive plutôt qu'un nouveau programme de travail.

La version 2.0 devrait approfondir :

• Surveillance du temps d'exécution
• exigences relatives au cycle de vie des identifiants

Notre feuille de route est claire :

• Fermer les restes lacunes L3 d'ici la fin du deuxième trimestre 2026
• Intégrer SLSA provenance développement standard CI/CD
• Ajouter des contrôles manuels pour les déploiements en production
• Centraliser les contrôles du fournisseur d'identité
• Passer en mode maintenance

Le but est simple :

Chaque nouveau dépôt est conforme dès le départ.
Chaque audit trimestriel détecte les dérives très tôt.

Un grand merci à Farshad Abasi, Cameron Walters et au groupe de travail OWASP SPVS.

Des projets comme celui-ci abaissent le niveau d'exigence pour toute organisation souhaitant aborder la sécurité de la chaîne d'approvisionnement logicielle de manière systématique plutôt que réactive.

Points clés à retenir

Quelques leçons sont transposables au-delà de notre contexte spécifique :

1. Commencez par le fichier CSV des exigences SPVS

Téléchargez le Exigences SPVS CSV et représentez vos commandes actuelles dans une feuille de calcul.

Vous saurez sous 24 heures si cela convient à votre organisation.

2. Choisissez un niveau cible et expédiez-le

L1 → L2 → L3 c'est une caractéristique, pas une limitation.

N'essayez pas de tout faire en même temps.

3. Traitez le pipeline comme cible

Les contrôles axés sur l'application sont nécessaires, mais pas suffisants.

Votre pipeline constitue désormais une surface d'attaque de premier ordre.

4. Vérifier l'ensemble pipeline

Une analyse poussée des dépendances ne compense pas une gouvernance des versions défaillante ni des environnements de construction non surveillés.

5. Automatiser la détection de dérive

Les feuilles de calcul sont des instantanés. La dérive est continue.

Même un outil interne modeste peut rendre les audits reproductibles et exploitables.

6. Budget pour les travaux d'organisation

L'aspect humain est plus difficile que l'aspect technique.

Expliquez la menace spécifique que chaque contrôle bloque, effectuez un test pilote avant le déploiement et donnez aux équipes une voie d'adaptation.

Pour en savoir plus

• OWASP : Sécurisés Pipeline Vérification Standard SPVS v1.0
• Farshad Abasi : Pourquoi avons-nous créé OWASP SPVS ?
• Farshad Abasi : Pipeline Les attaques s'aggravent. Voici comment se préparer.
• Farshad Abasi : OWASP SPVS par rapport aux autres cadres de gestion de la chaîne d'approvisionnement
• OWASP : Top 10 CI/CD Risques de sécurité
• SLSA : Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels
• OpenSSF: fiche d'évaluation