Le « shift left » est devenu l’un des principes les plus largement adoptés en DevSecOps. L’idée est simple et séduisante : déplacer la sécurité plus tôt dans le cycle de développement logiciel pour détecter les problèmes plus rapidement, réduire les coûts et améliorer les résultats globaux en matière de sécurité.
Au fil du temps, le « shift left » est passé d’un concept utile à un dogme quasi incontesté. Les analyses de sécurité, les tests et les vérifications de politiques sont poussés le plus tôt possible — souvent dans l’IDE du développeur ou dans les premières étapes du CI.
Pourtant, malgré des années de « shift left », les attaques contre la chaîne d’approvisionnement logicielle continuent de réussir. Les systèmes de build sont compromis. Des dépendances malveillantes sont livrées. Des versions contenant des portes dérobées sont distribuées via des pipelines de confiance.
Le problème n’est pas que le « shift left » soit erroné. Le problème est que le shift left seul est insuffisant, et dans de nombreux cas, il échoue précisément parce qu’il ignore la sécurité des pipelines CI/CD eux-mêmes.
Cet article explique où le modèle « shift left » atteint ses limites, pourquoi il ne traite pas la compromission des pipelines, et comment le DevSecOps doit évoluer pour inclure explicitement la sécurité des pipelines.
L’origine du « shift left »
Le concept de « shift left » est né en réponse aux défaillances de sécurité en fin de cycle.
Historiquement, les revues de sécurité avaient lieu à la fin du cycle de développement : tests d’intrusion avant la mise en production, points de validation sécurité, et remédiation de dernière minute des problèmes critiques.
Cette approche créait des problèmes prévisibles :
- Les constatations de sécurité arrivaient trop tard
- Les corrections étaient coûteuses et perturbatrices
- Les développeurs percevaient la sécurité comme un obstacle externe
Le « shift left » visait à résoudre ce problème en introduisant la sécurité plus tôt :
- Analyse statique pendant le développement
- Analyse des dépendances au moment du build
- Tests automatisés dans le CI
En tant que principe, c’était une amélioration évidente. Un retour d’information précoce est presque toujours préférable à un retour tardif.
Cependant, le modèle reposait sur une hypothèse qui n’est plus vraie :
Si le code est sécurisé tôt, le logiciel livré sera sécurisé.
Ce que le « shift left » sécurise réellement
En pratique, le « shift left » se concentre sur un ensemble spécifique de risques :
- Les vulnérabilités dans le code applicatif
- Les problèmes connus dans les dépendances
- Les erreurs de configuration détectables par analyse statique
Ces contrôles répondent à des questions importantes :
- Ce code contient-il des vulnérabilités évidentes ?
- Utilisons-nous des bibliothèques présentant des vulnérabilités connues ?
- Cette configuration enfreint-elle des politiques connues ?
Ce à quoi ils ne répondent pas est tout aussi important :
Peut-on faire confiance au système qui construit et distribue ce logiciel ?
Les contrôles shift left se concentrent sur ce qui est écrit. La sécurité des pipelines se concentre sur comment le code est transformé, empaqueté et distribué.
Pourquoi le « shift left » ne couvre pas le pipeline
Les pipelines CI/CD se situent en aval de la plupart des activités shift left.
Au moment où un pipeline s’exécute, le code a déjà :
- Passé l’analyse statique
- Passé les vérifications de dépendances
- Passé les tests unitaires et d’intégration
Pourtant, c’est précisément là que de nombreuses compromissions réelles se produisent.
La raison est structurelle : les contrôles shift left supposent que le pipeline lui-même est digne de confiance.
Cette hypothèse est souvent fausse.
Les pipelines exécutent des entrées non fiables par conception
Les pipelines CI/CD exécutent régulièrement :
- Du code de pull requests
- Des scripts de build
- Des actions et plugins tiers
- Des dépendances récupérées au moment du build
Même si le code source est « sécurisé », le pipeline est exposé à des comportements non fiables pendant l’exécution.
L’analyse shift left ne protège pas contre les comportements malveillants introduits au moment du build ou de l’empaquetage.
Les pipelines fonctionnent avec des privilèges élevés
Les pipelines ont souvent accès à :
- Des secrets et des identifiants
- Des dépôts d’artefacts
- Des clés de signature
- Des permissions de déploiement
Si des attaquants compromettent le pipeline, ils n’ont pas besoin d’exploiter les systèmes de production.
Ils peuvent simplement produire des artefacts « légitimes » auxquels les systèmes en aval font implicitement confiance.
Défaillances réelles de la mentalité « shift left »
Les incidents majeurs de la chaîne d’approvisionnement ne se sont pas produits parce que les équipes n’avaient pas analysé le code suffisamment tôt.
Ils se sont produits parce que des attaquants ont exploité des mécanismes de build et de livraison de confiance.
La compromission du pipeline contourne les contrôles au niveau du code
Lorsque des attaquants injectent un comportement malveillant dans :
- Les étapes de build
- L’outillage CI
- Les processus de résolution de dépendances
les artefacts résultants peuvent passer tous les contrôles shift left.
Du point de vue du pipeline, tout semble normal.
Du point de vue de la production, l’artefact est légitime.
Les contrôles shift left ne modélisent pas les frontières de confiance
Les outils shift left se concentrent sur la détection de problèmes connus.
Ils ne modélisent pas :
- Qui contrôle l’exécution du pipeline
- Où la confiance est accordée
- Comment les artefacts acquièrent leur légitimité
C’est pourquoi les attaquants ciblent les pipelines : ils exploitent les relations de confiance, pas les vulnérabilités.
Où les contrôles de sécurité des pipelines doivent réellement se situer
Si les contrôles shift left sont insuffisants, où les contrôles de sécurité des pipelines doivent-ils être appliqués ?
La réponse n’est pas « encore plus tôt ».
La sécurité des pipelines nécessite des contrôles à des transitions de confiance spécifiques.
Avant l’exécution : contrôler les entrées non fiables
Tous les déclencheurs de pipeline ne doivent pas être traités de la même manière.
Les contrôles doivent distinguer entre :
- Les branches de confiance
- Les pull requests non fiables
- Les contributions externes
Les secrets, les actions privilégiées et les étapes de déploiement doivent être contrôlés en conséquence.
Pendant l’exécution : isoler les runners
Les runners sont l’endroit où la confiance est la plus fragile.
Les contrôles efficaces incluent :
- Des runners éphémères
- Un isolement renforcé
- Un accès réseau minimal
- Des identités à moindre privilège
L’analyse shift left ne protège pas contre la compromission des runners. L’isolement, si.
Après l’exécution : vérifier les artefacts
Le contrôle de pipeline le plus critique est souvent le dernier.
Avant le déploiement, les systèmes doivent vérifier :
- Qui a construit l’artefact
- Comment il a été construit
- S’il a été modifié
Sans vérification, la production fait implicitement confiance au pipeline.
Repenser le DevSecOps au-delà du « shift left »
Le DevSecOps a besoin d’un modèle mental plus complet.
La sécurité doit être :
- Précoce, pour détecter les défauts à moindre coût
- Continue, pour s’adapter au changement
- Exécutoire, pour empêcher toute compromission silencieuse
La sécurité des pipelines traite le troisième point.
Elle introduit des garanties exécutoires que l’analyse seule ne peut pas fournir.
Un modèle plus précis : sécuriser le cycle de vie de la confiance
Au lieu du « shift left », un meilleur cadre de réflexion est :
Sécuriser le cycle de vie de la confiance.
Cela signifie :
- Comprendre où la confiance entre dans le système
- Contrôler comment elle se propage
- La vérifier avant qu’elle n’atteigne la production
Les contrôles shift left restent précieux, mais uniquement en tant que partie d’un système plus large qui inclut la sécurité des pipelines.
Conclusion
Le « shift left » n’est pas erroné — mais il est incomplet.
Il améliore la qualité du code et détecte les défauts tôt, mais il ne protège pas contre la compromission des pipelines ni contre les attaques de la chaîne d’approvisionnement.
Les pipelines CI/CD sont l’endroit où la confiance est transformée, amplifiée et finalement accordée.
Ignorer la sécurité des pipelines revient à faire confiance aux systèmes mêmes que les attaquants ciblent de plus en plus.
Le DevSecOps doit évoluer au-delà des slogans et se concentrer sur l’ingénierie de la confiance de bout en bout.
Sans la sécurité des pipelines CI/CD, le « shift left » n’est pas une stratégie — c’est une hypothèse.
