Connaître les vulnérabilités n’est que la moitié de la bataille
Alors que nous poursuivons notre voyage vers l’informatique continue, l’accent est mis en priorité sur la sécurité. Et il devrait bien en être ainsi. Les violations sont nombreuses. Des vulnérabilités sont découvertes quotidiennement et l’écart en matière de correctifs ne semble pas se réduire.
Une solution souvent proposée pour sécuriser davantage le code consiste à analyser le code source. Les analyses de sécurité statiques et dynamiques sont désormais des éléments clés des processus de livraison continue. Nos propres pipelines internes les intègrent, et vous pouvez à tout moment consulter un tableau de bord qui affiche tous les résultats de ces analyses.
 |
Cependant, savoir que des vulnérabilités existent dans le code source — comme G.I. Joe nous le rappelle — ne constitue que la moitié du combat. Si seulement l’autre moitié se matérialisait vraiment par des lasers bleus et rouges, ce serait fascinant, mais en réalité, la sécurité des applications consiste à agir face à ces vulnérabilités. Malheureusement, je constate que cette approche reste trop souvent un simple vœu. Vous vous souvenez peut-être d'un rapport Tripwire ( État de la sécurité des conteneurs 2019 ) dans lequel 17 % des personnes interrogées ont admis avoir des conteneurs vulnérables, savaient ce qu'ils étaient et les ont quand même déployés. Vous vous souviendrez peut-être également d'un rapport Arxan/IBM de 2017 sur la sécurité des applications mobiles et IoT qui a révélé que 53 % des personnes interrogées utilisent des tests de sécurité statiques et 51 % utilisent des tests de sécurité dynamiques pour les applications mobiles. Et malgré de fortes inquiétudes concernant une violation, près de la moitié (44 %) ne prenaient aucune mesure pour l’empêcher. |
Le problème de ne pas tester et de ne rien faire face aux vulnérabilités connues est presque toujours lié à la pression visant à réduire le délai de rentabilisation. Près de la moitié (48 %) des développeurs déclarent qu'ils n'ont pas assez de temps à consacrer à la sécurité ( enquête communautaire DevSecOps 2018 ). D’autres enquêtes le confirment : les développeurs sont soumis à une pression incroyable pour produire du code plus rapidement et plus fréquemment. Il s'avère que la sécurité continue d'être la « chose » qui est abandonnée lorsque la vitesse est en jeu, que ce soit au niveau des données ou du chemin de livraison.
Il est bien établi que les gens travaillent pour atteindre leurs objectifs. Et comme les développeurs sont des personnes, cela signifie qu’ils sont également soumis à cette règle. S'ils veulent arriver rapidement sur le marché, ils travailleront dans ce sens, même si cela signifie sauter des étapes qui compromettent la sécurité. Si nous voulons proposer des applications sécurisées sur le marché, nous devons adopter un changement culturel qui mesure et valorise la mise sur le marché sécurisée autant que la mise sur le marché rapide .
En attendant, nous pouvons tout aussi bien compter sur les lasers rouges et bleus pour traiter les vulnérabilités que sur les développeurs.