DevSecOps ? Une vraie révolution culturelle

A l’automne 2016, le constat était net : l’intégration de la sécurité dans les approches DevOps est difficile. Plus récemment, Elizabeth Lawler, de CyberArk, déplorait que les efforts se concentrait encore trop sur la seule chaîne logistique du logiciel. Mais aujourd’hui encore, passer au DevSecOps n’apparaît pas simple.

Dans une note d’information à ses clients, Gartner relève quatre difficultés principales. Et cela commence par une question de priorités : « dans le monde de l’économie numérique, les équipes en charge du développement des produits qui fournissent aux clients de nouvelles capacités favorisées par l’informatique sont souveraines ». Dès lors, on n’est tenté de penser que les équipes de sécurité ont bien de la chance quand elles arrivent à se faire entendre. Mais c’est peut-être une question d’approche.

Pour les analystes, pour s’intégrer à un environnement DevOps, les équipes de sécurité doivent avant tout s’adapter aux outils et processus de développement, « et non l’inverse ». Une évolution qui peut être d’autant plus difficile que « les professionnels de la sécurité des informations [sont] habitués à obliger les développeurs à se conformer à leurs processus ».

Il convient donc de laisser les développeurs continuer à travailler avec leurs outils, leurs méthodes, et de jouer la carte de l’intégration avec ceux-ci. Cela peut aussi passer par l’acceptation d’une part d’imperfection : « la sécurité parfaite des applications n’est pas possible » et… « à trop vouloir des applications sans la moindre vulnérabilité, les tests de la sécurité deviennent très lourds et constituent un frein à la rapidité de l’économie numérique ».

Mais cela ne signifie pas pour autant qu’il faille se laisser aller au laxisme. Car le fait de miser sur DevOps n’exonère pas de ses responsabilités, notamment réglementaires. D’ailleurs, cette réalité semble comprise : selon Gartner, les pratiques DevSecOps auront été adoptées dans 80 % des environnements de développement rapide d’ici à 2021, contre seulement 15 % l’an dernier.

Pour avancer dans cette direction, le cabinet formule plusieurs recommandations. La première d’entre elles n’est autre que l’intégration des tests de sécurité et de conformité de manière transparente. Et à cela s’ajoute la recherche automatisée des vulnérabilités connues et des défauts de configuration dans les composants tiers et libre utilisés – « dans l’idéal, élaborez une nomenclature complète en utilisant l’analyse de la composition des logiciels ».

Et comme pour de nombreux autres domaines de la sécurité, Gartner recommande de ne pas chercher à éliminer systématiquement toutes les vulnérabilités inconnues du code personnalisé, en raison du risque de faux positifs. Alors pour le cabinet, il s’agit de trouver un « compromis entre la rapidité des tests, le temps perdu par les développeurs sur des faux positifs, et la hausse du risque liée aux faux négatifs ». C’est dans cette perspective qu’il convient plutôt de se concentrer sur ce qui présente « le niveau de criticité et de confiance le plus élevés ».