DevSecOps : approche miracle ou fausse bonne idée ?

DevSecOps, une bonne idée mais pas la panacée

Les développeurs n’étant pas des experts en sécurité, pas plus que les ingénieurs, il arrive souvent qu’ils évaluent mal les risques. En cas de mauvaise décision, leur entreprise ou ses clients sont confrontés à des dommages matériels. Il appartient alors à l'équipe de sécurité de se démener pour réparer les dégâts. DevSecOps est une bonne idée sur le papier. Sa promesse d'efficacité et de gains de coûts, liés à l’approche "shift left", est attrayante pour les chefs d'entreprise. En effet, ces derniers y voient un moyen de réduire leurs coûts de sécurité et d'optimiser leur rentabilité. Dans la réalité, le simple fait de transférer les responsabilités de sécurité aux équipes d'ingénieurs existantes alourdit la charge de travail de ces derniers. In fine, cette évolution se traduit par des équipes de sécurité en sous-effectif, incapable de répondre à leurs questions et de les soutenir.

Une approche qui divise plus qu’elle ne fédère

Les attentes irréalistes à l'égard des ingénieurs en logiciel, censés être des experts dans tous les domaines, de la conception de la sécurité à la modélisation des menaces, en passant par l'évaluation des risques et des vulnérabilités, engendrent l'évitement, le blâme et la frustration. La dépendance excessive à l'égard des outils de sécurité et de l'automatisation sert de justification financière et commerciale au manque de ressources des équipes de sécurité. Mais ce n'est pas une fatalité. Les ingénieurs en sécurité peuvent fournir d'excellentes solutions techniques, mais un programme de sécurité efficace est bien plus intéressant. Le programme de sécurité d'une entreprise est un portefeuille d'offres de produits et de services destinés aux clients internes et externes.

La force des Avengers ? Des profils complémentaires

Le problème, c‘est que les ingénieurs en sécurité sont loin d’être enthousiastes à l'idée d'écrire des référence utilisateurs, de construire des feuilles de route, de s’assurer que les parties prenantes sont en phase ou de rendre compte des résultats clés aux dirigeants de l'entreprise. Ce n'est pas leur superpouvoir et ils n’apprécient pas cette tâche. Il est temps de prendre exemple sur les pratiques d’ingénierie produit et de diversifier votre équipe de sécurité. Investissez stratégiquement dans des capacités complémentaires telles que les gestionnaires de programmes et de produits, des rédacteurs techniques, des experts en communication, ainsi que les spécialistes de l'analyse de données. Positionnés correctement dans l'organisation en tant que contributeurs clés, ces ressources seront des multiplicateurs de force pour vos ingénieurs et apporteront une vraie valeur ajoutée à l'entreprise.

Trouver son champion ne suffit pas !

Trop d'entreprises ne parviennent pas à recruter un gestionnaire de programme ou de communauté pour diriger et faciliter cette communauté interne. Pourtant, des champions de la sécurité correctement soutenus ont le potentiel d'aider les équipes de sécurité et d'ingénierie à avoir un impact plus important. Cette équipe virtuelle a besoin de leadership et de curation. Le profil idéal est un facilitateur ou un gestionnaire de communauté capable de créer un contenu et une structure attrayante, qui favorise un véritable partenariat, en s'appuyant sur des données objectives pour développer le programme et fournir des résultats commerciaux mesurables.

Le “tout ou rien” est un frein au progrès

Dans un monde idéal, DevSecOps permettrait d'obtenir un logiciel parfait, entièrement sécurisé, qui ne tombe jamais en panne et qui ne peut pas être violé. Mais la poursuite d'un objectif inatteignable peut souvent entraver la réalisation de progrès réels et tangibles. Plutôt que d'adopter une approche "tout ou rien", l'utilisation de conseils de sécurité "bon/mieux/meilleur" peut aider les ingénieurs à renforcer la sécurité tout au long du processus de développement. Ils peuvent ainsi progressivement prendre eux-mêmes de meilleures décisions en matière de risque pour l'avenir. C'est une simple question de psychologie : si vous fixez un objectif impossible à atteindre, la plupart des gens n'essaieront même pas. En revanche, si vous leur donnez des options ou si vous décomposez l'objectif global en étapes plus petites et réalisables, les équipes accumuleront rapidement les victoires faciles.

Aller au-delà des outils techniques pour sauver le DevSecOps

La mission de l'équipe de sécurité est de s'assurer que les clients peuvent faire confiance à la marque et aux produits de votre entreprise. La sécurisation des applications et des technologies n'est qu’une des tâches à accomplir pour y parvenir. Dans cette optique, les outils DevSecOps sont l'un des éléments d'un programme de sécurité efficace. Néanmoins, ils sont insuffisants en soi. Pour être profondément axés et engagés dans l'habilitation et la collaboration avec les entreprises, nous devons regarder au-delà de l'automatisation technique en diversifiant les équipes de sécurité et en redéfinissant les cadres culturels dans lesquels nous opérons. C’est ainsi que nous sauverons DevSecOps.