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.
Directeur général, président et cofondateur
Secure Code Warrior 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é.
Veuillez réserver une démonstration.
Directeur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
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 !
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior 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é.
Veuillez consulter le rapportVeuillez réserver une démonstration.
Directeur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
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
Directeur général, président et cofondateur
Secure Code Warrior 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é.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Thèmes 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.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à 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 clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.
