Blog

L'incitation des développeurs est la clé de meilleures pratiques en matière de sécurité

Pieter Danhieux
Publié le 19 octobre 2021

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!

Voir la ressource
Voir la ressource

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.

Vous souhaitez en savoir plus ?

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
Partager sur :
Auteur
Pieter Danhieux
Publié le 19 octobre 2021

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.

Partager sur :

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!

Voir la ressource
Voir la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions que vous nous autorisiez à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
Pour soumettre le formulaire, veuillez activer les cookies "Analytics". N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

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!

Accès aux ressources

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
Partager sur :
Vous souhaitez en savoir plus ?

Partager sur :
Auteur
Pieter Danhieux
Publié le 19 octobre 2021

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.

Partager sur :

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

Voir la ressource
Vous souhaitez en savoir plus ?

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écharger
Partager sur :
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles