Les points clés sur la politique de gestion des correctifs
Malgré tout le temps que j'ai passé à m'entraîner sur des tapis de course, je les ai toujours trouvés légèrement démoralisants. On martèle le sol encore et encore. Et ce sans jamais aller nulle part. C'est pourtant un effort considérable. On transpire toujours un peu, mais on finit par se sentir insatisfait. Et ce sentiment est renforcé le lendemain, quand il faut tout recommencer.
Et bien sachez que à bien des égards, la sécurité des applications ressemble à ce tapis de course.
Une fois le codage terminé, les équipes de sécurité (ou les clients) trouvent des failles. Les outils d’analyse détectent eux aussi des failles, ce qui donne souvent lieu à des rapports qui semblent interminables. Les développeurs sont constamment arrachés à leurs nouveaux projets pour réétudier ce qu’ils ont écrit, localiser les bugs, les corriger et publier des correctifs.
Mais ensuite, comme sur le tapis de course, le cycle se répète lorsque de nouveaux codes, de nouvelles dépendances et de nouvelles vulnérabilités apparaissent. Car, bien sûr, elles apparaîtront.
Ce processus frustrant est souvent appelé le cycle « trouver-corriger ». Les équipes de sécurité et d’assurance qualité utilisent des scanners de vulnérabilité et des tests d’intrusion.
Lorsque des problèmes sont détectés, comme c’est inévitable, les développeurs travaillent à partir des rapports de bogues, mettent en place des files d’attente de triage et consacrent parfois des plages horaires à des sprints de correction.