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.
L’une des solutions souvent suggérées pour un code plus sécurisé est l’analyse du code source. Les analyses de sécurité statiques et dynamiques sont devenues un ingrédient essentiel des processus de livraison continue. Nos propres pipelines internes les incluent, et je peux - à tout moment - jeter un œil à un tableau de bord qui me dit tout sur ce que ces analyses trouvent.
 |
Mais savoir que des vulnérabilités existent dans le code source - comme G.I. Joe nous le rappelle - n'est que la moitié de la bataille. Il serait fascinant que l’autre moitié soit réellement constituée de lasers bleus et rouges, mais la réalité de la sécurité des applications est que l’autre moitié consiste à « faire quelque chose à propos de ces vulnérabilités ». Malheureusement, nous ne voyons pas cette réalité devenir réalité. 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.