DevSecOps : les garanties sécurité dans l’industrialisation logicielle

La sécurité applicative se garantit dans la durée

Trop régulièrement, malheureusement, des incidents de sécurité paraissent dans l’actualité. Tout le monde est concerné, quelle que soit la technologie, de la simple librairie (de logs par exemple…) à l’application métier complexe qui voit ses millions de données utilisateurs s’envoler dans la nature. Parfois, cela peut avoir de très forts impacts financiers pour les entreprises en charge du service final. Il est donc primordial de faire de la sécurité une priorité.

De l’hébergement à l’application elle-même (code client ou serveur), les brèches éventuelles peuvent porter aussi bien sur des composants communautaires open source que propriétaires développés sur mesure.

Respecter quelques principes de base permet de limiter les risques : par exemple s’assurer de bénéficier d’un support actif sur les différentes briques logicielles externes, ou encore mettre en place une politique de mises à jour régulières. En plus de profiter de nouvelles fonctionnalités, le but est avant tout d’appliquer les derniers correctifs de bugs et de sécurité.

Parmi les mesures évidentes, on peut noter aussi la sélection minutieuse de ces composants tiers (réellement nécessaires) sur lesquels s’appuyer. En effet, l’objectif est double : choisir des dépendances reconnues et éprouvées dont l’activité de maintenance est fréquente, et par ailleurs ne pas réinventer la roue avec des développements “sur mesure” qui pourraient introduire des défauts de sécurité.

Puisque de nouvelles failles peuvent être découvertes à chaque instant, ces opérations (et d’autres que nous allons voir par la suite) doivent être réalisées de manière récurrente pour garantir un niveau de sécurité global qui s’inscrit dans le temps. Pour des exécutions répétées et des résultats fiables, il faut automatiser ces vérifications à l’aide d’outils : cela fait partie de ce que l’on appelle l’industrialisation logicielle.

Quelques outils pour garantir la sécurité applicative

Lors de l’initialisation d’un projet, des outils automatisés d’assurance qualité et sécurité doivent être configurés en parallèle de la mise en place de la solution elle-même. Ils attestent du niveau initial et doivent être exécutés lors de chaque changement pour valider que le niveau reste a minima identique. 

Ces outils couvrent plusieurs sujets :

Linting et vérification des conventions de codage

Qu’elles soient propres au langage, au framework, au projet ou encore d’entreprise, ces outils standardisent le code de la même façon pour tous les intervenants et améliorent la revue de code.

Sur le plus long terme, les bénéfices sont multiples : 

• Tout d’abord en matière de maintenabilité du code – et donc plus généralement en matière de sécurité ;
• La standardisation permet également de faciliter la collaboration, et donc d’accélérer les interventions et la mise en place de correctifs en cas d’incident en production ;

Analyse statique de code

Le code est analysé statiquement (sans que l’application ne soit exécutée) pour vérifier la cohérence programmatique mais aussi pour détecter des vulnérabilités exploitables.

• Côté applicatif : un outil comme Sonar reste aujourd’hui le standard le plus commun. Il couvre à la fois les aspects qualitatifs du code et la détection de failles potentielles. Pour aller plus loin on peut mettre en place un outil de type DAST (Dynamic Application Security Testing), comme Zap pour tester activement les failles potentielles dans le pipeline de CI/CD.
• Côté infrastructure : des outils permettent de remonter les erreurs de configuration les plus communes (stockage non chiffré, service non redondé, permissions trop élevées, etc.). C’est par exemple le cas de TFSec pour Terrafom, ou de Trivy pour les manifestes Kubernetes.

Tests unitaires et fonctionnels

Les tests unitaires et fonctionnels sont clés lorsque l’on parle de qualité logicielle. Ils sont privilégiés pour tester un algorithme précis de l’application (tests unitaires) ou une réponse de l’application (tests fonctionnels). Ces tests garantissent que le résultat obtenu correspond à celui attendu, dans un cas nominal ou non. Ils sont donc utiles lors de l’implémentation initiale d’une fonctionnalité et peuvent (doivent) être complétés en cas de correction, notamment s’il est question de sécurité, pour vérifier que la correction est effective.

Une bonne couverture de tests unitaires et fonctionnels automatisés permet enfin d’assurer la non régression du fonctionnement de l’application lorsque l’on intègre un correctif de sécurité, et donc d’aller vers un processus industrialisé en toute confiance.

Audits de sécurité 

En mode boîte blanche, grise ou noire, ils détectent des failles potentielles sur une partie du système. Les cas d’usage classiques incluent :

• La détection de librairies vulnérables dans les containers (via Trivy ou Snyk)
• L’analyse des ressources cloud déployées pour vérifier le respect des bonnes pratiques (AWS Config, Cloudsploit)
• L’analyse des applications pour vérifier leur résistance aux failles communes type OWASP top 10 (Qualys, Nexus)

Inventaire et patch management

Au-delà de ces outils ou pratiques de tests qui permettent d’identifier des failles, se pose la question du processus de remédiation. Ce dernier doit être efficient et scalable, ce qui passe bien sûr par une automatisation correctement orchestrée.

Une faille kernel, par exemple, doit pouvoir être patchée sur l’ensemble du parc serveur sans interrompre le service. Une mise à jour de librairie ne doit pas provoquer de régression applicative, et doit donc s’appuyer sur la chaîne de tests unitaires et fonctionnels.

Enfin, l’automatisation va de pair avec la traçabilité, en particulier dans certains domaines d’activité réglementés. Un service comme AWS Systems Manager permet par exemple de tenir automatiquement à jour l’inventaire des librairies système installées sur une plateforme, et de conserver un log d’audit de tous les patchs appliqués dans le temps.

Conclusion : une affaire d’outils, de bonnes pratiques et d’organisation

Pour rester pertinents, ces outils doivent être maintenus, adaptés, complétés, voire devenir de plus en plus stricts, tout au long du cycle de vie du projet … ce qui inclus également les phases ou le projet n’est plus en développement actif. Il est donc nécessaire d’anticiper à la fois les coûts, mais également la disponibilité des personnes clefs qui maintiendront et surveilleront ces outils et leurs résultats.

L’aspect organisationnel de ces processus est également un point essentiel. Nous parlons ici d’automatisation et d’industrialisation, mais les humains restent au centre du processus. La démarche “DevSecOps” implique par définition que les outils et méthodologies soient partagés et lisibles pour casser les silos.

Pour conclure, et au-delà de ces éléments très centrés sur la chaîne de développement logiciel, il ne faut pas oublier que la sécurité est une chaîne qui doit être renforcée de manière cohérente. Tous les outils du monde ne permettront pas de compenser une application mal conçue en termes de service rendu et d’expérience utilisateur. 

Il est donc au moins aussi important de s’assurer en amont (lors de la conception du service) que l’application ne manipulera que les données strictement nécessaires à son bon fonctionnement afin de réduire les risques.

L’application devra enfin être conçue pour accompagner ses utilisateurs dans la mise en place d’une bonne hygiène numérique en facilitant les bonnes pratiques (support des gestionnaires de mots de passe, 2FA, processus clair de suppression de données / comptes, …)