Si les outils AppSec sont la solution miracle, pourquoi tant d'entreprises ne les utilisent-elles pas ?
Une version de cet article a été publiée dans Revue SC. Il a été mis à jour et diffusé ici.
L'une des nombreuses énigmes auxquelles sont confrontés les spécialistes de la sécurité d'aujourd'hui est de trouver l'équilibre entre les solutions qu'ils utiliseront pour gérer les cyberrisques auxquels ils sont confrontés. Comment répartir le budget entre les outils et les personnes ? Quelle suite d'outils conviendra le mieux à la technologie existante ? Avec autant d'options, il n'y a pas de réponse facile, et choisir les mauvaises options coûtera du temps et de l'argent plus tard.
Un rapport récent a révélé que le marché des outils de sécurité des applications est en pleine évolution une croissance « explosive » d'ici 2025, une indication claire de leur rôle incontesté dans le succès des pratiques DevSecOps et de leur pertinence croissante pour le secteur face à des volumes croissants de code présentant des failles de sécurité potentielles.
Il y a cependant un problème un peu curieux. Près de la moitié des organisations envoient sciemment du code vulnérable, malgré à l'aide d'une gamme d'outils AppSec conçus pour y mettre fin. Pour les produits dont la demande du marché est indéniable et qui gagnent rapidement du terrain, cela n'a aucun sens. Pourquoi tant de personnes achèteraient-elles des outils de sécurité sophistiqués, pour ignorer leurs découvertes ou ne pas les utiliser du tout ? C'est un peu comme acheter une maison en bord de mer pour dormir dans une tente dans les bois.
Les outils AppSec ne sont pas utilisés comme on aurait pu s'y attendre pour plusieurs raisons. Il s'agit moins des outils et de leurs fonctionnalités que de la manière dont ils s'intègrent à un programme de sécurité dans son ensemble.
Plus d'outils ne signifie pas moins de problèmes.
Au fur et à mesure que les entreprises font évoluer leurs processus de développement logiciel, passant d'Agile à DevOps, en passant par le nirvana sacré qu'est DevSecOps (bon, pour l'instant, c'est le meilleur que nous ayons), il est inévitable que plusieurs scanners, écrans, pare-feux et toutes sortes d'outils AppSec soient achetés en cours de route. Bien que cela puisse sembler être une question de « plus en plus, mieux c'est », cela conduit très souvent à une technologie qui ressemble au monstre de Frankenstein, avec toute l'imprévisibilité que cela implique.
Les budgets et les ressources d'experts étant de plus en plus limités par rapport à l'étendue des travaux requis, essayer de résoudre le problème et de trouver la meilleure solution d'outillage est une tâche ardue, et le code à scanner et à corriger ne cesse d'arriver. Il n'est pas étonnant que de nombreuses organisations aient dû conserver le code d'expédition, même si cela est plutôt alarmant, et cela représente toujours un risque immense pour nos données et notre confidentialité.
Les outils de numérisation sont lents, ce qui a un impact sur l'agilité des versions.
La mise en place d'une sécurité rapide est un véritable casse-tête en matière de développement logiciel, et à vrai dire, nous essayons toujours de faire les choses correctement alors même que nous incitons les organisations à adopter une approche axée sur DevSecOps. Une révision manuelle méticuleuse du code aurait pu constituer la solution de sécurité dans les années 90, mais à une époque où nous produisons des centaines de milliards de lignes de code, c'est un plan à peu près aussi efficace que la préparation d'un terrain de football avec une paire de ciseaux à ongles.
Les outils de numérisation automatisent le processus de détection des problèmes potentiels, en effectuant pour nous cette partie méticuleuse de la révision du code. Le problème est qu'ils sont encore lents dans le contexte d'un pipeline CI/CD fonctionnant à plein régime, et aucun outil ne détecte toutes les vulnérabilités. Les résultats transmis à l'équipe de sécurité à la suite d'un scan présentent également quelques problèmes flagrants :
- Il existe un lot de faux positifs (et négatifs)
- Un mauvais expert en sécurité doit encore rester là et faire une révision manuelle pour trier les vrais bogues des bogues fantômes
- Bien souvent, trop de vulnérabilités courantes sont révélées et auraient dû être détectées avant le déploiement du code. Voulez-vous vraiment que vos experts en sécurité, très onéreux, ne se préoccupent pas des gros problèmes de sécurité liés aux petites choses ?
- Les scanners trouvent, ils ne réparent pas.
Même dans une organisation qui fait de son mieux pour appliquer les meilleures pratiques en matière de cybersécurité et qui évolue avec le temps pour inclure la sécurité à chaque étape du processus, le processus ci-dessus reste un obstacle si les scanners constituent la principale mesure de protection et si trop de bogues courants obligent l'équipe à déployer un code sécurisé. Il va de soi que l'on peut faire des économies dans ce domaine, et cela se traduit généralement par le recours au strict minimum d'outils qui ne peuvent pas couvrir tous les risques potentiels, même si une suite de solutions a été achetée.
Une certaine automatisation technologique peut entraîner une diminution de la qualité du code
L'analyse et les tests supportent la charge des processus automatisés des outils AppSec, ainsi que des éléments essentiels tels que les pare-feux et la surveillance, mais d'autres outils courants peuvent par inadvertance éroder les bases pratiques de sécurité au fil du temps.
Par exemple, la technologie RASP (Runtime Application Self-Protection) est souvent utilisée pour renforcer la posture de sécurité sans sacrifier la vitesse de codage. Il fonctionne dans l'environnement d'exécution d'une application, protégeant contre la saisie de code malveillant, les attaques en temps réel et signalant tout comportement d'exécution étrange.
Il s'agit certainement d'une couche de protection supplémentaire, mais si elle est considérée comme une protection intégrée contre les éventuelles faiblesses de la base de code, les développeurs peuvent faire preuve de complaisance, en particulier lorsqu'ils sont confrontés à des délais de mise sur le marché de plus en plus impossibles à atteindre pour proposer de nouvelles fonctionnalités. Les pratiques de codage sécurisé peuvent ne pas être suivies, en partant du principe que l'autoprotection lors de l'exécution détectera les erreurs. Les développeurs ne font pas tout leur possible pour créer des modèles de codage non sécurisés, mais la sécurité est souvent reléguée au second plan au profit de la fourniture de fonctionnalités, en particulier dans l'hypothèse d'une sauvegarde automatisée.
Les outils peuvent échouer (et dans le cas de RASP, ils sont souvent exécutés en mode surveillance pour éviter les faux positifs, ce qui ne fait que fournir de la visibilité, et non une protection, contre une attaque), et lorsque cela se produit, il s'agit d'un code sécurisé de haute qualité sur lequel on peut se fier à chaque fois. La sensibilisation à la sécurité dans tous les rôles qui concernent le code est fondamentale pour DevSecOps, et les développeurs ne pas suivre de formation ou ne pas produire de code sécurisé sont une erreur. Le code sécurisé et le code non sécurisé demandent le même effort d'écriture ; c'est l'acquisition des connaissances nécessaires pour coder en toute sécurité qui demande de l'énergie. Le temps passé à implémenter et à optimiser RASP peut être bien mieux utilisé pour améliorer les compétences des développeurs afin qu'ils ne commettent pas d'erreur au départ.
Trouver l'équilibre entre les outils et les personnes : ce n'est pas une solution miracle, mais c'est ce que nous avons de plus proche (pour l'instant).
La philosophie principale de DevSecOps est de faire de la sécurité une responsabilité partagée, et pour les organisations qui créent les logiciels qui alimentent nos vies, qu'il s'agisse du réseau électrique ou de nos sonnettes, elles doivent impliquer tout le monde dans le processus afin de garantir un niveau de sécurité plus élevé.
Les outils ne suffiront pas à tout, et ce n'est même pas le moyen le moins cher. Les meilleurs résultats sont de loin obtenus en donnant la priorité à une formation à la sécurité pertinente pour tous ceux qui ont accès au code, en travaillant activement pour que la sécurité soit au cœur des préoccupations de l'équipe de développement et en développant une culture de sécurité positive dirigée par l'homme, avec une suite d'outils qui joue un rôle de soutien.
Malgré les contraintes de temps, les contraintes de coûts et d'autres facteurs qui empêchent les experts en sécurité de dormir la nuit, si les développeurs n'introduisent pas de failles de sécurité courantes dès le départ, ces outils (qu'ils soient utilisés ou non) représentent un facteur de risque bien moindre.
Les outils AppSec ne sont pas utilisés comme on aurait pu s'y attendre pour plusieurs raisons. Il s'agit moins des outils et de leurs fonctionnalités que de la manière dont ils s'intègrent à un programme de sécurité dans son ensemble.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Une version de cet article a été publiée dans Revue SC. Il a été mis à jour et diffusé ici.
L'une des nombreuses énigmes auxquelles sont confrontés les spécialistes de la sécurité d'aujourd'hui est de trouver l'équilibre entre les solutions qu'ils utiliseront pour gérer les cyberrisques auxquels ils sont confrontés. Comment répartir le budget entre les outils et les personnes ? Quelle suite d'outils conviendra le mieux à la technologie existante ? Avec autant d'options, il n'y a pas de réponse facile, et choisir les mauvaises options coûtera du temps et de l'argent plus tard.
Un rapport récent a révélé que le marché des outils de sécurité des applications est en pleine évolution une croissance « explosive » d'ici 2025, une indication claire de leur rôle incontesté dans le succès des pratiques DevSecOps et de leur pertinence croissante pour le secteur face à des volumes croissants de code présentant des failles de sécurité potentielles.
Il y a cependant un problème un peu curieux. Près de la moitié des organisations envoient sciemment du code vulnérable, malgré à l'aide d'une gamme d'outils AppSec conçus pour y mettre fin. Pour les produits dont la demande du marché est indéniable et qui gagnent rapidement du terrain, cela n'a aucun sens. Pourquoi tant de personnes achèteraient-elles des outils de sécurité sophistiqués, pour ignorer leurs découvertes ou ne pas les utiliser du tout ? C'est un peu comme acheter une maison en bord de mer pour dormir dans une tente dans les bois.
Les outils AppSec ne sont pas utilisés comme on aurait pu s'y attendre pour plusieurs raisons. Il s'agit moins des outils et de leurs fonctionnalités que de la manière dont ils s'intègrent à un programme de sécurité dans son ensemble.
Plus d'outils ne signifie pas moins de problèmes.
Au fur et à mesure que les entreprises font évoluer leurs processus de développement logiciel, passant d'Agile à DevOps, en passant par le nirvana sacré qu'est DevSecOps (bon, pour l'instant, c'est le meilleur que nous ayons), il est inévitable que plusieurs scanners, écrans, pare-feux et toutes sortes d'outils AppSec soient achetés en cours de route. Bien que cela puisse sembler être une question de « plus en plus, mieux c'est », cela conduit très souvent à une technologie qui ressemble au monstre de Frankenstein, avec toute l'imprévisibilité que cela implique.
Les budgets et les ressources d'experts étant de plus en plus limités par rapport à l'étendue des travaux requis, essayer de résoudre le problème et de trouver la meilleure solution d'outillage est une tâche ardue, et le code à scanner et à corriger ne cesse d'arriver. Il n'est pas étonnant que de nombreuses organisations aient dû conserver le code d'expédition, même si cela est plutôt alarmant, et cela représente toujours un risque immense pour nos données et notre confidentialité.
Les outils de numérisation sont lents, ce qui a un impact sur l'agilité des versions.
La mise en place d'une sécurité rapide est un véritable casse-tête en matière de développement logiciel, et à vrai dire, nous essayons toujours de faire les choses correctement alors même que nous incitons les organisations à adopter une approche axée sur DevSecOps. Une révision manuelle méticuleuse du code aurait pu constituer la solution de sécurité dans les années 90, mais à une époque où nous produisons des centaines de milliards de lignes de code, c'est un plan à peu près aussi efficace que la préparation d'un terrain de football avec une paire de ciseaux à ongles.
Les outils de numérisation automatisent le processus de détection des problèmes potentiels, en effectuant pour nous cette partie méticuleuse de la révision du code. Le problème est qu'ils sont encore lents dans le contexte d'un pipeline CI/CD fonctionnant à plein régime, et aucun outil ne détecte toutes les vulnérabilités. Les résultats transmis à l'équipe de sécurité à la suite d'un scan présentent également quelques problèmes flagrants :
- Il existe un lot de faux positifs (et négatifs)
- Un mauvais expert en sécurité doit encore rester là et faire une révision manuelle pour trier les vrais bogues des bogues fantômes
- Bien souvent, trop de vulnérabilités courantes sont révélées et auraient dû être détectées avant le déploiement du code. Voulez-vous vraiment que vos experts en sécurité, très onéreux, ne se préoccupent pas des gros problèmes de sécurité liés aux petites choses ?
- Les scanners trouvent, ils ne réparent pas.
Même dans une organisation qui fait de son mieux pour appliquer les meilleures pratiques en matière de cybersécurité et qui évolue avec le temps pour inclure la sécurité à chaque étape du processus, le processus ci-dessus reste un obstacle si les scanners constituent la principale mesure de protection et si trop de bogues courants obligent l'équipe à déployer un code sécurisé. Il va de soi que l'on peut faire des économies dans ce domaine, et cela se traduit généralement par le recours au strict minimum d'outils qui ne peuvent pas couvrir tous les risques potentiels, même si une suite de solutions a été achetée.
Une certaine automatisation technologique peut entraîner une diminution de la qualité du code
L'analyse et les tests supportent la charge des processus automatisés des outils AppSec, ainsi que des éléments essentiels tels que les pare-feux et la surveillance, mais d'autres outils courants peuvent par inadvertance éroder les bases pratiques de sécurité au fil du temps.
Par exemple, la technologie RASP (Runtime Application Self-Protection) est souvent utilisée pour renforcer la posture de sécurité sans sacrifier la vitesse de codage. Il fonctionne dans l'environnement d'exécution d'une application, protégeant contre la saisie de code malveillant, les attaques en temps réel et signalant tout comportement d'exécution étrange.
Il s'agit certainement d'une couche de protection supplémentaire, mais si elle est considérée comme une protection intégrée contre les éventuelles faiblesses de la base de code, les développeurs peuvent faire preuve de complaisance, en particulier lorsqu'ils sont confrontés à des délais de mise sur le marché de plus en plus impossibles à atteindre pour proposer de nouvelles fonctionnalités. Les pratiques de codage sécurisé peuvent ne pas être suivies, en partant du principe que l'autoprotection lors de l'exécution détectera les erreurs. Les développeurs ne font pas tout leur possible pour créer des modèles de codage non sécurisés, mais la sécurité est souvent reléguée au second plan au profit de la fourniture de fonctionnalités, en particulier dans l'hypothèse d'une sauvegarde automatisée.
Les outils peuvent échouer (et dans le cas de RASP, ils sont souvent exécutés en mode surveillance pour éviter les faux positifs, ce qui ne fait que fournir de la visibilité, et non une protection, contre une attaque), et lorsque cela se produit, il s'agit d'un code sécurisé de haute qualité sur lequel on peut se fier à chaque fois. La sensibilisation à la sécurité dans tous les rôles qui concernent le code est fondamentale pour DevSecOps, et les développeurs ne pas suivre de formation ou ne pas produire de code sécurisé sont une erreur. Le code sécurisé et le code non sécurisé demandent le même effort d'écriture ; c'est l'acquisition des connaissances nécessaires pour coder en toute sécurité qui demande de l'énergie. Le temps passé à implémenter et à optimiser RASP peut être bien mieux utilisé pour améliorer les compétences des développeurs afin qu'ils ne commettent pas d'erreur au départ.
Trouver l'équilibre entre les outils et les personnes : ce n'est pas une solution miracle, mais c'est ce que nous avons de plus proche (pour l'instant).
La philosophie principale de DevSecOps est de faire de la sécurité une responsabilité partagée, et pour les organisations qui créent les logiciels qui alimentent nos vies, qu'il s'agisse du réseau électrique ou de nos sonnettes, elles doivent impliquer tout le monde dans le processus afin de garantir un niveau de sécurité plus élevé.
Les outils ne suffiront pas à tout, et ce n'est même pas le moyen le moins cher. Les meilleurs résultats sont de loin obtenus en donnant la priorité à une formation à la sécurité pertinente pour tous ceux qui ont accès au code, en travaillant activement pour que la sécurité soit au cœur des préoccupations de l'équipe de développement et en développant une culture de sécurité positive dirigée par l'homme, avec une suite d'outils qui joue un rôle de soutien.
Malgré les contraintes de temps, les contraintes de coûts et d'autres facteurs qui empêchent les experts en sécurité de dormir la nuit, si les développeurs n'introduisent pas de failles de sécurité courantes dès le départ, ces outils (qu'ils soient utilisés ou non) représentent un facteur de risque bien moindre.
Une version de cet article a été publiée dans Revue SC. Il a été mis à jour et diffusé ici.
L'une des nombreuses énigmes auxquelles sont confrontés les spécialistes de la sécurité d'aujourd'hui est de trouver l'équilibre entre les solutions qu'ils utiliseront pour gérer les cyberrisques auxquels ils sont confrontés. Comment répartir le budget entre les outils et les personnes ? Quelle suite d'outils conviendra le mieux à la technologie existante ? Avec autant d'options, il n'y a pas de réponse facile, et choisir les mauvaises options coûtera du temps et de l'argent plus tard.
Un rapport récent a révélé que le marché des outils de sécurité des applications est en pleine évolution une croissance « explosive » d'ici 2025, une indication claire de leur rôle incontesté dans le succès des pratiques DevSecOps et de leur pertinence croissante pour le secteur face à des volumes croissants de code présentant des failles de sécurité potentielles.
Il y a cependant un problème un peu curieux. Près de la moitié des organisations envoient sciemment du code vulnérable, malgré à l'aide d'une gamme d'outils AppSec conçus pour y mettre fin. Pour les produits dont la demande du marché est indéniable et qui gagnent rapidement du terrain, cela n'a aucun sens. Pourquoi tant de personnes achèteraient-elles des outils de sécurité sophistiqués, pour ignorer leurs découvertes ou ne pas les utiliser du tout ? C'est un peu comme acheter une maison en bord de mer pour dormir dans une tente dans les bois.
Les outils AppSec ne sont pas utilisés comme on aurait pu s'y attendre pour plusieurs raisons. Il s'agit moins des outils et de leurs fonctionnalités que de la manière dont ils s'intègrent à un programme de sécurité dans son ensemble.
Plus d'outils ne signifie pas moins de problèmes.
Au fur et à mesure que les entreprises font évoluer leurs processus de développement logiciel, passant d'Agile à DevOps, en passant par le nirvana sacré qu'est DevSecOps (bon, pour l'instant, c'est le meilleur que nous ayons), il est inévitable que plusieurs scanners, écrans, pare-feux et toutes sortes d'outils AppSec soient achetés en cours de route. Bien que cela puisse sembler être une question de « plus en plus, mieux c'est », cela conduit très souvent à une technologie qui ressemble au monstre de Frankenstein, avec toute l'imprévisibilité que cela implique.
Les budgets et les ressources d'experts étant de plus en plus limités par rapport à l'étendue des travaux requis, essayer de résoudre le problème et de trouver la meilleure solution d'outillage est une tâche ardue, et le code à scanner et à corriger ne cesse d'arriver. Il n'est pas étonnant que de nombreuses organisations aient dû conserver le code d'expédition, même si cela est plutôt alarmant, et cela représente toujours un risque immense pour nos données et notre confidentialité.
Les outils de numérisation sont lents, ce qui a un impact sur l'agilité des versions.
La mise en place d'une sécurité rapide est un véritable casse-tête en matière de développement logiciel, et à vrai dire, nous essayons toujours de faire les choses correctement alors même que nous incitons les organisations à adopter une approche axée sur DevSecOps. Une révision manuelle méticuleuse du code aurait pu constituer la solution de sécurité dans les années 90, mais à une époque où nous produisons des centaines de milliards de lignes de code, c'est un plan à peu près aussi efficace que la préparation d'un terrain de football avec une paire de ciseaux à ongles.
Les outils de numérisation automatisent le processus de détection des problèmes potentiels, en effectuant pour nous cette partie méticuleuse de la révision du code. Le problème est qu'ils sont encore lents dans le contexte d'un pipeline CI/CD fonctionnant à plein régime, et aucun outil ne détecte toutes les vulnérabilités. Les résultats transmis à l'équipe de sécurité à la suite d'un scan présentent également quelques problèmes flagrants :
- Il existe un lot de faux positifs (et négatifs)
- Un mauvais expert en sécurité doit encore rester là et faire une révision manuelle pour trier les vrais bogues des bogues fantômes
- Bien souvent, trop de vulnérabilités courantes sont révélées et auraient dû être détectées avant le déploiement du code. Voulez-vous vraiment que vos experts en sécurité, très onéreux, ne se préoccupent pas des gros problèmes de sécurité liés aux petites choses ?
- Les scanners trouvent, ils ne réparent pas.
Même dans une organisation qui fait de son mieux pour appliquer les meilleures pratiques en matière de cybersécurité et qui évolue avec le temps pour inclure la sécurité à chaque étape du processus, le processus ci-dessus reste un obstacle si les scanners constituent la principale mesure de protection et si trop de bogues courants obligent l'équipe à déployer un code sécurisé. Il va de soi que l'on peut faire des économies dans ce domaine, et cela se traduit généralement par le recours au strict minimum d'outils qui ne peuvent pas couvrir tous les risques potentiels, même si une suite de solutions a été achetée.
Une certaine automatisation technologique peut entraîner une diminution de la qualité du code
L'analyse et les tests supportent la charge des processus automatisés des outils AppSec, ainsi que des éléments essentiels tels que les pare-feux et la surveillance, mais d'autres outils courants peuvent par inadvertance éroder les bases pratiques de sécurité au fil du temps.
Par exemple, la technologie RASP (Runtime Application Self-Protection) est souvent utilisée pour renforcer la posture de sécurité sans sacrifier la vitesse de codage. Il fonctionne dans l'environnement d'exécution d'une application, protégeant contre la saisie de code malveillant, les attaques en temps réel et signalant tout comportement d'exécution étrange.
Il s'agit certainement d'une couche de protection supplémentaire, mais si elle est considérée comme une protection intégrée contre les éventuelles faiblesses de la base de code, les développeurs peuvent faire preuve de complaisance, en particulier lorsqu'ils sont confrontés à des délais de mise sur le marché de plus en plus impossibles à atteindre pour proposer de nouvelles fonctionnalités. Les pratiques de codage sécurisé peuvent ne pas être suivies, en partant du principe que l'autoprotection lors de l'exécution détectera les erreurs. Les développeurs ne font pas tout leur possible pour créer des modèles de codage non sécurisés, mais la sécurité est souvent reléguée au second plan au profit de la fourniture de fonctionnalités, en particulier dans l'hypothèse d'une sauvegarde automatisée.
Les outils peuvent échouer (et dans le cas de RASP, ils sont souvent exécutés en mode surveillance pour éviter les faux positifs, ce qui ne fait que fournir de la visibilité, et non une protection, contre une attaque), et lorsque cela se produit, il s'agit d'un code sécurisé de haute qualité sur lequel on peut se fier à chaque fois. La sensibilisation à la sécurité dans tous les rôles qui concernent le code est fondamentale pour DevSecOps, et les développeurs ne pas suivre de formation ou ne pas produire de code sécurisé sont une erreur. Le code sécurisé et le code non sécurisé demandent le même effort d'écriture ; c'est l'acquisition des connaissances nécessaires pour coder en toute sécurité qui demande de l'énergie. Le temps passé à implémenter et à optimiser RASP peut être bien mieux utilisé pour améliorer les compétences des développeurs afin qu'ils ne commettent pas d'erreur au départ.
Trouver l'équilibre entre les outils et les personnes : ce n'est pas une solution miracle, mais c'est ce que nous avons de plus proche (pour l'instant).
La philosophie principale de DevSecOps est de faire de la sécurité une responsabilité partagée, et pour les organisations qui créent les logiciels qui alimentent nos vies, qu'il s'agisse du réseau électrique ou de nos sonnettes, elles doivent impliquer tout le monde dans le processus afin de garantir un niveau de sécurité plus élevé.
Les outils ne suffiront pas à tout, et ce n'est même pas le moyen le moins cher. Les meilleurs résultats sont de loin obtenus en donnant la priorité à une formation à la sécurité pertinente pour tous ceux qui ont accès au code, en travaillant activement pour que la sécurité soit au cœur des préoccupations de l'équipe de développement et en développant une culture de sécurité positive dirigée par l'homme, avec une suite d'outils qui joue un rôle de soutien.
Malgré les contraintes de temps, les contraintes de coûts et d'autres facteurs qui empêchent les experts en sécurité de dormir la nuit, si les développeurs n'introduisent pas de failles de sécurité courantes dès le départ, ces outils (qu'ils soient utilisés ou non) représentent un facteur de risque bien moindre.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Afficher le rapportRéservez une démo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Une version de cet article a été publiée dans Revue SC. Il a été mis à jour et diffusé ici.
L'une des nombreuses énigmes auxquelles sont confrontés les spécialistes de la sécurité d'aujourd'hui est de trouver l'équilibre entre les solutions qu'ils utiliseront pour gérer les cyberrisques auxquels ils sont confrontés. Comment répartir le budget entre les outils et les personnes ? Quelle suite d'outils conviendra le mieux à la technologie existante ? Avec autant d'options, il n'y a pas de réponse facile, et choisir les mauvaises options coûtera du temps et de l'argent plus tard.
Un rapport récent a révélé que le marché des outils de sécurité des applications est en pleine évolution une croissance « explosive » d'ici 2025, une indication claire de leur rôle incontesté dans le succès des pratiques DevSecOps et de leur pertinence croissante pour le secteur face à des volumes croissants de code présentant des failles de sécurité potentielles.
Il y a cependant un problème un peu curieux. Près de la moitié des organisations envoient sciemment du code vulnérable, malgré à l'aide d'une gamme d'outils AppSec conçus pour y mettre fin. Pour les produits dont la demande du marché est indéniable et qui gagnent rapidement du terrain, cela n'a aucun sens. Pourquoi tant de personnes achèteraient-elles des outils de sécurité sophistiqués, pour ignorer leurs découvertes ou ne pas les utiliser du tout ? C'est un peu comme acheter une maison en bord de mer pour dormir dans une tente dans les bois.
Les outils AppSec ne sont pas utilisés comme on aurait pu s'y attendre pour plusieurs raisons. Il s'agit moins des outils et de leurs fonctionnalités que de la manière dont ils s'intègrent à un programme de sécurité dans son ensemble.
Plus d'outils ne signifie pas moins de problèmes.
Au fur et à mesure que les entreprises font évoluer leurs processus de développement logiciel, passant d'Agile à DevOps, en passant par le nirvana sacré qu'est DevSecOps (bon, pour l'instant, c'est le meilleur que nous ayons), il est inévitable que plusieurs scanners, écrans, pare-feux et toutes sortes d'outils AppSec soient achetés en cours de route. Bien que cela puisse sembler être une question de « plus en plus, mieux c'est », cela conduit très souvent à une technologie qui ressemble au monstre de Frankenstein, avec toute l'imprévisibilité que cela implique.
Les budgets et les ressources d'experts étant de plus en plus limités par rapport à l'étendue des travaux requis, essayer de résoudre le problème et de trouver la meilleure solution d'outillage est une tâche ardue, et le code à scanner et à corriger ne cesse d'arriver. Il n'est pas étonnant que de nombreuses organisations aient dû conserver le code d'expédition, même si cela est plutôt alarmant, et cela représente toujours un risque immense pour nos données et notre confidentialité.
Les outils de numérisation sont lents, ce qui a un impact sur l'agilité des versions.
La mise en place d'une sécurité rapide est un véritable casse-tête en matière de développement logiciel, et à vrai dire, nous essayons toujours de faire les choses correctement alors même que nous incitons les organisations à adopter une approche axée sur DevSecOps. Une révision manuelle méticuleuse du code aurait pu constituer la solution de sécurité dans les années 90, mais à une époque où nous produisons des centaines de milliards de lignes de code, c'est un plan à peu près aussi efficace que la préparation d'un terrain de football avec une paire de ciseaux à ongles.
Les outils de numérisation automatisent le processus de détection des problèmes potentiels, en effectuant pour nous cette partie méticuleuse de la révision du code. Le problème est qu'ils sont encore lents dans le contexte d'un pipeline CI/CD fonctionnant à plein régime, et aucun outil ne détecte toutes les vulnérabilités. Les résultats transmis à l'équipe de sécurité à la suite d'un scan présentent également quelques problèmes flagrants :
- Il existe un lot de faux positifs (et négatifs)
- Un mauvais expert en sécurité doit encore rester là et faire une révision manuelle pour trier les vrais bogues des bogues fantômes
- Bien souvent, trop de vulnérabilités courantes sont révélées et auraient dû être détectées avant le déploiement du code. Voulez-vous vraiment que vos experts en sécurité, très onéreux, ne se préoccupent pas des gros problèmes de sécurité liés aux petites choses ?
- Les scanners trouvent, ils ne réparent pas.
Même dans une organisation qui fait de son mieux pour appliquer les meilleures pratiques en matière de cybersécurité et qui évolue avec le temps pour inclure la sécurité à chaque étape du processus, le processus ci-dessus reste un obstacle si les scanners constituent la principale mesure de protection et si trop de bogues courants obligent l'équipe à déployer un code sécurisé. Il va de soi que l'on peut faire des économies dans ce domaine, et cela se traduit généralement par le recours au strict minimum d'outils qui ne peuvent pas couvrir tous les risques potentiels, même si une suite de solutions a été achetée.
Une certaine automatisation technologique peut entraîner une diminution de la qualité du code
L'analyse et les tests supportent la charge des processus automatisés des outils AppSec, ainsi que des éléments essentiels tels que les pare-feux et la surveillance, mais d'autres outils courants peuvent par inadvertance éroder les bases pratiques de sécurité au fil du temps.
Par exemple, la technologie RASP (Runtime Application Self-Protection) est souvent utilisée pour renforcer la posture de sécurité sans sacrifier la vitesse de codage. Il fonctionne dans l'environnement d'exécution d'une application, protégeant contre la saisie de code malveillant, les attaques en temps réel et signalant tout comportement d'exécution étrange.
Il s'agit certainement d'une couche de protection supplémentaire, mais si elle est considérée comme une protection intégrée contre les éventuelles faiblesses de la base de code, les développeurs peuvent faire preuve de complaisance, en particulier lorsqu'ils sont confrontés à des délais de mise sur le marché de plus en plus impossibles à atteindre pour proposer de nouvelles fonctionnalités. Les pratiques de codage sécurisé peuvent ne pas être suivies, en partant du principe que l'autoprotection lors de l'exécution détectera les erreurs. Les développeurs ne font pas tout leur possible pour créer des modèles de codage non sécurisés, mais la sécurité est souvent reléguée au second plan au profit de la fourniture de fonctionnalités, en particulier dans l'hypothèse d'une sauvegarde automatisée.
Les outils peuvent échouer (et dans le cas de RASP, ils sont souvent exécutés en mode surveillance pour éviter les faux positifs, ce qui ne fait que fournir de la visibilité, et non une protection, contre une attaque), et lorsque cela se produit, il s'agit d'un code sécurisé de haute qualité sur lequel on peut se fier à chaque fois. La sensibilisation à la sécurité dans tous les rôles qui concernent le code est fondamentale pour DevSecOps, et les développeurs ne pas suivre de formation ou ne pas produire de code sécurisé sont une erreur. Le code sécurisé et le code non sécurisé demandent le même effort d'écriture ; c'est l'acquisition des connaissances nécessaires pour coder en toute sécurité qui demande de l'énergie. Le temps passé à implémenter et à optimiser RASP peut être bien mieux utilisé pour améliorer les compétences des développeurs afin qu'ils ne commettent pas d'erreur au départ.
Trouver l'équilibre entre les outils et les personnes : ce n'est pas une solution miracle, mais c'est ce que nous avons de plus proche (pour l'instant).
La philosophie principale de DevSecOps est de faire de la sécurité une responsabilité partagée, et pour les organisations qui créent les logiciels qui alimentent nos vies, qu'il s'agisse du réseau électrique ou de nos sonnettes, elles doivent impliquer tout le monde dans le processus afin de garantir un niveau de sécurité plus élevé.
Les outils ne suffiront pas à tout, et ce n'est même pas le moyen le moins cher. Les meilleurs résultats sont de loin obtenus en donnant la priorité à une formation à la sécurité pertinente pour tous ceux qui ont accès au code, en travaillant activement pour que la sécurité soit au cœur des préoccupations de l'équipe de développement et en développant une culture de sécurité positive dirigée par l'homme, avec une suite d'outils qui joue un rôle de soutien.
Malgré les contraintes de temps, les contraintes de coûts et d'autres facteurs qui empêchent les experts en sécurité de dormir la nuit, si les développeurs n'introduisent pas de failles de sécurité courantes dès le départ, ces outils (qu'ils soient utilisés ou non) représentent un facteur de risque bien moindre.
Table des matières
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démoTéléchargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
