Les tests jouent un rôle crucial tout au long du cycle de développement logiciel, assurant une livraison avec un minimum de défauts et conférant une fiabilité accrue au produit final.

Cependant, certaines équipes traditionnelles persistent à n'exécuter les tests qu'à la phase finale du développement. Cette approche est intrinsèquement défectueuse, car elle ne favorise pas les retours rapides et restreint l'efficacité, entravant ainsi l'identification précoce des anomalies. De ce fait, les tests deviennent un processus coûteux et rallongent le délai de mise sur le marché du produit final.

Pour bénéficier de retours d'information plus rapides sur les tests, ces derniers doivent être effectués dès les premières phases du cycle de développement logiciel. Cette stratégie de test, connue sous le nom de Shift-Left, peut être appliquée tant aux tests fonctionnels que non fonctionnels. Elle permet aux développeurs et testeurs de collaborer étroitement pour créer et exécuter des cas de test dès les premières étapes du développement.

Qu'est-ce que le Shift-Left ?

Le Shift-Left est une approche qui déplace les tests vers le début du cycle de développement logiciel (d'où "shift left"). Si les tests de sécurité ne sont effectués qu'une fois le code prêt pour la production, il peut être trop tard pour rectifier rapidement les problèmes. Cela peut entraîner des retards, des problèmes de sécurité et des silos entre la sécurité et le reste des équipes DevOps.

En d'autres termes, il s'agit d'une stratégie de développement logiciel visant à améliorer la qualité de livraison et à prévenir et résoudre les problèmes le plus tôt possible dans le cycle de développement.

Tout devient plus clair avec l'illustration suivante :

    Flux de test Shift-Left

Du côté gauche, le Shift-Left est mis en œuvre, où le développement comprend les phases de planification, de codage, de construction et de test.

Cette approche a d'abord été adoptée dans des concepts tels que le développement piloté par les tests (TDD) et le développement piloté par le comportement (BDD), mais elle est maintenant appliquée dans différents domaines. Les plateformes d'intégration continue/de livraison continue (CI/CD) permettent aux équipes de déployer et d'utiliser des outils pour effectuer des vérifications et des tests à chaque étape du flux.

Méthodologies connexes

L'approche Shift-Left comprend quatre méthodologies visant à résoudre les problèmes à différentes étapes du cycle de développement logiciel :

• Incrémentiel : adapté aux systèmes complexes intégrant un matériel spécifique, il garantit que chaque segment est validé avant d'incrémenter le suivant. 
• Traditionnel : conçu pour des validations plus légères et des systèmes moins complexes, il vise à valider les étapes de test unitaire et d'intégration. 
• Agile/DevOps : basé sur des tests effectués en sprints et limité au développement et aux tests non opérationnels. 
• Basé sur le modèle : contrairement à d'autres méthodologies où les tests ont lieu pendant le développement, celui-ci valide les exigences, l'architecture et la conception.

Quand peut-on appliquer le Shift-Left ?

Alors que les organisations s'efforcent de migrer vers une structure plus orientée DevSecOps, il est essentiel d'intégrer les tests de sécurité dès les premières phases du cycle de développement. Cela peut être réalisé en intégrant les tests de sécurité dans les pipelines de déploiement, afin que le code soit testé en continu, non seulement par rapport à d'autres commits dans le référentiel partagé, mais aussi en termes de sécurité globale.

L'intégration continue (CI) est un processus visant à améliorer la qualité du code grâce aux pipelines de déploiement. La sécurité peut être intégrée dès le début de ces pipelines. Ainsi, le Shift-Left peut être intégré dans des pipelines d'intégration continue tels que :

• Test de sécurité de l'application statique (SAST) : cette méthode automatise la sécurité via l'intégration continue. SAST analyse le code source, permettant aux développeurs de résoudre les problèmes tôt dans le cycle de développement logiciel. Par exemple, dans GitLab CI, le pipeline de déploiement vérifie le rapport SAST et compare les vulnérabilités entre les branches source et cible, affichant les résultats dans la demande de fusion.
• Test de sécurité de l'application dynamique (DAST) : cette méthodologie de test de boîte noire découvre d'éventuelles failles de sécurité via des analyses automatisées d'une cible en cours d'exécution. En collaboration avec SAST, DAST analyse les erreurs d'exécution dans les applications en cours d'exécution. Une fois déployée, une application est exposée à de nouveaux types de risques, tels que les failles de script entre sites ou les défauts d'authentification.
• Modélisation des menaces : ce processus consiste à réfléchir à chaque décision prise dans un système donné et à extrapoler ses répercussions sur son profil de sécurité, immédiatement ou à l'avenir. Il se base sur l'identification des exigences de sécurité, des menaces et vulnérabilités potentielles, ainsi que sur la quantification de leur criticité pour prioriser les actions de remédiation.
• Révision de l'architecture de sécurité : phase chargée d'identifier, d'évaluer et de réduire les risques pour renforcer les mesures de sécurité d'une organisation contre les menaces et les risques actuels et émergents.
• Analyse d'image de conteneur : cette méthode analyse une image de conteneur, couche par couche, pour détecter d'éventuelles menaces de sécurité.
• Signature de code : cette technique consiste à apposer une signature numérique sur un programme, un fichier ou une mise à jour logicielle pour vérifier son authenticité et son intégrité lors de l'installation et de l'exécution.

Il existe également d'autres types de tests de sécurité, tels que les tests de sécurité des applications interactives (IAST) et la protection autonome des applications en cours d'exécution (RASP). IAST fonctionne en plaçant un agent à l'intérieur d'une application, tandis que RASP est un outil de sécurité placé à l'intérieur d'une application pour répondre aux attaques en direct.

Avantages du Shift-Left

Concrètement, le concept Shift-Left vise à détecter et à corriger les vulnérabilités dès les premières étapes de l'écriture du code. Cela garantit non seulement une meilleure sécurité, mais améliore également l'expérience utilisateur en livrant un logiciel plus rapidement, plus fréquemment et de meilleure qualité.

Fondamentalement, cela accélère l'efficacité du développement et peut également réduire les frais généraux en détectant et en résolvant les bugs logiciels plus tôt dans le cycle de développement.

En résumé, voici les principaux avantages :

• Les bugs, les défauts et les problèmes de performance peuvent être identifiés tôt dans le cycle de développement, facilitant ainsi leur résolution.
• Les coûts de test et de maintenance peuvent être considérablement réduits grâce à une détection précoce.
• Le produit final est de meilleure qualité, avec très peu de bugs et de problèmes de performance.
• Le délai de mise sur le marché est réduit grâce à des tests intégrés au développement avec un retour d'information rapide.
• La satisfaction client est améliorée grâce à une meilleure expérience utilisateur.

Conclusion

Le test Shift-Left soutient les équipes Agile et les pratiques DevOps, générant ainsi des produits de meilleure qualité avec des coûts et des délais réduits. Il convient de noter que ce concept est populaire au sein de la communauté des tests car il permet de détecter les problèmes plus tôt avec des coûts de correction moindres. Parmi les équipes DevOps, son adoption est en constante augmentation.

Cependant, une préoccupation majeure réside dans le fait que cela peut ralentir le flux de développement et rendre bureaucratique le déploiement de nouvelles fonctionnalités en production. Les tests de charge avec l'approche Shift-Left représentent une stratégie sophistiquée pour garantir que l'application est toujours optimisée pour des performances optimales.

Ces outils sont conçus avec précision en tenant compte du développement Agile. Ainsi, l'ajout de quelques minutes à votre pipeline peut générer d'importants gains en matière de sécurité, assurant ainsi la qualité de ce qui sera livré à l'utilisateur final et évitant les problèmes dans votre application.