Pourquoi les injections SQL sont les cafards du monde de la sécurité des applications (et comment les RSSI peuvent les éradiquer une fois pour toutes)
Selon une théorie bien connue, les blattes peuvent survivre à pratiquement tout, même à une explosion nucléaire. Bien que cette théorie ne soit vraie que dans une certaine mesure, leur composition corporelle simple les rend extrêmement résistants pour leur taille et difficiles à éradiquer dans la plupart des conditions.
Je me suis dit... si les cafards avaient un équivalent dans le monde numérique, il faudrait qu'il s'agisse de vulnérabilités d'injection SQL (SQLi) dans le code. Cette vulnérabilité est connue depuis plus de vingt ans, mais les organisations en sont victimes à maintes reprises. La très répandue, attaque coûteuse contre Target était le résultat d'une injection SQL, tout comme une instance de piratage des élections dans l'Illinois, où 200 000 dossiers d'électeurs ont été révélés, ce qui a incité le FBI à recommander à tous les administrateurs informatiques de renforcer rapidement leurs pratiques de sécurité.
D'Imperva Rapport sur la Hacker Intelligence Initiative a révélé qu'entre 2005 et 2011, des attaques SQLi ont été utilisées dans 83 % des violations de données signalées. Aujourd'hui, les vulnérabilités liées à l'injection restent la principale menace dans Top 10 de l'OWASP. Ils sont relativement simples, mais ils ne mourront tout simplement pas.
Il semble ridicule que cette même vulnérabilité apparaisse toujours dans un nombre important d'analyses de sécurité des applications. Nous savons comment il fonctionne et comment l'arrêter. Comment est-ce possible ? La vérité est que la sécurité de nos logiciels peut encore être améliorée.
de Veracode Rapport sur l'état de la sécurité logicielle - basé sur 400 000 scans d'applications en 2017 » a révélé une statistique alarmante : seulement 30 % des applications ont satisfait à la politique du Top 10 de l'OWASP. Ce thème a été récurrent au cours des cinq dernières années, des injections SQL étant apparues dans près d'une application récemment scannée sur trois. C'est la preuve d'un problème endémique ; nous ne tirons pas les leçons de nos erreurs et les responsables de la sécurité informatique semblent avoir du mal à recruter suffisamment de talents en matière de sécurité. En règle générale, le ratio entre les spécialistes de la sécurité des applications et les développeurs est insuffisant pour 100.
Pourquoi la sécurité logicielle est-elle en mode survie ?
Ce n'est un secret pour personne que les spécialistes de la sécurité sont rares, mais nous devons également faire attention au fait que les développeurs ne résolvent pas les problèmes au fur et à mesure qu'ils se présentent et sont clairement mal équipés pour ne pas introduire de vulnérabilités dès le départ. Dans le même rapport de Veracode, il a été révélé que des mesures d'atténuation documentées n'étaient disponibles que pour 14,4 % de toutes les vulnérabilités liées au développement. En d'autres termes, la plupart des vulnérabilités ont été soumises sans mesures d'atténuation liées au développement. Moins d'un tiers des vulnérabilités ont été corrigées au cours des 90 premiers jours, et 42 % des vulnérabilités n'ont jamais été corrigées au cours de la période de développement.
Je discute constamment avec des professionnels de la sécurité, des RSSI et des PDG et, pour l'anecdote, j'ai découvert que de nombreuses entreprises sont tellement frustrées par le nombre de vulnérabilités détectées qui ne peuvent être atténuées (en plus du fléau connu sous le nom de faux positifs), qu'elles arrêtent complètement de les rechercher, croisent les doigts et espèrent que tout ira pour le mieux.
Pourquoi les professionnels de l'AppSec laissent-ils cela se produire ?
Ne vous y trompez pas : les utilisateurs d'AppSec sont terriblement conscients des problèmes de code. Après tout, c'est l'une de leurs compétences de base qui fait d'eux une ressource d'équipe si précieuse. Cependant, ils sont souvent entravés par plusieurs facteurs.
Par exemple, un responsable AppSec détectera un problème et demandera au développeur : « Pouvez-vous corriger le code ? ». La réponse à cette question importante varie d'une organisation à l'autre, mais en général, le développeur est tellement sollicité pour respecter les stricts sprints de fourniture de fonctionnalités qu'il n'a tout simplement pas le temps de résoudre ces problèmes, ni les outils adéquats pour les aider. Les professionnels de la sécurité des applications eux-mêmes sont peut-être en mesure d'identifier les vulnérabilités, mais ils n'ont souvent pas les compétences et/ou l'accès nécessaires pour y remédier sur place.
Nous devons également réaliser que pour chaque problème, il faut trouver une solution, la mettre en œuvre, puis la tester. Même pour le moindre problème détecté dans le code, le temps qu'il faut pour le résoudre, sans parler des ressources requises, est immense. Plus de 700 vulnérabilités peuvent être introduites dans les logiciels, et il est tout simplement impossible pour une seule personne de pouvoir se défendre contre toutes ces vulnérabilités. C'est pour cette raison que la plupart des entreprises s'en tiennent uniquement au Top 10 de l'OWASP. Pendant ce temps, les développeurs continuent de créer des fonctionnalités et, à leur tour, d'introduire des vulnérabilités dans le code qu'ils écrivent.
Quelle est la solution ?
Le fait est que nous ne donnons pas à nos développeurs les outils et la formation nécessaires pour favoriser le succès du codage sécurisé. Aucune réglementation n'oblige les entreprises à s'assurer que les développeurs possèdent les compétences adéquates en matière de sécurité, et la triste réalité est que la plupart des universités et des stages ne préparent pas non plus les développeurs débutants à coder en toute sécurité.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Nous devons consacrer du temps à former les développeurs à l'écriture de code sécurisé. Cependant, dans le monde d'aujourd'hui, où le développement de logiciels est rapide et où les bons développeurs et professionnels de la sécurité sont rares, cela ne semble jamais être une priorité. Il est temps de changer de conversation.
Un titre récent du Forum économique mondial a crié : « Il ne peut y avoir d'économie numérique sans sécurité », avec le contenu qui l'accompagne faisant valoir la nécessité de placer la sécurité au cœur de toute stratégie de transformation numérique. « La sécurité est ce qui protège les entreprises, leur permet d'innover et de créer de nouveaux produits et services. Au-delà d'un rôle défensif, la sécurité fournit aux entreprises un avantage stratégique en termes de croissance. »
L'amélioration des compétences et des résultats en matière de codage sécurisé ajoutera une puissante couche de cyberprotection aux organisations, les aidant à créer un code plus efficace et plus rapide. Les développeurs n'ont pas besoin de devenir des experts en sécurité, mais ils doivent être habilités de manière positive et pratique pour être la première ligne de défense contre les cyberattaques. Les développeurs peuvent devenir les prochains héros de la sécurité et de l'innovation. Ce sont des personnes très intelligentes, elles savent résoudre les problèmes de manière créative et souhaitent généralement développer leurs compétences. Tirez parti de leurs points forts grâce à la formation spécialisée qu'ils méritent et engagez-vous à respecter des normes de sécurité logicielle plus strictes. Lisez notre livre blanc pour en savoir plus.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Selon une théorie bien connue, les blattes peuvent survivre à pratiquement tout, même à une explosion nucléaire.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Selon une théorie bien connue, les blattes peuvent survivre à pratiquement tout, même à une explosion nucléaire. Bien que cette théorie ne soit vraie que dans une certaine mesure, leur composition corporelle simple les rend extrêmement résistants pour leur taille et difficiles à éradiquer dans la plupart des conditions.
Je me suis dit... si les cafards avaient un équivalent dans le monde numérique, il faudrait qu'il s'agisse de vulnérabilités d'injection SQL (SQLi) dans le code. Cette vulnérabilité est connue depuis plus de vingt ans, mais les organisations en sont victimes à maintes reprises. La très répandue, attaque coûteuse contre Target était le résultat d'une injection SQL, tout comme une instance de piratage des élections dans l'Illinois, où 200 000 dossiers d'électeurs ont été révélés, ce qui a incité le FBI à recommander à tous les administrateurs informatiques de renforcer rapidement leurs pratiques de sécurité.
D'Imperva Rapport sur la Hacker Intelligence Initiative a révélé qu'entre 2005 et 2011, des attaques SQLi ont été utilisées dans 83 % des violations de données signalées. Aujourd'hui, les vulnérabilités liées à l'injection restent la principale menace dans Top 10 de l'OWASP. Ils sont relativement simples, mais ils ne mourront tout simplement pas.
Il semble ridicule que cette même vulnérabilité apparaisse toujours dans un nombre important d'analyses de sécurité des applications. Nous savons comment il fonctionne et comment l'arrêter. Comment est-ce possible ? La vérité est que la sécurité de nos logiciels peut encore être améliorée.
de Veracode Rapport sur l'état de la sécurité logicielle - basé sur 400 000 scans d'applications en 2017 » a révélé une statistique alarmante : seulement 30 % des applications ont satisfait à la politique du Top 10 de l'OWASP. Ce thème a été récurrent au cours des cinq dernières années, des injections SQL étant apparues dans près d'une application récemment scannée sur trois. C'est la preuve d'un problème endémique ; nous ne tirons pas les leçons de nos erreurs et les responsables de la sécurité informatique semblent avoir du mal à recruter suffisamment de talents en matière de sécurité. En règle générale, le ratio entre les spécialistes de la sécurité des applications et les développeurs est insuffisant pour 100.
Pourquoi la sécurité logicielle est-elle en mode survie ?
Ce n'est un secret pour personne que les spécialistes de la sécurité sont rares, mais nous devons également faire attention au fait que les développeurs ne résolvent pas les problèmes au fur et à mesure qu'ils se présentent et sont clairement mal équipés pour ne pas introduire de vulnérabilités dès le départ. Dans le même rapport de Veracode, il a été révélé que des mesures d'atténuation documentées n'étaient disponibles que pour 14,4 % de toutes les vulnérabilités liées au développement. En d'autres termes, la plupart des vulnérabilités ont été soumises sans mesures d'atténuation liées au développement. Moins d'un tiers des vulnérabilités ont été corrigées au cours des 90 premiers jours, et 42 % des vulnérabilités n'ont jamais été corrigées au cours de la période de développement.
Je discute constamment avec des professionnels de la sécurité, des RSSI et des PDG et, pour l'anecdote, j'ai découvert que de nombreuses entreprises sont tellement frustrées par le nombre de vulnérabilités détectées qui ne peuvent être atténuées (en plus du fléau connu sous le nom de faux positifs), qu'elles arrêtent complètement de les rechercher, croisent les doigts et espèrent que tout ira pour le mieux.
Pourquoi les professionnels de l'AppSec laissent-ils cela se produire ?
Ne vous y trompez pas : les utilisateurs d'AppSec sont terriblement conscients des problèmes de code. Après tout, c'est l'une de leurs compétences de base qui fait d'eux une ressource d'équipe si précieuse. Cependant, ils sont souvent entravés par plusieurs facteurs.
Par exemple, un responsable AppSec détectera un problème et demandera au développeur : « Pouvez-vous corriger le code ? ». La réponse à cette question importante varie d'une organisation à l'autre, mais en général, le développeur est tellement sollicité pour respecter les stricts sprints de fourniture de fonctionnalités qu'il n'a tout simplement pas le temps de résoudre ces problèmes, ni les outils adéquats pour les aider. Les professionnels de la sécurité des applications eux-mêmes sont peut-être en mesure d'identifier les vulnérabilités, mais ils n'ont souvent pas les compétences et/ou l'accès nécessaires pour y remédier sur place.
Nous devons également réaliser que pour chaque problème, il faut trouver une solution, la mettre en œuvre, puis la tester. Même pour le moindre problème détecté dans le code, le temps qu'il faut pour le résoudre, sans parler des ressources requises, est immense. Plus de 700 vulnérabilités peuvent être introduites dans les logiciels, et il est tout simplement impossible pour une seule personne de pouvoir se défendre contre toutes ces vulnérabilités. C'est pour cette raison que la plupart des entreprises s'en tiennent uniquement au Top 10 de l'OWASP. Pendant ce temps, les développeurs continuent de créer des fonctionnalités et, à leur tour, d'introduire des vulnérabilités dans le code qu'ils écrivent.
Quelle est la solution ?
Le fait est que nous ne donnons pas à nos développeurs les outils et la formation nécessaires pour favoriser le succès du codage sécurisé. Aucune réglementation n'oblige les entreprises à s'assurer que les développeurs possèdent les compétences adéquates en matière de sécurité, et la triste réalité est que la plupart des universités et des stages ne préparent pas non plus les développeurs débutants à coder en toute sécurité.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Nous devons consacrer du temps à former les développeurs à l'écriture de code sécurisé. Cependant, dans le monde d'aujourd'hui, où le développement de logiciels est rapide et où les bons développeurs et professionnels de la sécurité sont rares, cela ne semble jamais être une priorité. Il est temps de changer de conversation.
Un titre récent du Forum économique mondial a crié : « Il ne peut y avoir d'économie numérique sans sécurité », avec le contenu qui l'accompagne faisant valoir la nécessité de placer la sécurité au cœur de toute stratégie de transformation numérique. « La sécurité est ce qui protège les entreprises, leur permet d'innover et de créer de nouveaux produits et services. Au-delà d'un rôle défensif, la sécurité fournit aux entreprises un avantage stratégique en termes de croissance. »
L'amélioration des compétences et des résultats en matière de codage sécurisé ajoutera une puissante couche de cyberprotection aux organisations, les aidant à créer un code plus efficace et plus rapide. Les développeurs n'ont pas besoin de devenir des experts en sécurité, mais ils doivent être habilités de manière positive et pratique pour être la première ligne de défense contre les cyberattaques. Les développeurs peuvent devenir les prochains héros de la sécurité et de l'innovation. Ce sont des personnes très intelligentes, elles savent résoudre les problèmes de manière créative et souhaitent généralement développer leurs compétences. Tirez parti de leurs points forts grâce à la formation spécialisée qu'ils méritent et engagez-vous à respecter des normes de sécurité logicielle plus strictes. Lisez notre livre blanc pour en savoir plus.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Selon une théorie bien connue, les blattes peuvent survivre à pratiquement tout, même à une explosion nucléaire. Bien que cette théorie ne soit vraie que dans une certaine mesure, leur composition corporelle simple les rend extrêmement résistants pour leur taille et difficiles à éradiquer dans la plupart des conditions.
Je me suis dit... si les cafards avaient un équivalent dans le monde numérique, il faudrait qu'il s'agisse de vulnérabilités d'injection SQL (SQLi) dans le code. Cette vulnérabilité est connue depuis plus de vingt ans, mais les organisations en sont victimes à maintes reprises. La très répandue, attaque coûteuse contre Target était le résultat d'une injection SQL, tout comme une instance de piratage des élections dans l'Illinois, où 200 000 dossiers d'électeurs ont été révélés, ce qui a incité le FBI à recommander à tous les administrateurs informatiques de renforcer rapidement leurs pratiques de sécurité.
D'Imperva Rapport sur la Hacker Intelligence Initiative a révélé qu'entre 2005 et 2011, des attaques SQLi ont été utilisées dans 83 % des violations de données signalées. Aujourd'hui, les vulnérabilités liées à l'injection restent la principale menace dans Top 10 de l'OWASP. Ils sont relativement simples, mais ils ne mourront tout simplement pas.
Il semble ridicule que cette même vulnérabilité apparaisse toujours dans un nombre important d'analyses de sécurité des applications. Nous savons comment il fonctionne et comment l'arrêter. Comment est-ce possible ? La vérité est que la sécurité de nos logiciels peut encore être améliorée.
de Veracode Rapport sur l'état de la sécurité logicielle - basé sur 400 000 scans d'applications en 2017 » a révélé une statistique alarmante : seulement 30 % des applications ont satisfait à la politique du Top 10 de l'OWASP. Ce thème a été récurrent au cours des cinq dernières années, des injections SQL étant apparues dans près d'une application récemment scannée sur trois. C'est la preuve d'un problème endémique ; nous ne tirons pas les leçons de nos erreurs et les responsables de la sécurité informatique semblent avoir du mal à recruter suffisamment de talents en matière de sécurité. En règle générale, le ratio entre les spécialistes de la sécurité des applications et les développeurs est insuffisant pour 100.
Pourquoi la sécurité logicielle est-elle en mode survie ?
Ce n'est un secret pour personne que les spécialistes de la sécurité sont rares, mais nous devons également faire attention au fait que les développeurs ne résolvent pas les problèmes au fur et à mesure qu'ils se présentent et sont clairement mal équipés pour ne pas introduire de vulnérabilités dès le départ. Dans le même rapport de Veracode, il a été révélé que des mesures d'atténuation documentées n'étaient disponibles que pour 14,4 % de toutes les vulnérabilités liées au développement. En d'autres termes, la plupart des vulnérabilités ont été soumises sans mesures d'atténuation liées au développement. Moins d'un tiers des vulnérabilités ont été corrigées au cours des 90 premiers jours, et 42 % des vulnérabilités n'ont jamais été corrigées au cours de la période de développement.
Je discute constamment avec des professionnels de la sécurité, des RSSI et des PDG et, pour l'anecdote, j'ai découvert que de nombreuses entreprises sont tellement frustrées par le nombre de vulnérabilités détectées qui ne peuvent être atténuées (en plus du fléau connu sous le nom de faux positifs), qu'elles arrêtent complètement de les rechercher, croisent les doigts et espèrent que tout ira pour le mieux.
Pourquoi les professionnels de l'AppSec laissent-ils cela se produire ?
Ne vous y trompez pas : les utilisateurs d'AppSec sont terriblement conscients des problèmes de code. Après tout, c'est l'une de leurs compétences de base qui fait d'eux une ressource d'équipe si précieuse. Cependant, ils sont souvent entravés par plusieurs facteurs.
Par exemple, un responsable AppSec détectera un problème et demandera au développeur : « Pouvez-vous corriger le code ? ». La réponse à cette question importante varie d'une organisation à l'autre, mais en général, le développeur est tellement sollicité pour respecter les stricts sprints de fourniture de fonctionnalités qu'il n'a tout simplement pas le temps de résoudre ces problèmes, ni les outils adéquats pour les aider. Les professionnels de la sécurité des applications eux-mêmes sont peut-être en mesure d'identifier les vulnérabilités, mais ils n'ont souvent pas les compétences et/ou l'accès nécessaires pour y remédier sur place.
Nous devons également réaliser que pour chaque problème, il faut trouver une solution, la mettre en œuvre, puis la tester. Même pour le moindre problème détecté dans le code, le temps qu'il faut pour le résoudre, sans parler des ressources requises, est immense. Plus de 700 vulnérabilités peuvent être introduites dans les logiciels, et il est tout simplement impossible pour une seule personne de pouvoir se défendre contre toutes ces vulnérabilités. C'est pour cette raison que la plupart des entreprises s'en tiennent uniquement au Top 10 de l'OWASP. Pendant ce temps, les développeurs continuent de créer des fonctionnalités et, à leur tour, d'introduire des vulnérabilités dans le code qu'ils écrivent.
Quelle est la solution ?
Le fait est que nous ne donnons pas à nos développeurs les outils et la formation nécessaires pour favoriser le succès du codage sécurisé. Aucune réglementation n'oblige les entreprises à s'assurer que les développeurs possèdent les compétences adéquates en matière de sécurité, et la triste réalité est que la plupart des universités et des stages ne préparent pas non plus les développeurs débutants à coder en toute sécurité.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Nous devons consacrer du temps à former les développeurs à l'écriture de code sécurisé. Cependant, dans le monde d'aujourd'hui, où le développement de logiciels est rapide et où les bons développeurs et professionnels de la sécurité sont rares, cela ne semble jamais être une priorité. Il est temps de changer de conversation.
Un titre récent du Forum économique mondial a crié : « Il ne peut y avoir d'économie numérique sans sécurité », avec le contenu qui l'accompagne faisant valoir la nécessité de placer la sécurité au cœur de toute stratégie de transformation numérique. « La sécurité est ce qui protège les entreprises, leur permet d'innover et de créer de nouveaux produits et services. Au-delà d'un rôle défensif, la sécurité fournit aux entreprises un avantage stratégique en termes de croissance. »
L'amélioration des compétences et des résultats en matière de codage sécurisé ajoutera une puissante couche de cyberprotection aux organisations, les aidant à créer un code plus efficace et plus rapide. Les développeurs n'ont pas besoin de devenir des experts en sécurité, mais ils doivent être habilités de manière positive et pratique pour être la première ligne de défense contre les cyberattaques. Les développeurs peuvent devenir les prochains héros de la sécurité et de l'innovation. Ce sont des personnes très intelligentes, elles savent résoudre les problèmes de manière créative et souhaitent généralement développer leurs compétences. Tirez parti de leurs points forts grâce à la formation spécialisée qu'ils méritent et engagez-vous à respecter des normes de sécurité logicielle plus strictes. Lisez notre livre blanc pour en savoir plus.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Afficher le rapportRéservez une démo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Selon une théorie bien connue, les blattes peuvent survivre à pratiquement tout, même à une explosion nucléaire. Bien que cette théorie ne soit vraie que dans une certaine mesure, leur composition corporelle simple les rend extrêmement résistants pour leur taille et difficiles à éradiquer dans la plupart des conditions.
Je me suis dit... si les cafards avaient un équivalent dans le monde numérique, il faudrait qu'il s'agisse de vulnérabilités d'injection SQL (SQLi) dans le code. Cette vulnérabilité est connue depuis plus de vingt ans, mais les organisations en sont victimes à maintes reprises. La très répandue, attaque coûteuse contre Target était le résultat d'une injection SQL, tout comme une instance de piratage des élections dans l'Illinois, où 200 000 dossiers d'électeurs ont été révélés, ce qui a incité le FBI à recommander à tous les administrateurs informatiques de renforcer rapidement leurs pratiques de sécurité.
D'Imperva Rapport sur la Hacker Intelligence Initiative a révélé qu'entre 2005 et 2011, des attaques SQLi ont été utilisées dans 83 % des violations de données signalées. Aujourd'hui, les vulnérabilités liées à l'injection restent la principale menace dans Top 10 de l'OWASP. Ils sont relativement simples, mais ils ne mourront tout simplement pas.
Il semble ridicule que cette même vulnérabilité apparaisse toujours dans un nombre important d'analyses de sécurité des applications. Nous savons comment il fonctionne et comment l'arrêter. Comment est-ce possible ? La vérité est que la sécurité de nos logiciels peut encore être améliorée.
de Veracode Rapport sur l'état de la sécurité logicielle - basé sur 400 000 scans d'applications en 2017 » a révélé une statistique alarmante : seulement 30 % des applications ont satisfait à la politique du Top 10 de l'OWASP. Ce thème a été récurrent au cours des cinq dernières années, des injections SQL étant apparues dans près d'une application récemment scannée sur trois. C'est la preuve d'un problème endémique ; nous ne tirons pas les leçons de nos erreurs et les responsables de la sécurité informatique semblent avoir du mal à recruter suffisamment de talents en matière de sécurité. En règle générale, le ratio entre les spécialistes de la sécurité des applications et les développeurs est insuffisant pour 100.
Pourquoi la sécurité logicielle est-elle en mode survie ?
Ce n'est un secret pour personne que les spécialistes de la sécurité sont rares, mais nous devons également faire attention au fait que les développeurs ne résolvent pas les problèmes au fur et à mesure qu'ils se présentent et sont clairement mal équipés pour ne pas introduire de vulnérabilités dès le départ. Dans le même rapport de Veracode, il a été révélé que des mesures d'atténuation documentées n'étaient disponibles que pour 14,4 % de toutes les vulnérabilités liées au développement. En d'autres termes, la plupart des vulnérabilités ont été soumises sans mesures d'atténuation liées au développement. Moins d'un tiers des vulnérabilités ont été corrigées au cours des 90 premiers jours, et 42 % des vulnérabilités n'ont jamais été corrigées au cours de la période de développement.
Je discute constamment avec des professionnels de la sécurité, des RSSI et des PDG et, pour l'anecdote, j'ai découvert que de nombreuses entreprises sont tellement frustrées par le nombre de vulnérabilités détectées qui ne peuvent être atténuées (en plus du fléau connu sous le nom de faux positifs), qu'elles arrêtent complètement de les rechercher, croisent les doigts et espèrent que tout ira pour le mieux.
Pourquoi les professionnels de l'AppSec laissent-ils cela se produire ?
Ne vous y trompez pas : les utilisateurs d'AppSec sont terriblement conscients des problèmes de code. Après tout, c'est l'une de leurs compétences de base qui fait d'eux une ressource d'équipe si précieuse. Cependant, ils sont souvent entravés par plusieurs facteurs.
Par exemple, un responsable AppSec détectera un problème et demandera au développeur : « Pouvez-vous corriger le code ? ». La réponse à cette question importante varie d'une organisation à l'autre, mais en général, le développeur est tellement sollicité pour respecter les stricts sprints de fourniture de fonctionnalités qu'il n'a tout simplement pas le temps de résoudre ces problèmes, ni les outils adéquats pour les aider. Les professionnels de la sécurité des applications eux-mêmes sont peut-être en mesure d'identifier les vulnérabilités, mais ils n'ont souvent pas les compétences et/ou l'accès nécessaires pour y remédier sur place.
Nous devons également réaliser que pour chaque problème, il faut trouver une solution, la mettre en œuvre, puis la tester. Même pour le moindre problème détecté dans le code, le temps qu'il faut pour le résoudre, sans parler des ressources requises, est immense. Plus de 700 vulnérabilités peuvent être introduites dans les logiciels, et il est tout simplement impossible pour une seule personne de pouvoir se défendre contre toutes ces vulnérabilités. C'est pour cette raison que la plupart des entreprises s'en tiennent uniquement au Top 10 de l'OWASP. Pendant ce temps, les développeurs continuent de créer des fonctionnalités et, à leur tour, d'introduire des vulnérabilités dans le code qu'ils écrivent.
Quelle est la solution ?
Le fait est que nous ne donnons pas à nos développeurs les outils et la formation nécessaires pour favoriser le succès du codage sécurisé. Aucune réglementation n'oblige les entreprises à s'assurer que les développeurs possèdent les compétences adéquates en matière de sécurité, et la triste réalité est que la plupart des universités et des stages ne préparent pas non plus les développeurs débutants à coder en toute sécurité.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Nous devons consacrer du temps à former les développeurs à l'écriture de code sécurisé. Cependant, dans le monde d'aujourd'hui, où le développement de logiciels est rapide et où les bons développeurs et professionnels de la sécurité sont rares, cela ne semble jamais être une priorité. Il est temps de changer de conversation.
Un titre récent du Forum économique mondial a crié : « Il ne peut y avoir d'économie numérique sans sécurité », avec le contenu qui l'accompagne faisant valoir la nécessité de placer la sécurité au cœur de toute stratégie de transformation numérique. « La sécurité est ce qui protège les entreprises, leur permet d'innover et de créer de nouveaux produits et services. Au-delà d'un rôle défensif, la sécurité fournit aux entreprises un avantage stratégique en termes de croissance. »
L'amélioration des compétences et des résultats en matière de codage sécurisé ajoutera une puissante couche de cyberprotection aux organisations, les aidant à créer un code plus efficace et plus rapide. Les développeurs n'ont pas besoin de devenir des experts en sécurité, mais ils doivent être habilités de manière positive et pratique pour être la première ligne de défense contre les cyberattaques. Les développeurs peuvent devenir les prochains héros de la sécurité et de l'innovation. Ce sont des personnes très intelligentes, elles savent résoudre les problèmes de manière créative et souhaitent généralement développer leurs compétences. Tirez parti de leurs points forts grâce à la formation spécialisée qu'ils méritent et engagez-vous à respecter des normes de sécurité logicielle plus strictes. Lisez notre livre blanc pour en savoir plus.
Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.
Table des matières
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démoTéléchargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
