Le facteur humain oublié à l'origine des failles de sécurité des applications Web
Le rapport 2018 de Verizon sur les enquêtes sur les violations de données est une fois de plus une excellente lecture qui nous permet de rester au courant de l'actualité en matière de cybersécurité, notamment des tendances actuelles en matière de cybercriminalité et des facteurs d'incidents, des analyses et des informations qui peuvent aider les entreprises à faire évoluer leur programme de sécurité. Cette année, les enquêteurs de Verizon ont analysé plus de 53 000 incidents et quelque 2 200 violations. Ils ont tiré de nombreux enseignements tangibles sur ce qu'il faut surveiller et ne pas faire, ainsi que de précieuses recommandations sur les domaines sur lesquels concentrer les efforts de sécurité. Le rapport de 2018 semble avoir évolué avec le temps, être pertinent pour un public plus large d'entreprises à mesure que les impacts sur la sécurité s'étendent, et être de plus en plus reconnu comme un problème commercial courant.
Parmi les nombreuses conclusions intéressantes, le rapport de 2018 confirme que la plupart des piratages se produisent toujours par le biais de violations d'applications Web (il existe même un graphique interactif sympa qui le montre).
Les attaques d'applications Web consistent en tout incident au cours duquel une application Web a été le vecteur de l'attaque. Cela inclut l'exploitation des vulnérabilités au niveau du code de l'application ainsi que le blocage des mécanismes d'authentification. Il convient de noter que le nombre de violations de ce type est réduit en raison du filtrage des attaques liées aux botnets sur les applications Web à l'aide d'informations d'identification volées sur les appareils appartenant aux clients. L'utilisation d'informations d'identification volées reste la principale forme de piratage lors de violations impliquant des applications Web, suivie par SQLi (plus d'informations sur SQL plus tard...).
L'un des thèmes qui ressort du rapport de cette année est l'importance du « facteur humain » dans l'équation de la sécurité, à la fois en tant que partie intégrante du problème et de la solution. Le rapport traite à la fois des acteurs externes et internes, indiquant que les erreurs étaient à l'origine de près d'une violation sur cinq (17 %). Des violations se sont produites lorsque des employés n'ont pas réussi à détruire des informations confidentielles, lorsqu'ils ont envoyé un e-mail à la mauvaise personne et lorsque les serveurs Web étaient mal configurés. Le rapport souligne que même si aucune de ces mesures n'était délibérément mal intentionnée, elles pourraient toutes s'avérer coûteuses.
Mais il existe un facteur humain souvent oublié qui est à l'origine de nombreuses failles de sécurité, à savoir la fréquence élevée à laquelle les développeurs créent du code contenant des failles de sécurité, ce qui entraîne des vulnérabilités des applications Web, qui à leur tour entraînent ces incidents et ces violations.
Les tests d'applications réalisés au cours des 5 dernières années n'ont pas montré d'amélioration significative du nombre de vulnérabilités détectées et les mêmes failles réapparaissent à maintes reprises. Un rapport Veracode de 2017 basé sur 400 000 scans d'applications montre que les applications ont respecté la politique des 10 meilleures applications de l'OWASP dans 30 % des cas seulement. Étonnamment, les injections SQL sont apparues dans près d'une application récemment scannée sur trois au cours des 5 dernières années, y compris l'année dernière. Je dis « étonnant », car les injections SQL existent depuis 1999. Le fait que les mêmes failles, y compris les injections SQL, soient constamment découvertes prouve que ce problème de « facteur humain » chez les développeurs n'est pas traité de manière adéquate.
C'est à ce stade que je dois me lever et dire que je suis du côté des développeurs dans cet argument. Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
C'est ce que nous faisons chez Secure Code Warrior et nous constatons que les entreprises qui intègrent une formation pratique au code sécurisé dans la vie quotidienne de leurs développeurs réduisent le nombre de vulnérabilités créées dans les applications Web. Pour pouvoir écrire du code sécurisé, les développeurs ont besoin d'un accès régulier à des formations pratiques qui les incitent activement à développer leurs compétences en matière de codage sécurisé. Ils doivent se renseigner sur les vulnérabilités récemment identifiées, en code réel, et plus particulièrement dans leurs propres langages/frameworks. Cette expérience d'apprentissage devrait les aider à comprendre comment localiser, identifier et corriger les vulnérabilités connues. Les développeurs ont également besoin d'un ensemble d'outils de qualité dans leur processus qui facilite la sécurité, ne les ralentit pas et les oriente en temps réel sur les bons et les mauvais modèles de codage.
C'est ainsi que nous pouvons faire une différence tangible et positive en ce qui concerne le nombre de violations des applications Web.
Je suis totalement d'accord avec Verizon pour dire qu'il est nécessaire de renforcer la formation en matière de sensibilisation à la sécurité à l'échelle de l'entreprise. Mon message à ce sujet aux DSI et aux RSSI est « n'oubliez pas vos développeurs ! ». Ces architectes de vos entreprises modernes peuvent être un « facteur humain » important qui génère régulièrement des points d'accès pour les pirates informatiques, ou ils peuvent être votre première ligne de défense, vos héros de sécurité.
Une mise à niveau efficace des compétences en matière de sécurité pour les développeurs pourrait faire une réelle différence dans les résultats rapportés par Verizon dans ses prochains rapports. Il serait intéressant de voir que le rapport 2019 présente la formation des développeurs en matière de sécurité comme une stratégie clé de réduction des risques que les entreprises peuvent adopter. Je suis optimiste, mais je parie que si les entreprises apprenaient à leurs développeurs comment éviter de créer des failles d'injection, le nombre de vulnérabilités des applications Web mentionnées dans ce rapport diminuerait de manière significative.
Jetez un œil à notre plateforme en action pour découvrir comment les développeurs peuvent améliorer leurs compétences rapidement dans un environnement de formation idéal et ludique :
Jouez à un défi de codage sécurisé
Consultez nos ressources d'apprentissage gratuites
Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
首席执行官、主席和联合创始人
Secure Code Warrior 在整个软件开发周期中保障代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管，还是其他任何参与安全工作的人员，我们都能协助您的组织降低不安全代码带来的风险。
预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
Le rapport 2018 de Verizon sur les enquêtes sur les violations de données est une fois de plus une excellente lecture qui nous permet de rester au courant de l'actualité en matière de cybersécurité, notamment des tendances actuelles en matière de cybercriminalité et des facteurs d'incidents, des analyses et des informations qui peuvent aider les entreprises à faire évoluer leur programme de sécurité. Cette année, les enquêteurs de Verizon ont analysé plus de 53 000 incidents et quelque 2 200 violations. Ils ont tiré de nombreux enseignements tangibles sur ce qu'il faut surveiller et ne pas faire, ainsi que de précieuses recommandations sur les domaines sur lesquels concentrer les efforts de sécurité. Le rapport de 2018 semble avoir évolué avec le temps, être pertinent pour un public plus large d'entreprises à mesure que les impacts sur la sécurité s'étendent, et être de plus en plus reconnu comme un problème commercial courant.
Parmi les nombreuses conclusions intéressantes, le rapport de 2018 confirme que la plupart des piratages se produisent toujours par le biais de violations d'applications Web (il existe même un graphique interactif sympa qui le montre).
Les attaques d'applications Web consistent en tout incident au cours duquel une application Web a été le vecteur de l'attaque. Cela inclut l'exploitation des vulnérabilités au niveau du code de l'application ainsi que le blocage des mécanismes d'authentification. Il convient de noter que le nombre de violations de ce type est réduit en raison du filtrage des attaques liées aux botnets sur les applications Web à l'aide d'informations d'identification volées sur les appareils appartenant aux clients. L'utilisation d'informations d'identification volées reste la principale forme de piratage lors de violations impliquant des applications Web, suivie par SQLi (plus d'informations sur SQL plus tard...).
L'un des thèmes qui ressort du rapport de cette année est l'importance du « facteur humain » dans l'équation de la sécurité, à la fois en tant que partie intégrante du problème et de la solution. Le rapport traite à la fois des acteurs externes et internes, indiquant que les erreurs étaient à l'origine de près d'une violation sur cinq (17 %). Des violations se sont produites lorsque des employés n'ont pas réussi à détruire des informations confidentielles, lorsqu'ils ont envoyé un e-mail à la mauvaise personne et lorsque les serveurs Web étaient mal configurés. Le rapport souligne que même si aucune de ces mesures n'était délibérément mal intentionnée, elles pourraient toutes s'avérer coûteuses.
Mais il existe un facteur humain souvent oublié qui est à l'origine de nombreuses failles de sécurité, à savoir la fréquence élevée à laquelle les développeurs créent du code contenant des failles de sécurité, ce qui entraîne des vulnérabilités des applications Web, qui à leur tour entraînent ces incidents et ces violations.
Les tests d'applications réalisés au cours des 5 dernières années n'ont pas montré d'amélioration significative du nombre de vulnérabilités détectées et les mêmes failles réapparaissent à maintes reprises. Un rapport Veracode de 2017 basé sur 400 000 scans d'applications montre que les applications ont respecté la politique des 10 meilleures applications de l'OWASP dans 30 % des cas seulement. Étonnamment, les injections SQL sont apparues dans près d'une application récemment scannée sur trois au cours des 5 dernières années, y compris l'année dernière. Je dis « étonnant », car les injections SQL existent depuis 1999. Le fait que les mêmes failles, y compris les injections SQL, soient constamment découvertes prouve que ce problème de « facteur humain » chez les développeurs n'est pas traité de manière adéquate.
C'est à ce stade que je dois me lever et dire que je suis du côté des développeurs dans cet argument. Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
C'est ce que nous faisons chez Secure Code Warrior et nous constatons que les entreprises qui intègrent une formation pratique au code sécurisé dans la vie quotidienne de leurs développeurs réduisent le nombre de vulnérabilités créées dans les applications Web. Pour pouvoir écrire du code sécurisé, les développeurs ont besoin d'un accès régulier à des formations pratiques qui les incitent activement à développer leurs compétences en matière de codage sécurisé. Ils doivent se renseigner sur les vulnérabilités récemment identifiées, en code réel, et plus particulièrement dans leurs propres langages/frameworks. Cette expérience d'apprentissage devrait les aider à comprendre comment localiser, identifier et corriger les vulnérabilités connues. Les développeurs ont également besoin d'un ensemble d'outils de qualité dans leur processus qui facilite la sécurité, ne les ralentit pas et les oriente en temps réel sur les bons et les mauvais modèles de codage.
C'est ainsi que nous pouvons faire une différence tangible et positive en ce qui concerne le nombre de violations des applications Web.
Je suis totalement d'accord avec Verizon pour dire qu'il est nécessaire de renforcer la formation en matière de sensibilisation à la sécurité à l'échelle de l'entreprise. Mon message à ce sujet aux DSI et aux RSSI est « n'oubliez pas vos développeurs ! ». Ces architectes de vos entreprises modernes peuvent être un « facteur humain » important qui génère régulièrement des points d'accès pour les pirates informatiques, ou ils peuvent être votre première ligne de défense, vos héros de sécurité.
Une mise à niveau efficace des compétences en matière de sécurité pour les développeurs pourrait faire une réelle différence dans les résultats rapportés par Verizon dans ses prochains rapports. Il serait intéressant de voir que le rapport 2019 présente la formation des développeurs en matière de sécurité comme une stratégie clé de réduction des risques que les entreprises peuvent adopter. Je suis optimiste, mais je parie que si les entreprises apprenaient à leurs développeurs comment éviter de créer des failles d'injection, le nombre de vulnérabilités des applications Web mentionnées dans ce rapport diminuerait de manière significative.
Jetez un œil à notre plateforme en action pour découvrir comment les développeurs peuvent améliorer leurs compétences rapidement dans un environnement de formation idéal et ludique :
Jouez à un défi de codage sécurisé
Consultez nos ressources d'apprentissage gratuites
Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
Le rapport 2018 de Verizon sur les enquêtes sur les violations de données est une fois de plus une excellente lecture qui nous permet de rester au courant de l'actualité en matière de cybersécurité, notamment des tendances actuelles en matière de cybercriminalité et des facteurs d'incidents, des analyses et des informations qui peuvent aider les entreprises à faire évoluer leur programme de sécurité. Cette année, les enquêteurs de Verizon ont analysé plus de 53 000 incidents et quelque 2 200 violations. Ils ont tiré de nombreux enseignements tangibles sur ce qu'il faut surveiller et ne pas faire, ainsi que de précieuses recommandations sur les domaines sur lesquels concentrer les efforts de sécurité. Le rapport de 2018 semble avoir évolué avec le temps, être pertinent pour un public plus large d'entreprises à mesure que les impacts sur la sécurité s'étendent, et être de plus en plus reconnu comme un problème commercial courant.
Parmi les nombreuses conclusions intéressantes, le rapport de 2018 confirme que la plupart des piratages se produisent toujours par le biais de violations d'applications Web (il existe même un graphique interactif sympa qui le montre).
Les attaques d'applications Web consistent en tout incident au cours duquel une application Web a été le vecteur de l'attaque. Cela inclut l'exploitation des vulnérabilités au niveau du code de l'application ainsi que le blocage des mécanismes d'authentification. Il convient de noter que le nombre de violations de ce type est réduit en raison du filtrage des attaques liées aux botnets sur les applications Web à l'aide d'informations d'identification volées sur les appareils appartenant aux clients. L'utilisation d'informations d'identification volées reste la principale forme de piratage lors de violations impliquant des applications Web, suivie par SQLi (plus d'informations sur SQL plus tard...).
L'un des thèmes qui ressort du rapport de cette année est l'importance du « facteur humain » dans l'équation de la sécurité, à la fois en tant que partie intégrante du problème et de la solution. Le rapport traite à la fois des acteurs externes et internes, indiquant que les erreurs étaient à l'origine de près d'une violation sur cinq (17 %). Des violations se sont produites lorsque des employés n'ont pas réussi à détruire des informations confidentielles, lorsqu'ils ont envoyé un e-mail à la mauvaise personne et lorsque les serveurs Web étaient mal configurés. Le rapport souligne que même si aucune de ces mesures n'était délibérément mal intentionnée, elles pourraient toutes s'avérer coûteuses.
Mais il existe un facteur humain souvent oublié qui est à l'origine de nombreuses failles de sécurité, à savoir la fréquence élevée à laquelle les développeurs créent du code contenant des failles de sécurité, ce qui entraîne des vulnérabilités des applications Web, qui à leur tour entraînent ces incidents et ces violations.
Les tests d'applications réalisés au cours des 5 dernières années n'ont pas montré d'amélioration significative du nombre de vulnérabilités détectées et les mêmes failles réapparaissent à maintes reprises. Un rapport Veracode de 2017 basé sur 400 000 scans d'applications montre que les applications ont respecté la politique des 10 meilleures applications de l'OWASP dans 30 % des cas seulement. Étonnamment, les injections SQL sont apparues dans près d'une application récemment scannée sur trois au cours des 5 dernières années, y compris l'année dernière. Je dis « étonnant », car les injections SQL existent depuis 1999. Le fait que les mêmes failles, y compris les injections SQL, soient constamment découvertes prouve que ce problème de « facteur humain » chez les développeurs n'est pas traité de manière adéquate.
C'est à ce stade que je dois me lever et dire que je suis du côté des développeurs dans cet argument. Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
C'est ce que nous faisons chez Secure Code Warrior et nous constatons que les entreprises qui intègrent une formation pratique au code sécurisé dans la vie quotidienne de leurs développeurs réduisent le nombre de vulnérabilités créées dans les applications Web. Pour pouvoir écrire du code sécurisé, les développeurs ont besoin d'un accès régulier à des formations pratiques qui les incitent activement à développer leurs compétences en matière de codage sécurisé. Ils doivent se renseigner sur les vulnérabilités récemment identifiées, en code réel, et plus particulièrement dans leurs propres langages/frameworks. Cette expérience d'apprentissage devrait les aider à comprendre comment localiser, identifier et corriger les vulnérabilités connues. Les développeurs ont également besoin d'un ensemble d'outils de qualité dans leur processus qui facilite la sécurité, ne les ralentit pas et les oriente en temps réel sur les bons et les mauvais modèles de codage.
C'est ainsi que nous pouvons faire une différence tangible et positive en ce qui concerne le nombre de violations des applications Web.
Je suis totalement d'accord avec Verizon pour dire qu'il est nécessaire de renforcer la formation en matière de sensibilisation à la sécurité à l'échelle de l'entreprise. Mon message à ce sujet aux DSI et aux RSSI est « n'oubliez pas vos développeurs ! ». Ces architectes de vos entreprises modernes peuvent être un « facteur humain » important qui génère régulièrement des points d'accès pour les pirates informatiques, ou ils peuvent être votre première ligne de défense, vos héros de sécurité.
Une mise à niveau efficace des compétences en matière de sécurité pour les développeurs pourrait faire une réelle différence dans les résultats rapportés par Verizon dans ses prochains rapports. Il serait intéressant de voir que le rapport 2019 présente la formation des développeurs en matière de sécurité comme une stratégie clé de réduction des risques que les entreprises peuvent adopter. Je suis optimiste, mais je parie que si les entreprises apprenaient à leurs développeurs comment éviter de créer des failles d'injection, le nombre de vulnérabilités des applications Web mentionnées dans ce rapport diminuerait de manière significative.
Jetez un œil à notre plateforme en action pour découvrir comment les développeurs peuvent améliorer leurs compétences rapidement dans un environnement de formation idéal et ludique :
Jouez à un défi de codage sécurisé
Consultez nos ressources d'apprentissage gratuites
Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
点击下方链接，下载此资源的PDF文件。
Secure Code Warrior 在整个软件开发周期中保障代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管，还是其他任何参与安全工作的人员，我们都能协助您的组织降低不安全代码带来的风险。
显示报告预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
Le rapport 2018 de Verizon sur les enquêtes sur les violations de données est une fois de plus une excellente lecture qui nous permet de rester au courant de l'actualité en matière de cybersécurité, notamment des tendances actuelles en matière de cybercriminalité et des facteurs d'incidents, des analyses et des informations qui peuvent aider les entreprises à faire évoluer leur programme de sécurité. Cette année, les enquêteurs de Verizon ont analysé plus de 53 000 incidents et quelque 2 200 violations. Ils ont tiré de nombreux enseignements tangibles sur ce qu'il faut surveiller et ne pas faire, ainsi que de précieuses recommandations sur les domaines sur lesquels concentrer les efforts de sécurité. Le rapport de 2018 semble avoir évolué avec le temps, être pertinent pour un public plus large d'entreprises à mesure que les impacts sur la sécurité s'étendent, et être de plus en plus reconnu comme un problème commercial courant.
Parmi les nombreuses conclusions intéressantes, le rapport de 2018 confirme que la plupart des piratages se produisent toujours par le biais de violations d'applications Web (il existe même un graphique interactif sympa qui le montre).
Les attaques d'applications Web consistent en tout incident au cours duquel une application Web a été le vecteur de l'attaque. Cela inclut l'exploitation des vulnérabilités au niveau du code de l'application ainsi que le blocage des mécanismes d'authentification. Il convient de noter que le nombre de violations de ce type est réduit en raison du filtrage des attaques liées aux botnets sur les applications Web à l'aide d'informations d'identification volées sur les appareils appartenant aux clients. L'utilisation d'informations d'identification volées reste la principale forme de piratage lors de violations impliquant des applications Web, suivie par SQLi (plus d'informations sur SQL plus tard...).
L'un des thèmes qui ressort du rapport de cette année est l'importance du « facteur humain » dans l'équation de la sécurité, à la fois en tant que partie intégrante du problème et de la solution. Le rapport traite à la fois des acteurs externes et internes, indiquant que les erreurs étaient à l'origine de près d'une violation sur cinq (17 %). Des violations se sont produites lorsque des employés n'ont pas réussi à détruire des informations confidentielles, lorsqu'ils ont envoyé un e-mail à la mauvaise personne et lorsque les serveurs Web étaient mal configurés. Le rapport souligne que même si aucune de ces mesures n'était délibérément mal intentionnée, elles pourraient toutes s'avérer coûteuses.
Mais il existe un facteur humain souvent oublié qui est à l'origine de nombreuses failles de sécurité, à savoir la fréquence élevée à laquelle les développeurs créent du code contenant des failles de sécurité, ce qui entraîne des vulnérabilités des applications Web, qui à leur tour entraînent ces incidents et ces violations.
Les tests d'applications réalisés au cours des 5 dernières années n'ont pas montré d'amélioration significative du nombre de vulnérabilités détectées et les mêmes failles réapparaissent à maintes reprises. Un rapport Veracode de 2017 basé sur 400 000 scans d'applications montre que les applications ont respecté la politique des 10 meilleures applications de l'OWASP dans 30 % des cas seulement. Étonnamment, les injections SQL sont apparues dans près d'une application récemment scannée sur trois au cours des 5 dernières années, y compris l'année dernière. Je dis « étonnant », car les injections SQL existent depuis 1999. Le fait que les mêmes failles, y compris les injections SQL, soient constamment découvertes prouve que ce problème de « facteur humain » chez les développeurs n'est pas traité de manière adéquate.
C'est à ce stade que je dois me lever et dire que je suis du côté des développeurs dans cet argument. Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
C'est ce que nous faisons chez Secure Code Warrior et nous constatons que les entreprises qui intègrent une formation pratique au code sécurisé dans la vie quotidienne de leurs développeurs réduisent le nombre de vulnérabilités créées dans les applications Web. Pour pouvoir écrire du code sécurisé, les développeurs ont besoin d'un accès régulier à des formations pratiques qui les incitent activement à développer leurs compétences en matière de codage sécurisé. Ils doivent se renseigner sur les vulnérabilités récemment identifiées, en code réel, et plus particulièrement dans leurs propres langages/frameworks. Cette expérience d'apprentissage devrait les aider à comprendre comment localiser, identifier et corriger les vulnérabilités connues. Les développeurs ont également besoin d'un ensemble d'outils de qualité dans leur processus qui facilite la sécurité, ne les ralentit pas et les oriente en temps réel sur les bons et les mauvais modèles de codage.
C'est ainsi que nous pouvons faire une différence tangible et positive en ce qui concerne le nombre de violations des applications Web.
Je suis totalement d'accord avec Verizon pour dire qu'il est nécessaire de renforcer la formation en matière de sensibilisation à la sécurité à l'échelle de l'entreprise. Mon message à ce sujet aux DSI et aux RSSI est « n'oubliez pas vos développeurs ! ». Ces architectes de vos entreprises modernes peuvent être un « facteur humain » important qui génère régulièrement des points d'accès pour les pirates informatiques, ou ils peuvent être votre première ligne de défense, vos héros de sécurité.
Une mise à niveau efficace des compétences en matière de sécurité pour les développeurs pourrait faire une réelle différence dans les résultats rapportés par Verizon dans ses prochains rapports. Il serait intéressant de voir que le rapport 2019 présente la formation des développeurs en matière de sécurité comme une stratégie clé de réduction des risques que les entreprises peuvent adopter. Je suis optimiste, mais je parie que si les entreprises apprenaient à leurs développeurs comment éviter de créer des failles d'injection, le nombre de vulnérabilités des applications Web mentionnées dans ce rapport diminuerait de manière significative.
Jetez un œil à notre plateforme en action pour découvrir comment les développeurs peuvent améliorer leurs compétences rapidement dans un environnement de formation idéal et ludique :
Jouez à un défi de codage sécurisé
Consultez nos ressources d'apprentissage gratuites
Comment les développeurs sont-ils censés écrire du code sécurisé si personne ne leur explique pourquoi c'est important, quelles sont les conséquences d'un code non sécurisé et, surtout, comment éviter d'écrire ces vulnérabilités dans leurs frameworks de programmation respectifs ?
%20(1).avif)
.avif)
