Premiers secours en cas de vulnérabilités : renoncez au 100 % DIY
Jamais le code n’a comporté autant de vulnérabilités. Logique, car il n’y a jamais eu autant de code, et pourtant le risque augmente de manière asymétrique. En 2000, on dénombrait à peine 1.020 vulnérabilités CVE enregistrées. En 2010, il y en avait juste un peu plus : 4.155. En 2017, ce nombre a explosé pour atteindre 14.714 CVE, contre 6.454 un an plus tôt. Et pas moins de 20.149 nouvelles vulnérabilités qui ont été détectées en 2021.
Tous les bugs logiciels n’ont pas la même gravité, mais les chiffres ne mentent pas : le nombre de brèches dans les logiciels est en forte augmentation. De plus, et ce n’est un secret pour personne, les organisations tardent parfois à installer les patchs importants, si bien que d’anciennes vulnérabilités subsistent. Ajoutez à cela que les cyberorganisations criminelles prennent aujourd’hui la forme d’entreprises vraiment organisées et assoiffées de profit, et vous comprendrez pourquoi il est plus important que jamais d’avoir un code parfaitement hermétique.
1. Travaillez selon les règles de l’art
Plus facile à dire qu’à faire. En tant que développeur, vous pouvez tout d’abord vous en tenir à quelques bonnes pratiques. Certains bugs peuvent être attribués à la paresse et donc être facilement évités. Vous développez une application qui traite l’input d’utilisateurs ? Assurez-vous que tout l’input est correctement validé. En effet, l’injection SQL est un risque courant et dangereux.
Par ailleurs, veillez à la qualité des messages d’erreur, à un cryptage suffisant des données sensibles, à la norme HTTPS pour les pages web, à un système de connexion sécurisé le cas échéant, etc. Plus aucune excuse n’est tolérée pour un utilisateur qui voit s’afficher le message « votre mot de passe est trop long ». Tout le monde commet des erreurs, mais en gardant la sécurité à l’esprit dès le début du développement d’une application, vous serez sur la bonne voie.
2. Dépendances vulnérables
Les vulnérabilités les plus dangereuses ne sont toutefois pas de votre faute. La plupart des applications reposent sur des bibliothèques externes populaires. Lorsqu’une attaque zero day se présente, c’est la douche froide. L’innocente bibliothèque Log4j, dans laquelle la vulnérabilité Log4Shell a subitement exposé la moitié du monde aux cybercriminels, en est un bon exemple.
Analyser vous-même toutes les bibliothèques externes ? Mission impossible ! Fort heureusement, il existe des outils pour vous aider, qui effectuent des scans automatisés pour indiquer si votre application s’appuie sur une bibliothèque présentant une vulnérabilité connue. De plus, les solutions de sécurité n’examinent pas nécessairement le code lui-même, mais vérifient si les composants open source sont dignes de confiance. Mieux vaut peut-être éviter d’intégrer cette ancienne version de Log4j…
3. Scanner le code propre
De tels outils automatisés existent également pour votre propre code. Les solutions viennent tant d’entreprises de sécurité classiques que d’acteurs spécialisés. Ils sont capables de trouver des erreurs courantes que vous pourriez ne pas remarquer au cours d’une journée bien remplie. C’est possible dans le référentiel GitHub où se trouve votre projet, ou directement dans votre IDE. De cette manière, vous corrigez les erreurs avant même que votre code ne soit compilé, et en tout cas avant qu’il n’entre en production. Prévenir prend moins de temps que guérir. Autre avantage : certains outils suggèrent immédiatement une solution.
Enfin, il est préférable de partir du principe que même les meilleures pratiques et les outils les plus utiles ne garantissent pas une sécurité absolue. Plus l’environnement dans lequel tourne votre app est sécurisé et plus la configuration qui l’entoure est bonne, moins il y a de risques de véritable problème. Cette collaboration entre le développeur et l’équipe informatique opérationnelle en matière de sécurité fait également partie de DevOps. Lorsque tout le monde prend ses responsabilités et se conforme aux meilleures pratiques, il y a moins de risques que quelque chose se passe mal.
4. Plus qu’un simple patch
Pour finir, si un composant présente quand même un bug quelque part, ou si vous avez commis une erreur : corrigez-le immédiatement sans refermer directement votre laptop. Le patch s’est-il attaqué au cœur du problème ? Ou avez-vous simplement posé un emplâtre sur une jambe de bois ? Une récente étude de Google Project Zero a révélé que la moitié des failles zero day découvertes au premier semestre de 2022 étaient une variante d’un bug découvert antérieurement mais mal patché.
Le développeur qui prend la sécurité au sérieux, adhère à la culture appropriée et déploie le cas échéant des outils et des ressources, est armé autant que faire se peut contre les menaces croissantes. Vous pouvez en être fier, et espérons que l’entreprise que vous rejoindrez appréciera cela à sa juste valeur.
Safety first ! Cela vous fait aussi immédiatement penser à la cybersécurité ? Vous êtes un crack en matière de premiers secours en cas de vulnérabilités ? Dans ce cas, nous avons certainement un job fait pour vous !