Inciter les développeurs est la clé de meilleures pratiques de sécurité
Le paysage des cybermenaces devient de plus en plus complexe de jour en jour. Les attaquants analysent en permanence les réseaux à la recherche d'applications, de programmes et d'instances cloud vulnérables, et la dernière nouveauté du mois concerne les API, largement considérées comme une solution facile grâce à leurs contrôles de sécurité souvent laxistes. Elles sont si persistantes que les nouvelles applications peuvent parfois être compromises et exploitées quelques heures après leur déploiement. Le rapport Verizon 2021 sur les enquêtes sur les violations de données montre clairement que les menaces proférées contre les entreprises et les organisations sont plus dangereux aujourd'hui plus qu'à n'importe quel autre moment de l'histoire.
Il devient de plus en plus évident que la seule façon de réellement renforcer le logiciel en cours de création est de s'assurer qu'il repose sur un code sécurisé. En d'autres termes, le meilleur moyen de mettre fin à l'invasion des acteurs malveillants est de les empêcher d'accéder à vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont biaisés en faveur des attaquants.
Cette situation a d'abord donné lieu à développement agile et DevOps, puis à l'ensemble Mouvement DevSecOps, où la sécurité est une responsabilité partagée pour toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais les développeurs constituent la base de cette pyramide, et sans doute la partie la plus importante. Alors que la plupart des développeurs souhaitent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'exige un changement de priorités aussi important.
Défaite intentionnellement
Pendant de nombreuses années, les développeurs ont été informés que leur rôle principal au sein de leur organisation était de créer et de déployer rapidement des applications dans un environnement dynamique, où les activités ne s'arrêtent jamais et les clients ne dorment jamais. Plus les développeurs pouvaient coder rapidement et déployer de fonctionnalités, plus ils étaient considérés comme utiles en termes d'évaluation des performances.
La sécurité n'était qu'une question secondaire, si tant est qu'elle soit prise en compte. Au lieu de cela, c'était aux équipes de sécurité des applications (AppSec) de s'occuper de tout cela. Les équipes AppSec n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent des applications complètes au stade du développement pour appliquer des correctifs de sécurité ou pour réécrire du code afin de corriger des vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà « terminée » équivalait à une heure où il ne créait pas de nouvelles applications et fonctionnalités, diminuant ainsi ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
L'environnement de menaces a ensuite modifié l'importance et la priorisation de la sécurité pour la plupart des entreprises. Selon le récent Coût d'un rapport de violation de données selon IBM et le Ponemon Institute, une faille de cybersécurité coûte aujourd'hui en moyenne 3,8 millions de dollars par incident, bien que ce ne soit guère la limite supérieure. À elle seule, une entreprise a subi des pertes de 1,3 milliard de dollars à la suite d'une faille sur son réseau. Les entreprises d'aujourd'hui souhaitent bénéficier de la sécurité offerte par DevSecOps, mais elles tardent malheureusement à récompenser les développeurs qui répondent à cet appel.
Le simple fait de demander aux équipes de développement de prendre en compte la sécurité ne fonctionnera pas, surtout si elles sont toujours encouragées uniquement sur la base de la rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de se renseigner sur la sécurité et de sécuriser leur code pourraient perdre les meilleures évaluations de performances et les bonus lucratifs que leurs collègues moins soucieux de la sécurité continuent de gagner. C'est presque comme si les entreprises truquaient involontairement le système pour corriger leurs propres failles de sécurité, et cela revient à leur perception de l'équipe de développement. S'ils ne les considèrent pas comme les premières lignes de la sécurité, il est très peu probable qu'un plan viable visant à utiliser leur main-d'œuvre se concrétise.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des décennies d'expérience dans le codage, mais très peu en matière de sécurité... Après tout, cela n'a jamais été exigé d'eux. À moins qu'une entreprise ne propose un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ses développeurs acquièrent soudainement de nouvelles compétences et les mettent en œuvre de manière significative afin de réduire activement les vulnérabilités.
Récompenser les développeurs pour leurs bonnes pratiques en matière de sécurité
La bonne nouvelle, c'est que l'écrasante majorité des développeurs font leur travail parce qu'ils le trouvent à la fois stimulant et gratifiant, et parce qu'ils jouissent du respect que leur poste implique. Michael Shpilt, codeur professionnel de longue date a récemment écrit à propos de toutes les choses qui le motivent, lui et ses collègues programmeurs, dans leur travail de développement. Oui, il cite la compensation monétaire parmi ces incitations, mais elle se situe étonnamment loin dans la liste. Il privilégie plutôt le plaisir de créer quelque chose de nouveau, d'acquérir de nouvelles compétences et la satisfaction de savoir que son travail sera directement utilisé pour aider les autres. Il parle également de son désir de se sentir valorisé au sein de son entreprise et de sa communauté. Bref, les développeurs sont comme beaucoup de bonnes personnes qui sont fières de leur travail.
Les développeurs tels que Shpilt et d'autres ne veulent pas que des acteurs malveillants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs mêmes qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement réorienter leurs priorités vers la sécurité sans soutien. Sinon, c'est presque comme si le système allait jouer contre eux.
Pour aider les équipes de développement à améliorer leurs prouesses en matière de cybersécurité, il faut d'abord leur enseigner les compétences nécessaires. L'utilisation d'un apprentissage échafaudé et d'outils tels que la formation Just-in-Time (JiT) peut rendre ce processus beaucoup moins pénible et aider à tirer parti des connaissances existantes dans le bon contexte.
Le principe de JiT est que les développeurs reçoivent les bonnes connaissances au bon moment. Par exemple, si un outil de formation pour développeurs JiT détecte qu'un programmeur crée un morceau de code non sécurisé ou introduit accidentellement une vulnérabilité dans son application, il peut s'activer et montrer au développeur comment il pourrait résoudre ce problème et comment écrire un code plus sécurisé pour remplir cette même fonction à l'avenir.
L'engagement en faveur de l'amélioration des compétences étant en place, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Les codeurs devraient plutôt être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs développeurs devenant champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. Et ces champions doivent être récompensés à la fois par le prestige de l'entreprise et par une compensation financière. Il est également important de se rappeler que les développeurs n'ont généralement pas une expérience positive de la sécurité, et les encourager grâce à un apprentissage positif et amusant et à des incitations adaptées à leurs intérêts contribuera grandement à garantir à la fois la rétention des connaissances et le désir de continuer à développer leurs compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation des développeurs, mais en s'attendant à ce que le développement d'applications sécurisées prenne un peu plus de temps, d'autant plus que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être la défense ultime contre les forces obscures d'un paysage de menaces de plus en plus dangereux. N'oubliez pas que les champions de ce nouveau monde, les développeurs qui créent constamment du nouveau code, doivent être respectés et rémunérés pour leur travail.
Vous voulez tester vos compétences en matière de sécurité par rapport à d'autres développeurs du monde entier ? Consultez Secure Code Warriors Jeux olympiques de 2021, et tu pourrais remporter un prix important lors de nos tournois mondiaux !
Les développeurs professionnels souhaitent adopter DevSecOps et écrire du code sécurisé, mais leurs organisations doivent soutenir ce changement radical si elles veulent que cet effort se développe.
Chief Executive Officer, Chairman, and Co-Founder
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
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
Le paysage des cybermenaces devient de plus en plus complexe de jour en jour. Les attaquants analysent en permanence les réseaux à la recherche d'applications, de programmes et d'instances cloud vulnérables, et la dernière nouveauté du mois concerne les API, largement considérées comme une solution facile grâce à leurs contrôles de sécurité souvent laxistes. Elles sont si persistantes que les nouvelles applications peuvent parfois être compromises et exploitées quelques heures après leur déploiement. Le rapport Verizon 2021 sur les enquêtes sur les violations de données montre clairement que les menaces proférées contre les entreprises et les organisations sont plus dangereux aujourd'hui plus qu'à n'importe quel autre moment de l'histoire.
Il devient de plus en plus évident que la seule façon de réellement renforcer le logiciel en cours de création est de s'assurer qu'il repose sur un code sécurisé. En d'autres termes, le meilleur moyen de mettre fin à l'invasion des acteurs malveillants est de les empêcher d'accéder à vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont biaisés en faveur des attaquants.
Cette situation a d'abord donné lieu à développement agile et DevOps, puis à l'ensemble Mouvement DevSecOps, où la sécurité est une responsabilité partagée pour toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais les développeurs constituent la base de cette pyramide, et sans doute la partie la plus importante. Alors que la plupart des développeurs souhaitent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'exige un changement de priorités aussi important.
Défaite intentionnellement
Pendant de nombreuses années, les développeurs ont été informés que leur rôle principal au sein de leur organisation était de créer et de déployer rapidement des applications dans un environnement dynamique, où les activités ne s'arrêtent jamais et les clients ne dorment jamais. Plus les développeurs pouvaient coder rapidement et déployer de fonctionnalités, plus ils étaient considérés comme utiles en termes d'évaluation des performances.
La sécurité n'était qu'une question secondaire, si tant est qu'elle soit prise en compte. Au lieu de cela, c'était aux équipes de sécurité des applications (AppSec) de s'occuper de tout cela. Les équipes AppSec n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent des applications complètes au stade du développement pour appliquer des correctifs de sécurité ou pour réécrire du code afin de corriger des vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà « terminée » équivalait à une heure où il ne créait pas de nouvelles applications et fonctionnalités, diminuant ainsi ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
L'environnement de menaces a ensuite modifié l'importance et la priorisation de la sécurité pour la plupart des entreprises. Selon le récent Coût d'un rapport de violation de données selon IBM et le Ponemon Institute, une faille de cybersécurité coûte aujourd'hui en moyenne 3,8 millions de dollars par incident, bien que ce ne soit guère la limite supérieure. À elle seule, une entreprise a subi des pertes de 1,3 milliard de dollars à la suite d'une faille sur son réseau. Les entreprises d'aujourd'hui souhaitent bénéficier de la sécurité offerte par DevSecOps, mais elles tardent malheureusement à récompenser les développeurs qui répondent à cet appel.
Le simple fait de demander aux équipes de développement de prendre en compte la sécurité ne fonctionnera pas, surtout si elles sont toujours encouragées uniquement sur la base de la rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de se renseigner sur la sécurité et de sécuriser leur code pourraient perdre les meilleures évaluations de performances et les bonus lucratifs que leurs collègues moins soucieux de la sécurité continuent de gagner. C'est presque comme si les entreprises truquaient involontairement le système pour corriger leurs propres failles de sécurité, et cela revient à leur perception de l'équipe de développement. S'ils ne les considèrent pas comme les premières lignes de la sécurité, il est très peu probable qu'un plan viable visant à utiliser leur main-d'œuvre se concrétise.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des décennies d'expérience dans le codage, mais très peu en matière de sécurité... Après tout, cela n'a jamais été exigé d'eux. À moins qu'une entreprise ne propose un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ses développeurs acquièrent soudainement de nouvelles compétences et les mettent en œuvre de manière significative afin de réduire activement les vulnérabilités.
Récompenser les développeurs pour leurs bonnes pratiques en matière de sécurité
La bonne nouvelle, c'est que l'écrasante majorité des développeurs font leur travail parce qu'ils le trouvent à la fois stimulant et gratifiant, et parce qu'ils jouissent du respect que leur poste implique. Michael Shpilt, codeur professionnel de longue date a récemment écrit à propos de toutes les choses qui le motivent, lui et ses collègues programmeurs, dans leur travail de développement. Oui, il cite la compensation monétaire parmi ces incitations, mais elle se situe étonnamment loin dans la liste. Il privilégie plutôt le plaisir de créer quelque chose de nouveau, d'acquérir de nouvelles compétences et la satisfaction de savoir que son travail sera directement utilisé pour aider les autres. Il parle également de son désir de se sentir valorisé au sein de son entreprise et de sa communauté. Bref, les développeurs sont comme beaucoup de bonnes personnes qui sont fières de leur travail.
Les développeurs tels que Shpilt et d'autres ne veulent pas que des acteurs malveillants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs mêmes qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement réorienter leurs priorités vers la sécurité sans soutien. Sinon, c'est presque comme si le système allait jouer contre eux.
Pour aider les équipes de développement à améliorer leurs prouesses en matière de cybersécurité, il faut d'abord leur enseigner les compétences nécessaires. L'utilisation d'un apprentissage échafaudé et d'outils tels que la formation Just-in-Time (JiT) peut rendre ce processus beaucoup moins pénible et aider à tirer parti des connaissances existantes dans le bon contexte.
Le principe de JiT est que les développeurs reçoivent les bonnes connaissances au bon moment. Par exemple, si un outil de formation pour développeurs JiT détecte qu'un programmeur crée un morceau de code non sécurisé ou introduit accidentellement une vulnérabilité dans son application, il peut s'activer et montrer au développeur comment il pourrait résoudre ce problème et comment écrire un code plus sécurisé pour remplir cette même fonction à l'avenir.
L'engagement en faveur de l'amélioration des compétences étant en place, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Les codeurs devraient plutôt être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs développeurs devenant champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. Et ces champions doivent être récompensés à la fois par le prestige de l'entreprise et par une compensation financière. Il est également important de se rappeler que les développeurs n'ont généralement pas une expérience positive de la sécurité, et les encourager grâce à un apprentissage positif et amusant et à des incitations adaptées à leurs intérêts contribuera grandement à garantir à la fois la rétention des connaissances et le désir de continuer à développer leurs compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation des développeurs, mais en s'attendant à ce que le développement d'applications sécurisées prenne un peu plus de temps, d'autant plus que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être la défense ultime contre les forces obscures d'un paysage de menaces de plus en plus dangereux. N'oubliez pas que les champions de ce nouveau monde, les développeurs qui créent constamment du nouveau code, doivent être respectés et rémunérés pour leur travail.
Vous voulez tester vos compétences en matière de sécurité par rapport à d'autres développeurs du monde entier ? Consultez Secure Code Warriors Jeux olympiques de 2021, et tu pourrais remporter un prix important lors de nos tournois mondiaux !
Le paysage des cybermenaces devient de plus en plus complexe de jour en jour. Les attaquants analysent en permanence les réseaux à la recherche d'applications, de programmes et d'instances cloud vulnérables, et la dernière nouveauté du mois concerne les API, largement considérées comme une solution facile grâce à leurs contrôles de sécurité souvent laxistes. Elles sont si persistantes que les nouvelles applications peuvent parfois être compromises et exploitées quelques heures après leur déploiement. Le rapport Verizon 2021 sur les enquêtes sur les violations de données montre clairement que les menaces proférées contre les entreprises et les organisations sont plus dangereux aujourd'hui plus qu'à n'importe quel autre moment de l'histoire.
Il devient de plus en plus évident que la seule façon de réellement renforcer le logiciel en cours de création est de s'assurer qu'il repose sur un code sécurisé. En d'autres termes, le meilleur moyen de mettre fin à l'invasion des acteurs malveillants est de les empêcher d'accéder à vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont biaisés en faveur des attaquants.
Cette situation a d'abord donné lieu à développement agile et DevOps, puis à l'ensemble Mouvement DevSecOps, où la sécurité est une responsabilité partagée pour toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais les développeurs constituent la base de cette pyramide, et sans doute la partie la plus importante. Alors que la plupart des développeurs souhaitent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'exige un changement de priorités aussi important.
Défaite intentionnellement
Pendant de nombreuses années, les développeurs ont été informés que leur rôle principal au sein de leur organisation était de créer et de déployer rapidement des applications dans un environnement dynamique, où les activités ne s'arrêtent jamais et les clients ne dorment jamais. Plus les développeurs pouvaient coder rapidement et déployer de fonctionnalités, plus ils étaient considérés comme utiles en termes d'évaluation des performances.
La sécurité n'était qu'une question secondaire, si tant est qu'elle soit prise en compte. Au lieu de cela, c'était aux équipes de sécurité des applications (AppSec) de s'occuper de tout cela. Les équipes AppSec n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent des applications complètes au stade du développement pour appliquer des correctifs de sécurité ou pour réécrire du code afin de corriger des vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà « terminée » équivalait à une heure où il ne créait pas de nouvelles applications et fonctionnalités, diminuant ainsi ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
L'environnement de menaces a ensuite modifié l'importance et la priorisation de la sécurité pour la plupart des entreprises. Selon le récent Coût d'un rapport de violation de données selon IBM et le Ponemon Institute, une faille de cybersécurité coûte aujourd'hui en moyenne 3,8 millions de dollars par incident, bien que ce ne soit guère la limite supérieure. À elle seule, une entreprise a subi des pertes de 1,3 milliard de dollars à la suite d'une faille sur son réseau. Les entreprises d'aujourd'hui souhaitent bénéficier de la sécurité offerte par DevSecOps, mais elles tardent malheureusement à récompenser les développeurs qui répondent à cet appel.
Le simple fait de demander aux équipes de développement de prendre en compte la sécurité ne fonctionnera pas, surtout si elles sont toujours encouragées uniquement sur la base de la rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de se renseigner sur la sécurité et de sécuriser leur code pourraient perdre les meilleures évaluations de performances et les bonus lucratifs que leurs collègues moins soucieux de la sécurité continuent de gagner. C'est presque comme si les entreprises truquaient involontairement le système pour corriger leurs propres failles de sécurité, et cela revient à leur perception de l'équipe de développement. S'ils ne les considèrent pas comme les premières lignes de la sécurité, il est très peu probable qu'un plan viable visant à utiliser leur main-d'œuvre se concrétise.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des décennies d'expérience dans le codage, mais très peu en matière de sécurité... Après tout, cela n'a jamais été exigé d'eux. À moins qu'une entreprise ne propose un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ses développeurs acquièrent soudainement de nouvelles compétences et les mettent en œuvre de manière significative afin de réduire activement les vulnérabilités.
Récompenser les développeurs pour leurs bonnes pratiques en matière de sécurité
La bonne nouvelle, c'est que l'écrasante majorité des développeurs font leur travail parce qu'ils le trouvent à la fois stimulant et gratifiant, et parce qu'ils jouissent du respect que leur poste implique. Michael Shpilt, codeur professionnel de longue date a récemment écrit à propos de toutes les choses qui le motivent, lui et ses collègues programmeurs, dans leur travail de développement. Oui, il cite la compensation monétaire parmi ces incitations, mais elle se situe étonnamment loin dans la liste. Il privilégie plutôt le plaisir de créer quelque chose de nouveau, d'acquérir de nouvelles compétences et la satisfaction de savoir que son travail sera directement utilisé pour aider les autres. Il parle également de son désir de se sentir valorisé au sein de son entreprise et de sa communauté. Bref, les développeurs sont comme beaucoup de bonnes personnes qui sont fières de leur travail.
Les développeurs tels que Shpilt et d'autres ne veulent pas que des acteurs malveillants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs mêmes qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement réorienter leurs priorités vers la sécurité sans soutien. Sinon, c'est presque comme si le système allait jouer contre eux.
Pour aider les équipes de développement à améliorer leurs prouesses en matière de cybersécurité, il faut d'abord leur enseigner les compétences nécessaires. L'utilisation d'un apprentissage échafaudé et d'outils tels que la formation Just-in-Time (JiT) peut rendre ce processus beaucoup moins pénible et aider à tirer parti des connaissances existantes dans le bon contexte.
Le principe de JiT est que les développeurs reçoivent les bonnes connaissances au bon moment. Par exemple, si un outil de formation pour développeurs JiT détecte qu'un programmeur crée un morceau de code non sécurisé ou introduit accidentellement une vulnérabilité dans son application, il peut s'activer et montrer au développeur comment il pourrait résoudre ce problème et comment écrire un code plus sécurisé pour remplir cette même fonction à l'avenir.
L'engagement en faveur de l'amélioration des compétences étant en place, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Les codeurs devraient plutôt être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs développeurs devenant champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. Et ces champions doivent être récompensés à la fois par le prestige de l'entreprise et par une compensation financière. Il est également important de se rappeler que les développeurs n'ont généralement pas une expérience positive de la sécurité, et les encourager grâce à un apprentissage positif et amusant et à des incitations adaptées à leurs intérêts contribuera grandement à garantir à la fois la rétention des connaissances et le désir de continuer à développer leurs compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation des développeurs, mais en s'attendant à ce que le développement d'applications sécurisées prenne un peu plus de temps, d'autant plus que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être la défense ultime contre les forces obscures d'un paysage de menaces de plus en plus dangereux. N'oubliez pas que les champions de ce nouveau monde, les développeurs qui créent constamment du nouveau code, doivent être respectés et rémunérés pour leur travail.
Vous voulez tester vos compétences en matière de sécurité par rapport à d'autres développeurs du monde entier ? Consultez Secure Code Warriors Jeux olympiques de 2021, et tu pourrais remporter un prix important lors de nos tournois mondiaux !
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
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
Le paysage des cybermenaces devient de plus en plus complexe de jour en jour. Les attaquants analysent en permanence les réseaux à la recherche d'applications, de programmes et d'instances cloud vulnérables, et la dernière nouveauté du mois concerne les API, largement considérées comme une solution facile grâce à leurs contrôles de sécurité souvent laxistes. Elles sont si persistantes que les nouvelles applications peuvent parfois être compromises et exploitées quelques heures après leur déploiement. Le rapport Verizon 2021 sur les enquêtes sur les violations de données montre clairement que les menaces proférées contre les entreprises et les organisations sont plus dangereux aujourd'hui plus qu'à n'importe quel autre moment de l'histoire.
Il devient de plus en plus évident que la seule façon de réellement renforcer le logiciel en cours de création est de s'assurer qu'il repose sur un code sécurisé. En d'autres termes, le meilleur moyen de mettre fin à l'invasion des acteurs malveillants est de les empêcher d'accéder à vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont biaisés en faveur des attaquants.
Cette situation a d'abord donné lieu à développement agile et DevOps, puis à l'ensemble Mouvement DevSecOps, où la sécurité est une responsabilité partagée pour toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais les développeurs constituent la base de cette pyramide, et sans doute la partie la plus importante. Alors que la plupart des développeurs souhaitent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'exige un changement de priorités aussi important.
Défaite intentionnellement
Pendant de nombreuses années, les développeurs ont été informés que leur rôle principal au sein de leur organisation était de créer et de déployer rapidement des applications dans un environnement dynamique, où les activités ne s'arrêtent jamais et les clients ne dorment jamais. Plus les développeurs pouvaient coder rapidement et déployer de fonctionnalités, plus ils étaient considérés comme utiles en termes d'évaluation des performances.
La sécurité n'était qu'une question secondaire, si tant est qu'elle soit prise en compte. Au lieu de cela, c'était aux équipes de sécurité des applications (AppSec) de s'occuper de tout cela. Les équipes AppSec n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent des applications complètes au stade du développement pour appliquer des correctifs de sécurité ou pour réécrire du code afin de corriger des vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà « terminée » équivalait à une heure où il ne créait pas de nouvelles applications et fonctionnalités, diminuant ainsi ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
L'environnement de menaces a ensuite modifié l'importance et la priorisation de la sécurité pour la plupart des entreprises. Selon le récent Coût d'un rapport de violation de données selon IBM et le Ponemon Institute, une faille de cybersécurité coûte aujourd'hui en moyenne 3,8 millions de dollars par incident, bien que ce ne soit guère la limite supérieure. À elle seule, une entreprise a subi des pertes de 1,3 milliard de dollars à la suite d'une faille sur son réseau. Les entreprises d'aujourd'hui souhaitent bénéficier de la sécurité offerte par DevSecOps, mais elles tardent malheureusement à récompenser les développeurs qui répondent à cet appel.
Le simple fait de demander aux équipes de développement de prendre en compte la sécurité ne fonctionnera pas, surtout si elles sont toujours encouragées uniquement sur la base de la rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de se renseigner sur la sécurité et de sécuriser leur code pourraient perdre les meilleures évaluations de performances et les bonus lucratifs que leurs collègues moins soucieux de la sécurité continuent de gagner. C'est presque comme si les entreprises truquaient involontairement le système pour corriger leurs propres failles de sécurité, et cela revient à leur perception de l'équipe de développement. S'ils ne les considèrent pas comme les premières lignes de la sécurité, il est très peu probable qu'un plan viable visant à utiliser leur main-d'œuvre se concrétise.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des décennies d'expérience dans le codage, mais très peu en matière de sécurité... Après tout, cela n'a jamais été exigé d'eux. À moins qu'une entreprise ne propose un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ses développeurs acquièrent soudainement de nouvelles compétences et les mettent en œuvre de manière significative afin de réduire activement les vulnérabilités.
Récompenser les développeurs pour leurs bonnes pratiques en matière de sécurité
La bonne nouvelle, c'est que l'écrasante majorité des développeurs font leur travail parce qu'ils le trouvent à la fois stimulant et gratifiant, et parce qu'ils jouissent du respect que leur poste implique. Michael Shpilt, codeur professionnel de longue date a récemment écrit à propos de toutes les choses qui le motivent, lui et ses collègues programmeurs, dans leur travail de développement. Oui, il cite la compensation monétaire parmi ces incitations, mais elle se situe étonnamment loin dans la liste. Il privilégie plutôt le plaisir de créer quelque chose de nouveau, d'acquérir de nouvelles compétences et la satisfaction de savoir que son travail sera directement utilisé pour aider les autres. Il parle également de son désir de se sentir valorisé au sein de son entreprise et de sa communauté. Bref, les développeurs sont comme beaucoup de bonnes personnes qui sont fières de leur travail.
Les développeurs tels que Shpilt et d'autres ne veulent pas que des acteurs malveillants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs mêmes qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement réorienter leurs priorités vers la sécurité sans soutien. Sinon, c'est presque comme si le système allait jouer contre eux.
Pour aider les équipes de développement à améliorer leurs prouesses en matière de cybersécurité, il faut d'abord leur enseigner les compétences nécessaires. L'utilisation d'un apprentissage échafaudé et d'outils tels que la formation Just-in-Time (JiT) peut rendre ce processus beaucoup moins pénible et aider à tirer parti des connaissances existantes dans le bon contexte.
Le principe de JiT est que les développeurs reçoivent les bonnes connaissances au bon moment. Par exemple, si un outil de formation pour développeurs JiT détecte qu'un programmeur crée un morceau de code non sécurisé ou introduit accidentellement une vulnérabilité dans son application, il peut s'activer et montrer au développeur comment il pourrait résoudre ce problème et comment écrire un code plus sécurisé pour remplir cette même fonction à l'avenir.
L'engagement en faveur de l'amélioration des compétences étant en place, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Les codeurs devraient plutôt être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs développeurs devenant champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. Et ces champions doivent être récompensés à la fois par le prestige de l'entreprise et par une compensation financière. Il est également important de se rappeler que les développeurs n'ont généralement pas une expérience positive de la sécurité, et les encourager grâce à un apprentissage positif et amusant et à des incitations adaptées à leurs intérêts contribuera grandement à garantir à la fois la rétention des connaissances et le désir de continuer à développer leurs compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation des développeurs, mais en s'attendant à ce que le développement d'applications sécurisées prenne un peu plus de temps, d'autant plus que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être la défense ultime contre les forces obscures d'un paysage de menaces de plus en plus dangereux. N'oubliez pas que les champions de ce nouveau monde, les développeurs qui créent constamment du nouveau code, doivent être respectés et rémunérés pour leur travail.
Vous voulez tester vos compétences en matière de sécurité par rapport à d'autres développeurs du monde entier ? Consultez Secure Code Warriors Jeux olympiques de 2021, et tu pourrais remporter un prix important lors de nos tournois mondiaux !
Table des matières
Chief Executive Officer, Chairman, and Co-Founder
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.
