L'incitation des développeurs est la clé de meilleures pratiques en matière de sécurité
Le paysage des cybermenaces devient chaque jour plus complexe. Les attaquants scrutent constamment les réseaux à la recherche d'applications, de programmes et d'instances en nuage vulnérables, et la dernière nouveauté du mois est l'API, largement considérée comme une proie facile grâce à ses contrôles de sécurité souvent laxistes. Ils sont si tenaces que les nouvelles applications peuvent parfois être compromises et exploitées dans les heures qui suivent leur déploiement. Le rapport Verizon 2021 Data Breach Investigations Report montre clairement que les menaces qui pèsent sur les entreprises et les organisations sont plus dangereuses aujourd'hui qu'à n'importe quel autre moment de l'histoire.
Il est de plus en plus évident que le seul moyen de fortifier véritablement les logiciels créés est de s'assurer qu'ils sont construits sur un code sécurisé. En d'autres termes, le meilleur moyen d'arrêter l'invasion des acteurs de la menace est de les empêcher de pénétrer dans vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont en faveur des attaquants.
Cette situation a d'abord donné naissance au développement agile et à DevOps, puis à l'ensemble du mouvement DevSecOps, où la sécurité est une responsabilité partagée par toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais la base de cette pyramide, et sans doute la partie la plus importante, ce sont les développeurs. Alors que la plupart des développeurs veulent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'un tel changement de priorités exige.
La défaite à dessein
Pendant de nombreuses années, on a dit aux développeurs que leur rôle principal au sein de leur entreprise était de créer et de déployer rapidement des applications dans un environnement en constante évolution, où les affaires ne s'arrêtent jamais et où 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'un pis-aller, si tant est qu'elle ait été prise en compte. Tout cela était laissé à l'appréciation des équipes chargées de la sécurité des applications (AppSec). Ces équipes n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent les applications terminées en développement pour appliquer les correctifs de sécurité ou réécrire le code afin de remédier aux vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà "terminée" était une heure qu'il ne passait pas à créer de nouvelles applications et fonctionnalités, ce qui diminuait ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
Ensuite, l'environnement des menaces a modifié l'importance et la priorité de la sécurité pour la plupart des entreprises. Selon le récent rapport Cost of a Data Breach Report d'IBM et du Ponemon Institute, le coût moyen d'une atteinte à la cybersécurité s'élève aujourd'hui à environ 3,8 millions de dollars par incident, bien que ce chiffre soit loin d'être la limite supérieure. Une entreprise a subi à elle seule des pertes de 1,3 milliard de dollars à la suite d'une atteinte à son réseau. Les entreprises d'aujourd'hui veulent la sécurité offerte par DevSecOps, mais, malheureusement, elles ont été lentes à récompenser les développeurs qui répondent à cet appel.
Il ne suffit pas de dire aux équipes de développement de prendre en compte la sécurité, surtout si elles sont encore récompensées sur la base de la seule rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de s'informer sur la sécurité et de sécuriser leur code pourraient en fait perdre de meilleures évaluations de performance et des primes lucratives que leurs collègues moins sensibilisés à la sécurité continuent de gagner. C'est un peu comme si les entreprises truquaient involontairement le système pour leurs propres échecs en matière de sécurité, et cela revient à la perception qu'elles ont de l'équipe de développement. Si elles ne les considèrent pas comme la ligne de front de la sécurité, il est très peu probable qu'un plan viable d'utilisation de leur main-d'œuvre aboutisse.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des dizaines d'années d'expérience en matière de codage, mais très peu en ce qui concerne la sécurité... après tout, cela ne leur a jamais été demandé. À moins qu'une entreprise n'offre un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ces derniers 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 apprécient le respect que leur position implique. Michael Shpilt, codeur professionnel de longue date , a récemment écrit sur toutes les choses qui le motivent, lui et ses collègues codeurs, dans leur travail de développement. Certes, il cite la rémunération monétaire parmi ces motivations, mais elle arrive é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 dit aussi vouloir se sentir valorisé au sein de son entreprise et de sa communauté. En bref, les développeurs sont comme beaucoup de gens bien qui sont fiers de leur travail.
Les développeurs comme Shpilt et d'autres ne veulent pas que des acteurs menaçants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement changer leurs priorités en faveur de la sécurité sans soutien. Sinon, c'est comme si le système travaillait 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 de l'apprentissage par échafaudage et d'outils tels que la formation juste à temps (JiT) peut rendre ce processus beaucoup moins pénible et permet de s'appuyer sur les connaissances existantes dans le bon contexte.
Par exemple, si un outil de formation des 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 activer et montrer au développeur comment il peut résoudre ce problème et comment écrire un code plus sécurisé pour exécuter la même fonction à l'avenir.
Avec un engagement en faveur de l'amélioration des compétences, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Au lieu de cela, les codeurs devraient être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs d'entre eux devenant des champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. 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 avec un apprentissage positif et amusant et des incitations qui répondent à leurs intérêts contribuera grandement à assurer à la fois la rétention des connaissances et le désir de continuer à développer les compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation d'un développeur, mais en sachant que le développement d'applications sécurisées peut prendre un peu plus de temps, notamment parce que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être l'ultime défense contre les arts sombres 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 de nouveaux codes, doivent être respectés et rémunérés pour leur travail.
Vous voulez mettre vos compétences en matière de sécurité à l'épreuve face à d'autres développeurs du monde entier ? Consultez le site Secure Code Warrior's Devlympics 2021et vous pourriez remporter un prix important sur notre site tournaments!
Les développeurs professionnels veulent adopter DevSecOps et écrire du code sécurisé, mais leurs organisations doivent soutenir ce changement s'ils veulent que cet effort se développe.
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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é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 chaque jour plus complexe. Les attaquants scrutent constamment les réseaux à la recherche d'applications, de programmes et d'instances en nuage vulnérables, et la dernière nouveauté du mois est l'API, largement considérée comme une proie facile grâce à ses contrôles de sécurité souvent laxistes. Ils sont si tenaces que les nouvelles applications peuvent parfois être compromises et exploitées dans les heures qui suivent leur déploiement. Le rapport Verizon 2021 Data Breach Investigations Report montre clairement que les menaces qui pèsent sur les entreprises et les organisations sont plus dangereuses aujourd'hui qu'à n'importe quel autre moment de l'histoire.
Il est de plus en plus évident que le seul moyen de fortifier véritablement les logiciels créés est de s'assurer qu'ils sont construits sur un code sécurisé. En d'autres termes, le meilleur moyen d'arrêter l'invasion des acteurs de la menace est de les empêcher de pénétrer dans vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont en faveur des attaquants.
Cette situation a d'abord donné naissance au développement agile et à DevOps, puis à l'ensemble du mouvement DevSecOps, où la sécurité est une responsabilité partagée par toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais la base de cette pyramide, et sans doute la partie la plus importante, ce sont les développeurs. Alors que la plupart des développeurs veulent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'un tel changement de priorités exige.
La défaite à dessein
Pendant de nombreuses années, on a dit aux développeurs que leur rôle principal au sein de leur entreprise était de créer et de déployer rapidement des applications dans un environnement en constante évolution, où les affaires ne s'arrêtent jamais et où 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'un pis-aller, si tant est qu'elle ait été prise en compte. Tout cela était laissé à l'appréciation des équipes chargées de la sécurité des applications (AppSec). Ces équipes n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent les applications terminées en développement pour appliquer les correctifs de sécurité ou réécrire le code afin de remédier aux vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà "terminée" était une heure qu'il ne passait pas à créer de nouvelles applications et fonctionnalités, ce qui diminuait ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
Ensuite, l'environnement des menaces a modifié l'importance et la priorité de la sécurité pour la plupart des entreprises. Selon le récent rapport Cost of a Data Breach Report d'IBM et du Ponemon Institute, le coût moyen d'une atteinte à la cybersécurité s'élève aujourd'hui à environ 3,8 millions de dollars par incident, bien que ce chiffre soit loin d'être la limite supérieure. Une entreprise a subi à elle seule des pertes de 1,3 milliard de dollars à la suite d'une atteinte à son réseau. Les entreprises d'aujourd'hui veulent la sécurité offerte par DevSecOps, mais, malheureusement, elles ont été lentes à récompenser les développeurs qui répondent à cet appel.
Il ne suffit pas de dire aux équipes de développement de prendre en compte la sécurité, surtout si elles sont encore récompensées sur la base de la seule rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de s'informer sur la sécurité et de sécuriser leur code pourraient en fait perdre de meilleures évaluations de performance et des primes lucratives que leurs collègues moins sensibilisés à la sécurité continuent de gagner. C'est un peu comme si les entreprises truquaient involontairement le système pour leurs propres échecs en matière de sécurité, et cela revient à la perception qu'elles ont de l'équipe de développement. Si elles ne les considèrent pas comme la ligne de front de la sécurité, il est très peu probable qu'un plan viable d'utilisation de leur main-d'œuvre aboutisse.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des dizaines d'années d'expérience en matière de codage, mais très peu en ce qui concerne la sécurité... après tout, cela ne leur a jamais été demandé. À moins qu'une entreprise n'offre un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ces derniers 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 apprécient le respect que leur position implique. Michael Shpilt, codeur professionnel de longue date , a récemment écrit sur toutes les choses qui le motivent, lui et ses collègues codeurs, dans leur travail de développement. Certes, il cite la rémunération monétaire parmi ces motivations, mais elle arrive é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 dit aussi vouloir se sentir valorisé au sein de son entreprise et de sa communauté. En bref, les développeurs sont comme beaucoup de gens bien qui sont fiers de leur travail.
Les développeurs comme Shpilt et d'autres ne veulent pas que des acteurs menaçants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement changer leurs priorités en faveur de la sécurité sans soutien. Sinon, c'est comme si le système travaillait 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 de l'apprentissage par échafaudage et d'outils tels que la formation juste à temps (JiT) peut rendre ce processus beaucoup moins pénible et permet de s'appuyer sur les connaissances existantes dans le bon contexte.
Par exemple, si un outil de formation des 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 activer et montrer au développeur comment il peut résoudre ce problème et comment écrire un code plus sécurisé pour exécuter la même fonction à l'avenir.
Avec un engagement en faveur de l'amélioration des compétences, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Au lieu de cela, les codeurs devraient être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs d'entre eux devenant des champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. 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 avec un apprentissage positif et amusant et des incitations qui répondent à leurs intérêts contribuera grandement à assurer à la fois la rétention des connaissances et le désir de continuer à développer les compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation d'un développeur, mais en sachant que le développement d'applications sécurisées peut prendre un peu plus de temps, notamment parce que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être l'ultime défense contre les arts sombres 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 de nouveaux codes, doivent être respectés et rémunérés pour leur travail.
Vous voulez mettre vos compétences en matière de sécurité à l'épreuve face à d'autres développeurs du monde entier ? Consultez le site Secure Code Warrior's Devlympics 2021et vous pourriez remporter un prix important sur notre site tournaments!
Le paysage des cybermenaces devient chaque jour plus complexe. Les attaquants scrutent constamment les réseaux à la recherche d'applications, de programmes et d'instances en nuage vulnérables, et la dernière nouveauté du mois est l'API, largement considérée comme une proie facile grâce à ses contrôles de sécurité souvent laxistes. Ils sont si tenaces que les nouvelles applications peuvent parfois être compromises et exploitées dans les heures qui suivent leur déploiement. Le rapport Verizon 2021 Data Breach Investigations Report montre clairement que les menaces qui pèsent sur les entreprises et les organisations sont plus dangereuses aujourd'hui qu'à n'importe quel autre moment de l'histoire.
Il est de plus en plus évident que le seul moyen de fortifier véritablement les logiciels créés est de s'assurer qu'ils sont construits sur un code sécurisé. En d'autres termes, le meilleur moyen d'arrêter l'invasion des acteurs de la menace est de les empêcher de pénétrer dans vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont en faveur des attaquants.
Cette situation a d'abord donné naissance au développement agile et à DevOps, puis à l'ensemble du mouvement DevSecOps, où la sécurité est une responsabilité partagée par toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais la base de cette pyramide, et sans doute la partie la plus importante, ce sont les développeurs. Alors que la plupart des développeurs veulent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'un tel changement de priorités exige.
La défaite à dessein
Pendant de nombreuses années, on a dit aux développeurs que leur rôle principal au sein de leur entreprise était de créer et de déployer rapidement des applications dans un environnement en constante évolution, où les affaires ne s'arrêtent jamais et où 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'un pis-aller, si tant est qu'elle ait été prise en compte. Tout cela était laissé à l'appréciation des équipes chargées de la sécurité des applications (AppSec). Ces équipes n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent les applications terminées en développement pour appliquer les correctifs de sécurité ou réécrire le code afin de remédier aux vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà "terminée" était une heure qu'il ne passait pas à créer de nouvelles applications et fonctionnalités, ce qui diminuait ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
Ensuite, l'environnement des menaces a modifié l'importance et la priorité de la sécurité pour la plupart des entreprises. Selon le récent rapport Cost of a Data Breach Report d'IBM et du Ponemon Institute, le coût moyen d'une atteinte à la cybersécurité s'élève aujourd'hui à environ 3,8 millions de dollars par incident, bien que ce chiffre soit loin d'être la limite supérieure. Une entreprise a subi à elle seule des pertes de 1,3 milliard de dollars à la suite d'une atteinte à son réseau. Les entreprises d'aujourd'hui veulent la sécurité offerte par DevSecOps, mais, malheureusement, elles ont été lentes à récompenser les développeurs qui répondent à cet appel.
Il ne suffit pas de dire aux équipes de développement de prendre en compte la sécurité, surtout si elles sont encore récompensées sur la base de la seule rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de s'informer sur la sécurité et de sécuriser leur code pourraient en fait perdre de meilleures évaluations de performance et des primes lucratives que leurs collègues moins sensibilisés à la sécurité continuent de gagner. C'est un peu comme si les entreprises truquaient involontairement le système pour leurs propres échecs en matière de sécurité, et cela revient à la perception qu'elles ont de l'équipe de développement. Si elles ne les considèrent pas comme la ligne de front de la sécurité, il est très peu probable qu'un plan viable d'utilisation de leur main-d'œuvre aboutisse.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des dizaines d'années d'expérience en matière de codage, mais très peu en ce qui concerne la sécurité... après tout, cela ne leur a jamais été demandé. À moins qu'une entreprise n'offre un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ces derniers 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 apprécient le respect que leur position implique. Michael Shpilt, codeur professionnel de longue date , a récemment écrit sur toutes les choses qui le motivent, lui et ses collègues codeurs, dans leur travail de développement. Certes, il cite la rémunération monétaire parmi ces motivations, mais elle arrive é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 dit aussi vouloir se sentir valorisé au sein de son entreprise et de sa communauté. En bref, les développeurs sont comme beaucoup de gens bien qui sont fiers de leur travail.
Les développeurs comme Shpilt et d'autres ne veulent pas que des acteurs menaçants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement changer leurs priorités en faveur de la sécurité sans soutien. Sinon, c'est comme si le système travaillait 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 de l'apprentissage par échafaudage et d'outils tels que la formation juste à temps (JiT) peut rendre ce processus beaucoup moins pénible et permet de s'appuyer sur les connaissances existantes dans le bon contexte.
Par exemple, si un outil de formation des 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 activer et montrer au développeur comment il peut résoudre ce problème et comment écrire un code plus sécurisé pour exécuter la même fonction à l'avenir.
Avec un engagement en faveur de l'amélioration des compétences, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Au lieu de cela, les codeurs devraient être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs d'entre eux devenant des champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. 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 avec un apprentissage positif et amusant et des incitations qui répondent à leurs intérêts contribuera grandement à assurer à la fois la rétention des connaissances et le désir de continuer à développer les compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation d'un développeur, mais en sachant que le développement d'applications sécurisées peut prendre un peu plus de temps, notamment parce que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être l'ultime défense contre les arts sombres 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 de nouveaux codes, doivent être respectés et rémunérés pour leur travail.
Vous voulez mettre vos compétences en matière de sécurité à l'épreuve face à d'autres développeurs du monde entier ? Consultez le site Secure Code Warrior's Devlympics 2021et vous pourriez remporter un prix important sur notre site tournaments!
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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é.
Voir le rapportRéservez 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 chaque jour plus complexe. Les attaquants scrutent constamment les réseaux à la recherche d'applications, de programmes et d'instances en nuage vulnérables, et la dernière nouveauté du mois est l'API, largement considérée comme une proie facile grâce à ses contrôles de sécurité souvent laxistes. Ils sont si tenaces que les nouvelles applications peuvent parfois être compromises et exploitées dans les heures qui suivent leur déploiement. Le rapport Verizon 2021 Data Breach Investigations Report montre clairement que les menaces qui pèsent sur les entreprises et les organisations sont plus dangereuses aujourd'hui qu'à n'importe quel autre moment de l'histoire.
Il est de plus en plus évident que le seul moyen de fortifier véritablement les logiciels créés est de s'assurer qu'ils sont construits sur un code sécurisé. En d'autres termes, le meilleur moyen d'arrêter l'invasion des acteurs de la menace est de les empêcher de pénétrer dans vos applications. Une fois que vous commencez à mener cette guerre, la plupart des avantages sont en faveur des attaquants.
Cette situation a d'abord donné naissance au développement agile et à DevOps, puis à l'ensemble du mouvement DevSecOps, où la sécurité est une responsabilité partagée par toutes les personnes impliquées dans le processus de création de logiciels, du développement au déploiement. Mais la base de cette pyramide, et sans doute la partie la plus importante, ce sont les développeurs. Alors que la plupart des développeurs veulent faire leur part et écrire du code sécurisé, de nombreuses organisations pour lesquelles ils travaillent sont moins favorables aux changements qu'un tel changement de priorités exige.
La défaite à dessein
Pendant de nombreuses années, on a dit aux développeurs que leur rôle principal au sein de leur entreprise était de créer et de déployer rapidement des applications dans un environnement en constante évolution, où les affaires ne s'arrêtent jamais et où 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'un pis-aller, si tant est qu'elle ait été prise en compte. Tout cela était laissé à l'appréciation des équipes chargées de la sécurité des applications (AppSec). Ces équipes n'étaient pas appréciées par la plupart des développeurs, car elles renvoyaient souvent les applications terminées en développement pour appliquer les correctifs de sécurité ou réécrire le code afin de remédier aux vulnérabilités. Et chaque heure qu'un développeur passait à travailler sur une application déjà "terminée" était une heure qu'il ne passait pas à créer de nouvelles applications et fonctionnalités, ce qui diminuait ses performances (et sa valeur, aux yeux d'une entreprise particulièrement punitive).
Ensuite, l'environnement des menaces a modifié l'importance et la priorité de la sécurité pour la plupart des entreprises. Selon le récent rapport Cost of a Data Breach Report d'IBM et du Ponemon Institute, le coût moyen d'une atteinte à la cybersécurité s'élève aujourd'hui à environ 3,8 millions de dollars par incident, bien que ce chiffre soit loin d'être la limite supérieure. Une entreprise a subi à elle seule des pertes de 1,3 milliard de dollars à la suite d'une atteinte à son réseau. Les entreprises d'aujourd'hui veulent la sécurité offerte par DevSecOps, mais, malheureusement, elles ont été lentes à récompenser les développeurs qui répondent à cet appel.
Il ne suffit pas de dire aux équipes de développement de prendre en compte la sécurité, surtout si elles sont encore récompensées sur la base de la seule rapidité. En fait, dans un tel système, les développeurs qui prennent le temps de s'informer sur la sécurité et de sécuriser leur code pourraient en fait perdre de meilleures évaluations de performance et des primes lucratives que leurs collègues moins sensibilisés à la sécurité continuent de gagner. C'est un peu comme si les entreprises truquaient involontairement le système pour leurs propres échecs en matière de sécurité, et cela revient à la perception qu'elles ont de l'équipe de développement. Si elles ne les considèrent pas comme la ligne de front de la sécurité, il est très peu probable qu'un plan viable d'utilisation de leur main-d'œuvre aboutisse.
Et cela ne tient même pas compte du manque de formation. Certains développeurs très compétents ont des dizaines d'années d'expérience en matière de codage, mais très peu en ce qui concerne la sécurité... après tout, cela ne leur a jamais été demandé. À moins qu'une entreprise n'offre un bon programme de formation à ses programmeurs qualifiés, elle ne peut guère s'attendre à ce que ces derniers 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 apprécient le respect que leur position implique. Michael Shpilt, codeur professionnel de longue date , a récemment écrit sur toutes les choses qui le motivent, lui et ses collègues codeurs, dans leur travail de développement. Certes, il cite la rémunération monétaire parmi ces motivations, mais elle arrive é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 dit aussi vouloir se sentir valorisé au sein de son entreprise et de sa communauté. En bref, les développeurs sont comme beaucoup de gens bien qui sont fiers de leur travail.
Les développeurs comme Shpilt et d'autres ne veulent pas que des acteurs menaçants compromettent leur code et l'utilisent pour nuire à leur entreprise ou aux utilisateurs qu'ils essaient d'aider. Mais ils ne peuvent pas soudainement changer leurs priorités en faveur de la sécurité sans soutien. Sinon, c'est comme si le système travaillait 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 de l'apprentissage par échafaudage et d'outils tels que la formation juste à temps (JiT) peut rendre ce processus beaucoup moins pénible et permet de s'appuyer sur les connaissances existantes dans le bon contexte.
Par exemple, si un outil de formation des 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 activer et montrer au développeur comment il peut résoudre ce problème et comment écrire un code plus sécurisé pour exécuter la même fonction à l'avenir.
Avec un engagement en faveur de l'amélioration des compétences, les anciennes méthodes d'évaluation des développeurs basées uniquement sur la rapidité doivent être éliminées. Au lieu de cela, les codeurs devraient être récompensés en fonction de leur capacité à créer du code sécurisé, les meilleurs d'entre eux devenant des champions de la sécurité qui aident le reste de l'équipe à améliorer ses compétences. 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 avec un apprentissage positif et amusant et des incitations qui répondent à leurs intérêts contribuera grandement à assurer à la fois la rétention des connaissances et le désir de continuer à développer les compétences.
Les entreprises peuvent toujours inclure la vitesse de codage dans l'évaluation d'un développeur, mais en sachant que le développement d'applications sécurisées peut prendre un peu plus de temps, notamment parce que les codeurs acquièrent ces nouvelles compétences.
DevSecOps peut être l'ultime défense contre les arts sombres 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 de nouveaux codes, doivent être respectés et rémunérés pour leur travail.
Vous voulez mettre vos compétences en matière de sécurité à l'épreuve face à d'autres développeurs du monde entier ? Consultez le site Secure Code Warrior's Devlympics 2021et vous pourriez remporter un prix important sur notre site tournaments!
Table des matières
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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émonstrationTéléchargerRessources pour vous aider à démarrer
La puissance d'OpenText Fortify + Secure Code Warrior
OpenText Fortify et Secure Code Warrior unissent leurs forces pour aider les entreprises à réduire les risques, à transformer les développeurs en champions de la sécurité et à renforcer la confiance des clients. Pour en savoir plus, cliquez ici.
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
Ressources pour vous aider à démarrer
10 prédictions clés : Secure Code Warrior sur l'influence de l'IA et de la conception sécurisée en 2025
Les organisations sont confrontées à des décisions difficiles sur l'utilisation de l'IA pour soutenir la productivité à long terme, la durabilité et le retour sur investissement de la sécurité. Au cours des dernières années, il nous est apparu clairement que l'IA ne remplacera jamais complètement le rôle du développeur. Des partenariats IA + développeurs aux pressions croissantes (et à la confusion) autour des attentes en matière de conception sécurisée, examinons de plus près ce à quoi nous pouvons nous attendre au cours de l'année prochaine.
OWASP Top 10 pour les applications LLM : Ce qui est nouveau, ce qui a changé et comment rester en sécurité
Gardez une longueur d'avance dans la sécurisation des applications LLM avec les dernières mises à jour du Top 10 de l'OWASP. Découvrez ce qui est nouveau, ce qui a changé et comment Secure Code Warrior vous fournit des ressources d'apprentissage actualisées pour atténuer les risques dans l'IA générative.
La note de confiance révèle la valeur des initiatives d'amélioration de la sécurité par la conception
Nos recherches ont montré que la formation au code sécurisé fonctionne. Le Trust Score, qui utilise un algorithme s'appuyant sur plus de 20 millions de points de données d'apprentissage issus du travail de plus de 250 000 apprenants dans plus de 600 organisations, révèle son efficacité à réduire les vulnérabilités et la manière de rendre l'initiative encore plus efficace.
.png)
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Codage axé sur le développeur.
En toute sécurité.
Contactez-nous dès aujourd'hui et faites de la sécurité des logiciels une partie intrinsèque de votre processus de développement.
