Le paysage des menaces d’aujourd’hui est en constante évolution, et maintenant plus que jamais, les organisations et les entreprises de tous les secteurs ont un besoin critique de produire et de maintenir constamment des logiciels sécurisés. Alors que certains secteurs verticaux – comme le secteur financier, par exemple – sont soumis à des exigences réglementaires et de conformité depuis un certain temps, nous constatons une augmentation constante de l’attention portée aux meilleures pratiques en matière de cybersécurité aux plus hauts niveaux du gouvernement, avec les États-Unis, le Royaume-Uni et L’Australie a tous mis en lumière très récemment la nécessité d’un développement sécurisé à chaque étape du SDLC.
Malgré cela, les attaquants trouvent constamment de nouvelles façons de contourner même les protections et les défenses les plus avancées. Par exemple, beaucoup ont déplacé leur attention de la diffusion de logiciels malveillants vers la compromission des API ou le lancement d’attaques ciblées. contre une chaîne d’approvisionnement. Et bien que ces incidents de haut niveau se produisent avec une fréquence beaucoup plus élevée, il en va de même pour les exploits plus simplistes tels que les scripts intersites et l’injection SQL, qui sont tous deux un fléau pour les défenses de la cybersécurité depuis des décennies. Juste le mois dernierune vulnérabilité critique d’injection SQL a été signalée dans un plugin WooCommerce WordPress, avec un indice de gravité de 9,8/10.
Il devient évident que si les plates-formes et les défenses de cybersécurité sont des composants essentiels de la défense contre les attaques modernes, ce dont on a vraiment besoin, c’est d’un code sécurisé pouvant être déployé sans vulnérabilités. Et cela nécessite une augmentation délibérée et engagée des normes de codage sécurisé, actionnée par des développeurs soucieux de la sécurité.
De nombreux développeurs disent qu’ils sont prêts à défendre la sécurité et à s’engager à respecter des normes plus élevées de qualité de code et de sortie sécurisée, mais ils ne peuvent pas le faire seuls. Nous ne pouvons pas nous permettre d’ignorer les besoins des développeurs dans la lutte contre les vulnérabilités courantes, et ils ont besoin du soutien d’outils et de formations adaptés, ainsi que d’un remaniement des paramètres traditionnels par lesquels ils sont souvent jugés par leurs employeurs et organisations.
Pourquoi la plupart des développeurs ne donnent pas déjà la priorité à la sécurité
Les meilleures pratiques de codage ont continué d’évoluer au fil des ans, en réponse aux besoins des entreprises et aux tendances du marché. Dans le passé, la plupart des applications étaient créées à l’aide de ce qu’on appelle développement de la cascade modèle dans lequel les ingénieurs logiciels travaillaient pour préparer leur code afin d’atteindre une série continue d’étapes ou d’objectifs avant de passer à la phase de développement suivante. Waterfall avait tendance à soutenir le développement de programmes qui, après avoir franchi toutes les étapes précédentes en cours de route, étaient exempts de bogues ou de défauts opérationnels au moment où ils étaient prêts pour l’environnement de production. Mais selon les normes d’aujourd’hui, c’était douloureusement lent, avec parfois 18 mois ou plus entre le démarrage d’un projet et l’arrivée à la ligne d’arrivée. Et cela ne va pas voler dans la plupart des entreprises ces jours-ci.
La méthode agile avait tendance à remplacer Waterfall, en mettant beaucoup plus l’accent sur la vitesse. Et cela a été suivi par DevOps, qui est conçu pour encore plus de rapidité en combinant le développement et les opérations pour s’assurer que les programmes sont prêts pour la production presque dès qu’ils effacent les derniers ajustements de développement.
Mettre la vitesse sur la sécurité, et presque tout le reste au-delà de la fonctionnalité, était une nécessité à mesure que l’environnement commercial évoluait. Dans un monde basé sur le cloud où tout le monde est en ligne tout le temps et où des millions de transactions mobiles peuvent se produire toutes les quelques secondes, il est essentiel de déployer des logiciels et de les intégrer dans le pipeline d’intégration et de livraison continues (CI/CD) aussi rapidement que possible. pour les entreprises.
Ce n’est pas que les organisations ne se souciaient pas de la sécurité. C’est juste que dans l’environnement commercial concurrentiel qui existe dans la plupart des industries, la vitesse était considérée comme plus importante. Et les développeurs qui pouvaient égaler cette vitesse ont prospéré au point où cela est devenu le principal moyen par lequel leurs performances professionnelles étaient jugées.
Maintenant que les attaques avancées se multiplient de manière si spectaculaire, le déploiement de code vulnérable devient un handicap. La préférence change une fois de plus, la sécurité devenant de plus en plus l’objectif principal du développement de logiciels, suivie de près par la vitesse. Le renforcement de la sécurité après coup n’est pas seulement dangereux, il ralentit également le processus de déploiement du logiciel. Cela a conduit à la montée de la DevSecOps méthodologie qui tente de fusionner vitesse et sécurité pour aider à générer un code sécurisé et considère la sécurité comme une responsabilité partagée. Mais les développeurs formés à la vitesse pure ne peuvent pas devenir conscients de la sécurité fonctionnelle sans un soutien important de la part de leurs organisations.
Ce dont les développeurs ont besoin pour vraiment avoir un impact sur la réduction des vulnérabilités
La bonne nouvelle est que la plupart des développeurs souhaitent voir un passage au codage sécurisé et une redéfinition des priorités de la sécurité dans le cadre du processus de développement. Dans un enquête complète menée par Evans Data auprès de plus de 1 200 développeurs professionnels travaillant activement dans le monde au début de cette année, la grande majorité a déclaré qu’elle soutenait le concept de création de code sécurisé. La plupart s’attendaient également à ce qu’elle devienne une priorité dans leur organisation. Cependant, seuls 8 % des répondants ont déclaré que l’écriture de code sécurisé était facile à réaliser. Cela laisse beaucoup de place à l’amélioration au sein des équipes de développement de la plupart des organisations entre ce qui est nécessaire et ce qui est requis pour y parvenir.
Le simple fait d’imposer un code sécurisé ne fera pas le travail, et sans effort pour développer les bonnes compétences et la sensibilisation, cela perturbera fortement leur flux de travail. Les équipes de développement doivent exister dans un environnement qui nourrit leur esprit de sécurité et promeut une culture de responsabilité partagée.
La plus grande chose dont ils ont besoin est une meilleure formation pour eux, suivie d’outils qui aident à faire du codage sécurisé une partie intégrante de leur flux de travail. Et le programme doit être personnalisé afin que les développeurs moins expérimentés puissent commencer leur formation en apprenant à reconnaître les types de vulnérabilités courantes qui se glissent souvent dans le code, avec de nombreux apprentissages pratiques et des exemples. Pendant ce temps, les développeurs plus avancés qui démontrent leurs compétences en matière de sécurité peuvent à la place être chargés de bogues plus complexes et peut-être même de concepts avancés de modélisation des menaces.
En plus de financer et de soutenir les programmes de formation, notamment en accordant aux développeurs suffisamment de temps loin du codage pour participer correctement à ces programmes, les organisations doivent également changer la façon dont leur cohorte est évaluée. La principale mesure pour récompenser les développeurs doit s’éloigner de la vitesse brute. Au lieu de cela, les évaluations pourraient récompenser ceux qui peuvent créer un code sécurisé exempt de vulnérabilités ou d’exploits. Oui, la vitesse peut également être un facteur évalué, mais avant tout, le code doit être sécurisé, et le développement moderne doit tracer une voie où la sécurité à la vitesse n’est plus un mythe.
L’envoi de code non sécurisé ou vulnérable ne devrait pas être un risque commercial acceptable, et renforcer la sécurité après coup devient de plus en plus inefficace. Heureusement, la meilleure arme pour lutter contre cette tendance inquiétante est de faire en sorte que la communauté des développeurs produise un code sécurisé que les attaquants ne peuvent pas exploiter. La plupart des développeurs sont prêts à relever ce défi ; donnez-leur le soutien nécessaire pour y arriver.
Secure Code Warrior est l’une des quatre sociétés citées dans le rapport Gartner® Cool Vendors™ in Software Engineering: Enhancing Developer Productivity. Nous sommes prêts à aider les équipes de développement à naviguer dans les complexités du développement de logiciels sécurisés avec des outils qui ont du sens dans leur monde. Apprendre encore plus.
Noter – Cet article est rédigé et contribué par Matias Madou, CTO et co-fondateur, Secure Code Warrior.