Cette vulnérabilité peut survenir lorsque les développeurs ne parviennent pas à implémenter correctement les règles de logique métier, ce qui pourrait rendre leurs applications vulnérables à divers types d'attaques si un utilisateur malveillant choisissait de les exploiter.

S'il y a bien une chose capable de gâcher Noël dans le secteur de la cybersécurité, c'est une violation de données dévastatrice en passe de devenir le plus grand événement de cyberespionnage jamais enregistré contre le gouvernement américain.

Une fois de plus, la cause profonde du piratage d'Equifax est une vulnérabilité d'application web. Ce type de faille existe depuis plus d'une décennie, mais reste d'une actualité brûlante.

Les attaques par injection, tristement célèbres pour être les reines des vulnérabilités (par catégorie), ont été détrônées par le contrôle d'accès défaillant, désormais considéré comme le pire du pire, et les développeurs doivent en prendre note.

Épisode 139 : Matias Madou aborde la formation au développement sécurisé et la recherche en tests de sécurité logicielle

En règle générale, des contrôles d'autorisation au niveau de l'objet doivent être intégrés à chaque fonction accédant à une source de données via une saisie utilisateur ; ne pas le faire expose à des risques considérables.

Un parcours de formation sur mesure, regroupant précisément les modules dont vos développeurs ont besoin pour démontrer leurs compétences, aura un impact significatif et leur permettra d'être opérationnels immédiatement en matière de bonnes pratiques de sécurité au quotidien.

Près de 300 000 développeurs répartis dans environ 95 000 applications utilisent le BSIMM8 pour planifier, exécuter et mesurer leurs initiatives de sécurité logicielle (SSI).

Déplacer les correctifs de sécurité vers le processus de développement n'est pas chose aisée, mais c'est une nécessité dans le monde actuel, où même des appareils en apparence simples, comme les outils de présentation, sont à la fois étonnamment complexes et connectés à tout le reste.

Nous devons parvenir à un stade où la sécurité est perçue comme une responsabilité partagée à l'échelle de toute l'organisation et tout au long du cycle de vie du développement logiciel (SDLC). C'est tout à fait possible en s'engageant dans un environnement DevSecOps complet et hautement collaboratif.

La vulnérabilité liée à l'absence de contrôle d'accès au niveau des fonctions permet aux utilisateurs d'exécuter des fonctions qui devraient être restreintes, ou d'accéder à des ressources qui devraient être protégées.

L'authentification sert souvent de passerelle vers une application et, potentiellement, vers le reste d'un réseau ; elle constitue donc une cible de choix pour les attaquants. Si un processus d'authentification est défaillant ou vulnérable, il y a de fortes chances que les attaquants découvrent cette faille et l'exploitent.

Selon les enquêteurs, seule une erreur dans le code informatique des attaquants a permis d'éviter une explosion.

Le développement logiciel n'est plus une activité isolée. Lorsque nous prenons en compte tous les aspects des risques liés aux logiciels — du cloud aux systèmes embarqués dans les appareils et les véhicules, en passant par nos infrastructures critiques et les API qui relient le tout — la surface d'attaque devient illimitée et incontrôlable.

Les développeurs sont idéalement placés pour faire une transition lucrative vers la sécurité applicative (AppSec).

Il est indéniable que ces deux dernières années ont transformé les normes de cybersécurité. Bien que cela ne soit pas obligatoire, toutes les organisations devraient se fixer pour objectif de suivre cette voie et d'examiner les pratiques de sécurité de leurs fournisseurs comme si elles faisaient partie intégrante de leur propre programme de sécurité interne.

La vulnérabilité d'assignation de masse est apparue car de nombreux frameworks modernes encouragent les développeurs à utiliser des fonctions qui lient automatiquement les entrées des clients aux variables de code et aux objets internes.

Nous avons réfléchi à la manière de réduire les obstacles à la formation lorsque vous en avez besoin, et à la façon d'intégrer le micro-apprentissage dans votre flux de travail de manière plus fluide.

Les développeurs ne pourront pas réduire efficacement les vulnérabilités sans une compréhension fondamentale de leur fonctionnement, de leur dangerosité, des modèles qui les provoquent et des pratiques de conception ou de codage permettant de les corriger dans un contexte qui leur est familier. Une approche structurée permet d'acquérir des connaissances par étapes pour obtenir une vision globale de ce que signifie coder de manière sécurisée, protéger une base de code et s'affirmer en tant que développeur sensibilisé à la sécurité.

Par définition, les attaques « zero-day » ne laissent aucun répit aux développeurs pour identifier et corriger les vulnérabilités exploitables, car les attaquants ont toujours une longueur d'avance. Une fois les dégâts causés, c'est la course contre la montre pour réparer le logiciel et limiter l'impact sur la réputation de l'entreprise. Les attaquants conservent un avantage permanent ; il est donc crucial de réduire cet écart autant que possible.

Voici la première partie d'une série consacrée à la mise en conformité PCI-DSS au sein d'une organisation. Dans ce chapitre, nous détaillons comment les spécialistes de la sécurité applicative (AppSec) peuvent collaborer étroitement avec les responsables du développement pour autonomiser les développeurs, renforcer le cycle de vie de développement sécurisé (SSDLC) et obtenir des résultats concrets à partir de législations générales.

Nous savons déjà qu'une journée de travail est bien remplie. Quelle motivation les développeurs auraient-ils à se traîner dans une salle de classe ou à changer de contexte pour suivre une formation théorique statique en cinq étapes ?

Il existe plusieurs raisons pour lesquelles les outils de sécurité applicative (AppSec) ne sont pas utilisés comme nous pourrions nous y attendre. Le problème ne réside pas tant dans les outils et leurs fonctionnalités que dans la manière dont ils s'intègrent à l'ensemble du programme de sécurité.

Nous souhaitons mettre en lumière l'un de nos experts, Oscar Quintas. Membre de notre équipe Product Content, il occupe le poste de chercheur principal en sécurité. Il est également notre magicien attitré pour tout ce qui concerne l'Infrastructure as Code (IaC).

L'injection SQL fête ses 22 ans. Bien que cette vulnérabilité soit assez vieille pour boire, nous la laissons prendre le dessus au lieu de l'éliminer une fois pour toutes.

Le rapport de force entre les héros et les méchants de la cybersécurité est notoirement déséquilibré. Les données sensibles sont le nouvel or, et les attaquants s'adaptent rapidement pour contourner les défenses, exploitant les failles de sécurité, petites ou grandes, pour décrocher le gros lot.

Cette vulnérabilité survient lorsqu'un trop grand nombre de requêtes est reçu simultanément et que l'API ne dispose pas de ressources informatiques suffisantes pour les traiter. L'API peut alors devenir indisponible ou ne plus répondre aux nouvelles requêtes.

Pour lutter contre les cybercriminels, nous devons rester aussi proches d'eux que possible, en anticipant leurs terrains de jeu avec une approche préventive. Voici les domaines où je pense qu'ils pourraient commencer à faire des vagues l'année prochaine :

Si le contrôle d'accès au niveau de l'infrastructure n'est pas parfaitement configuré, l'entreprise entière s'expose à des attaquants qui peuvent exploiter cette vulnérabilité comme porte d'entrée pour de l'espionnage non autorisé ou une attaque complète.

Les cyberattaques sont de plus en plus fréquentes et les menaces visant les infrastructures Linux se multiplient, avec pour objectif final de mettre la main sur un trésor de données sensibles stockées dans le cloud.

Les mécanismes réels derrière cette vulnérabilité sont similaires à d'autres, mais l'exposition excessive de données, dans ce cas précis, se définit par l'implication de données légalement protégées ou hautement sensibles.

Tout comme les logiciels web, les API et les appareils mobiles, le code vulnérable des systèmes embarqués peut être exploité s'il est découvert par un attaquant dans la nature.

Voici la deuxième partie de notre mini-série sur la conformité PCI-DSS au sein d'une organisation. Dans ce dernier chapitre, nous détaillons comment les CTO et les CISO peuvent montrer l'exemple pour réduire les cyberrisques et rendre le processus fluide, efficace... et peut-être même un peu ludique pour les développeurs.

En pensant à votre organisation, réfléchissez à ces questions dans le contexte de votre rôle. Comment s'en sortirait-elle face au test DevSec ?

Une théorie bien connue veut que les cafards puissent survivre à pratiquement tout, même à une explosion nucléaire.

La faille liée à une journalisation et une surveillance insuffisantes résulte généralement d'une stratégie de cybersécurité défaillante concernant l'enregistrement des tentatives d'authentification échouées, des accès refusés et des erreurs de validation des entrées.

De nos jours, le hachage des données critiques telles que les mots de passe, les informations personnelles et les dossiers financiers au repos est la pierre angulaire de toute défense en cybersécurité.

Le récent décret sur la cybersécurité de l'administration Biden fait beaucoup parler dans le secteur de la sécurité, en particulier ceux qui cherchent à convaincre les développeurs de l'importance d'appliquer les meilleures pratiques de codage sécurisé dans leur travail quotidien.

Nous devons renforcer une approche de la cybersécurité axée sur l'humain ; elle donnera de meilleurs résultats qu'une dépendance excessive à l'automatisation, aux outils et à la réaction face à des problèmes déjà ancrés et identifiés.

Les développeurs sont parmi les mieux placés pour comprendre le code, ainsi que les configurations de sécurité et le contrôle d'accès. Leurs compétences en sécurité doivent être cultivées, et pour atteindre les normes élevées définies par le NIST, une structure de formation pratique pourrait bien être le moyen le plus efficace d'y parvenir, en particulier au sein de grandes équipes de développement.

Nous sommes ravis d'annoncer le lancement d'une toute nouvelle fonctionnalité sur la plateforme Secure Code Warrior : les Missions. Cette catégorie de défis inédite constitue la prochaine étape de la formation à la sécurité axée sur les développeurs, permettant aux utilisateurs de passer de la simple mémorisation de connaissances théoriques à leur application dans un environnement de simulation réel.

Que l'inconfort provienne de l'incertitude liée à une nouvelle méthode de travail, d'un manque de confiance ou simplement d'un scepticisme vis-à-vis du télétravail, je constate que les entreprises qui y résistent ont tendance à prendre du retard pour attirer les meilleurs talents, maintenir une portée mondiale et, en toute franchise, pour s'adapter à leur époque.

La clé de la plupart des systèmes de sécurité informatique repose aujourd'hui sur les mots de passe. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations continuent d'utiliser la sécurité par mot de passe comme élément de protection.

Le coût de modification d'une ligne de code sur un équipement avionique s'élève à 1 million de dollars et nécessite un an de mise en œuvre. Pour Southwest Airlines, dont la flotte repose sur des Boeing 737, cela pourrait les « mettre en faillite ».

Le déluge d'outils de sécurité complexes rend la cybersécurité de plus en plus ardue pour les RSSI.

Secure Code Warrior a développé une GitHub Action qui intègre un apprentissage contextuel au scan de code GitHub. Les développeurs peuvent ainsi utiliser une action tierce, comme Snyk Container Action, pour détecter des vulnérabilités, puis enrichir les résultats avec des ressources pédagogiques hyper-pertinentes et spécifiques aux CWE.

Les tests d'intrusion et les outils d'analyse statique (plus connus sous le nom de SAST) ne constituent qu'une partie du processus global d'atténuation des risques de sécurité. Ils fonctionnent de manière assez indépendante de nos activités, jusqu'à ce que le code nous revienne pour des correctifs urgents, bien entendu !

Un code d'un certain niveau de qualité est par définition sécurisé, mais tout code sécurisé n'est pas nécessairement de bonne qualité. « Commencer avant le début » est-il la formule pour garantir des normes de codage purement sécurisées ?

Le comportement vulnérable sur lequel nous allons nous pencher ici est l'utilisation de code provenant de sources non fiables, une pratique apparemment anodine qui cause de sérieux problèmes.

En 2016, un chercheur en sécurité a découvert une vulnérabilité courante appelée cross-site scripting (XSS) sur le site principal d'Equifax, selon un tweet publié par un chercheur connu sous le pseudonyme de x0rz.

Cette vulnérabilité relève davantage d'un problème humain ou organisationnel, permettant à d'anciennes API de subsister bien après avoir dû être remplacées par des versions plus récentes et sécurisées.

De nombreuses entreprises qui excellent dans leur approche de la cybersécurité ont mis en place un programme officiel de « security champions », confiant des responsabilités clés en matière de sécurité — allant de la liaison entre les équipes et la promotion interne à la supervision des meilleures pratiques — à des personnes faisant preuve d'aptitude et de passion pour ce rôle.

Rust intègre des éléments connus et fonctionnels issus de langages couramment utilisés, tout en adoptant une philosophie différente qui élimine la complexité pour privilégier la performance et la sécurité.

Bien que ce phénomène soit un peu plus fréquent dans les API, les attaquants cherchent souvent à exploiter des failles non corrigées et des fichiers ou répertoires non protégés partout sur un réseau. Tomber sur une API avec le débogage activé ou des fonctions de sécurité désactivées facilite grandement leur tâche malveillante.

Le monde commence à délaisser Waterfall, Agile et désormais DevOps. Quelle est donc la prochaine solution ? Et en tant que développeur, quel est votre rôle pour suivre le rythme de ces changements d'approche ?

En tant qu'industrie, nous ne devrions jamais attendre des développeurs qu'ils deviennent des experts en sécurité, mais les organisations peuvent adopter de nouvelles normes pour les autonomiser afin qu'ils produisent des logiciels de meilleure qualité.

Il arrive que des applications partagent des données avec d'autres programmes dans le cadre d'une charge de travail globale. Si la couche de transport n'est pas protégée, elle devient vulnérable aussi bien à l'espionnage extérieur qu'à la consultation interne non autorisée.

Toutes les organisations peuvent profiter du Mois de la sensibilisation à la cybersécurité pour rafraîchir leurs connaissances en matière de sécurité. Cette année, nous lançons également une nouvelle application gratuite pour la communauté des développeurs !

Une relation bâtie sur les fondations fragiles de la méfiance ne peut, en toute honnêteté, qu'être abordée avec des attentes limitées. Malheureusement, c'est souvent le cas de la relation de travail entre les développeurs et l'équipe de sécurité applicative (AppSec) au sein d'une organisation.

Les erreurs de configuration de sécurité, en particulier celles liées à des autorisations inappropriées, surviennent le plus souvent lorsqu'un développeur crée un nouvel utilisateur ou accorde des droits à une application pour accomplir une tâche.

Les attaquants chercheront toujours en priorité les vulnérabilités faciles à exploiter et peuvent même utiliser des scripts pour passer en revue les faiblesses courantes. C'est un peu comme un voleur qui vérifierait toutes les voitures dans une rue pour voir si une portière est déverrouillée, ce qui est bien plus simple que de briser une vitre.

Face à une pénurie persistante de compétences qui contraste avec le déluge de code produit pour répondre aux besoins logiciels mondiaux, de nombreuses entreprises prennent du retard dans leur stratégie de cybersécurité et leur infrastructure. Il est temps d'évaluer honnêtement notre maturité globale en matière de cybersécurité et d'identifier les gains rapides et viables qui s'offrent à nous.

Les RSSI se retrouvent dans une position de plus en plus délicate : protéger davantage d'actifs, déployer plus de code, réduire une surface d'attaque grandissante, le tout avec des ressources financières en diminution rapide. Il est indéniable que la cybersécurité est perçue comme un centre de coûts. Bien que le programme de sécurité d'une organisation soit le seul rempart contre une cyberattaque qui pourrait faire la une des journaux, les responsables de la sécurité doivent davantage valoriser leur département auprès de la direction, en utilisant un langage compréhensible par les décideurs.

Notre dernier livre blanc, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, est le fruit d'une analyse approfondie d'initiatives réelles de conception sécurisée (Secure-by-Design) en entreprise, permettant d'établir des bonnes pratiques fondées sur des données probantes.

L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de vie du développement logiciel (SDLC). Des outils comme le Trust Score de Secure Code Warrior permettent de mesurer et d'améliorer leurs progrès.

Nos recherches ont démontré que la formation au code sécurisé est efficace. Le Trust Score, qui s'appuie sur un algorithme exploitant plus de 20 millions de points de données issus du travail de plus de 250 000 apprenants au sein de plus de 600 organisations, révèle son efficacité dans la réduction des vulnérabilités et indique comment rendre cette initiative encore plus performante.

Il est notoirement difficile d'obtenir des données pertinentes sur le succès des initiatives « Secure-by-Design ». Les RSSI peinent souvent à démontrer le retour sur investissement (ROI) et la valeur métier des programmes de sécurité, tant au niveau individuel qu'organisationnel. De plus, les entreprises ont beaucoup de mal à se situer par rapport aux normes actuelles du secteur. La stratégie nationale de cybersécurité du président a appelé les parties prenantes à « adopter la sécurité et la résilience dès la conception ». La clé du succès de ces initiatives ne réside pas seulement dans la formation des développeurs au code sécurisé, mais aussi dans la capacité à rassurer les régulateurs. Dans cette présentation, nous partageons une multitude de données qualitatives et quantitatives issues de sources primaires, notamment des données internes collectées auprès de plus de 250 000 développeurs, des retours clients et des études publiques. En exploitant cette agrégation de données, nous proposons une vision de l'état actuel des initiatives « Secure-by-Design » dans divers secteurs. Ce rapport explique pourquoi ce domaine est sous-exploité, l'impact majeur d'un programme de montée en compétences sur la réduction des risques cyber, et le potentiel d'élimination de catégories entières de vulnérabilités.

Le débat sur l'IA ne porte pas sur son usage, mais sur son application. Découvrez comment concilier les gains de productivité liés à l'IA et une sécurité robuste en vous appuyant sur des développeurs qui maîtrisent parfaitement leur code.

Claude Mythos d'Anthropic représente un changement fondamental et permanent dans la manière dont chaque responsable de la sécurité doit aborder son programme de protection, en particulier concernant la gestion des correctifs des systèmes hérités.

Dans ce livre blanc, Matias Madou, Ph.D., expert en sécurité, CTO et cofondateur de Secure Code Warrior, aborde les points suivants : les six piliers nécessaires pour déployer une formation et une autonomisation efficaces en matière de sécurité pour vos équipes de développement. Il partage également les leçons tirées par dix dirigeants ayant mis en œuvre des programmes de sécurité à l'échelle de l'entreprise, ainsi que les pièges courants à éviter pour réussir.