La lourde charge de la sécurisation du logiciel

Bien qu'il faille la prendre avec un minimum de précautions puisqu'elle est commanditée par un éditeur spécialisé (JFrog), cette enquête d'IDC qui révèle que les développeurs de logiciels passent une partie (trop) importante de leur temps dans des tâches liées à la sécurité devrait probablement interpeller les responsables informatiques.

Par exemple, la moitié de l'échantillon – issu des différents métiers concernés, depuis les product owners jusqu'aux chefs de projet en passant par les professionnels (seniors) du code, dans des entreprises américaines, britanniques, françaises et allemandes – déclarent consacrer 19% de leurs efforts à des contrôles et autres corrections relatifs à la sécurité… souvent en dehors des heures de travail « normales », qui plus est. Cela représenterait un budget d'environ 28 000 dollars annuels par développeur.

Dans un sens, mais l'étude n'aborde pas ce point de vue, ces statistiques constituent une excellente nouvelle. Elles démontrent en effet que les démarches dites « DevSecOps », qui visent à intégrer les considérations de sécurité en continu, au cœur de la chaîne de création du logiciel (avec les exigences de déploiement en production), commencent à s'ancrer dans les habitudes, ce qui profite automatiquement à la qualité des solutions livrées et à la réduction des risques lors de leur utilisation.

En revanche, au vu des estimations avancées, se pose tout de même la question d'un possible excès. Après tout, on peut considérer que le talent des personnes qui sont recrutées, toujours plus difficilement et souvent à prix d'or, pour écrire des applications est quelque peu gaspillé quand il leur faut aussi se préoccuper de problématiques périphériques, certes critiques pour le résultat final mais qui ne requièrent pas, en principe, leur expertise, d'autant que leur prise en charge devrait être automatisée.

Tel est justement le point sur lequel JFrog insiste particulièrement, en imputant l'essentiel de la faute à l'outillage mis en œuvre, soit qu'il soit mal adapté et exige des vérifications manuelles complémentaires inutiles ou redondantes, soit que son hétérogénéité et l’absence d’expérience utilisateur sans coutures engendrent des ruptures régulières dans le flot d’activité normal, au détriment de la productivité. Cette réalité conduit à relativiser le constat de maturité des organisations… et de leurs fournisseurs.

Mais, comme toujours, l’équipement n’est peut-être pas le seul coupable direct. Je soupçonne que le manque de culture de sécurité chez les ingénieurs, quand il ne s’agit pas de leur spécialité officielle, joue également un rôle crucial. D’abord parce que, à l’opposé de la philosophie « DevSecOps », il tend à laisser s’introduire les failles, qui ne sont corrigées qu’a posteriori, lorsqu’elles sont détectées par une sonde. Ensuite parce que la présence même de solutions automatiques encourage la « paresse » : pourquoi faire attention puisque les erreurs seront toujours repérées, plus tard ?

Si mon hypothèse était confirmée, nous aurions ainsi affaire à un effet pervers classique de la technologie : déchargeant les individus de leur responsabilité alors qu'elle est encore incapable de les remplacer totalement – quand bien même elle se gausse d'intelligence artificielle –, elle s'avère finalement plus néfaste que bénéfique.