« L’annonce de la nouvelle vulnérabilité critique d’OpenSSL a immédiatement fait resurgir des souvenirs peu glorieux de Heartbleed ou, plus récemment, de la vulnérabilité Log4J. Heartbleed a eu un impact considérable sur toutes les équipes d’exploitation du monde entier et, depuis lors, l’infrastructure informatique est devenue dix fois plus compliquée. Lorsque Heartbleed a été découvert, la majorité des organisations informatiques utilisaient du matériel dédié ou des machines virtuelles (VM). Mais maintenant, nous sommes dans l’ère du Cloud Native, qui a créé des conteneurs avancés et des architectures sans serveur.

Le vecteur d’attaque est devenu beaucoup plus important, et plutôt que de devoir simplement examiner leurs machines virtuelles, les organisations doivent commencer à se préparer à patcher toutes leurs images de conteneurs en réponse à cette annonce. Espérons que la vulnérabilité de Log4J a incité beaucoup d’équipes à vérifier leurs dépendances. Si c’est le cas, ces étapes aideront les équipes à déployer rapidement un correctif ciblé sur leur infrastructure. Les SBOM (Software Bill of Materials – Inventaire logiciel) de toutes les images de conteneurs sont un excellent point de départ pour obtenir ces informations sur les dépendances de vos applications et de votre infrastructure.

Nous savons également que les versions d’OpenSSL antérieures à 3.0 ne sont pas concernées et que de nombreux systèmes d’exploitation utilisent OpenSSL 1.1, de sorte que ces environnements ne seront pas touchés. Ces connaissances permettront aux équipes chargées de la cybersécurité et des opérations d’écarter de grandes parties de leur infrastructure et, espérons-le, de rendre l’impact de cette vulnérabilité plus faible que prévu initialement. Mais les équipes d’ingénierie des plates-formes devraient continuer à investir dans un meilleur audit de leurs environnements et de leurs dépendances pour la prochaine menace, qui n’est jamais loin. »