Domaine d’expertise
Sécurité de la chaîne logicielle
Une organisation peut corriger ses vulnérabilités applicatives tout en ignorant comment un artefact a été produit, quelles dépendances il embarque et qui pouvait modifier sa chaîne de construction.
Définition opérationnelle
La sécurité de la chaîne logicielle protège les sources, dépendances, identités de construction, artefacts et chemins de promotion, puis permet d’en vérifier l’origine et l’intégrité.
Problèmes réellement rencontrés
-
01
Artefacts promus sans provenance vérifiable
-
02
Dépendances directes et transitives mal connues
-
03
Runners de CI trop privilégiés ou persistants
-
04
Signatures produites mais jamais vérifiées au déploiement
Décisions concernées
- Définir frontières de confiance et niveaux d’assurance
- Choisir les attestations et vérifications exigées
- Prioriser durcissement des sources, builds ou déploiements
Erreurs fréquentes
- Réduire le sujet à la génération d’une SBOM
- Signer avec des secrets longue durée dans la CI
- Appliquer le même niveau d’assurance à tous les artefacts
Signaux qu’une expertise externe devient utile
- Impossible de relier un binaire à une source et un build
- Une compromission de CI aurait un rayon d’impact inconnu
- Les preuves sont collectées uniquement avant audit
Méthode Omnivya
-
1.
Cartographier acteurs, identités, systèmes et promotions
-
2.
Modéliser menaces et chemins de compromission
-
3.
Vérifier contrôles et preuves sur un artefact réel
-
4.
Définir une progression d’assurance proportionnée
Livrables possibles
- Carte de chaîne et frontières de confiance
- Analyse des menaces et contrôles manquants
- Profil de provenance, signature et vérification
Preuves de raisonnement
- Provenance vérifiée jusqu’au déploiement
- Identités de build courtes et bornées
- Scénarios de compromission testés sur le périmètre retenu
Limites explicites
- Ne pas présenter une SBOM comme preuve d’intégrité
- Ne pas imposer un niveau maximal à tous les produits
- Ne pas certifier une chaîne sans vérification indépendante
Formats de mission associés
- Revue de risques techniques
Qualifier le risque au-delà du volume de tickets ou de CVE.
- Audit de plateforme
Évaluer ce qu’une plateforme permet réellement de décider et d’opérer.
- Expertise sur programme critique
Apporter une expertise senior sur un programme déjà engagé, sans en prendre le contrôle.
Questions fréquentes
- Une SBOM suffit-elle ?
- Non. Elle renseigne la composition si sa génération est fiable, mais ne prouve ni l’intégrité du build ni l’application des politiques.
- Faut-il viser SLSA au niveau maximal ?
- Pas par défaut. Le niveau dépend de la menace, de la criticité et du coût acceptable pour chaque classe d’artefact.
- Par où commencer ?
- Par un artefact critique et son chemin complet, afin d’observer les ruptures de confiance avant de généraliser.
Vérifier une chaîne de construction
Si la tension décrite est la vôtre, cadrons la décision avant d’élargir le périmètre.