![[#Promo] L’iPad 10 est proposé à seulement 299 euros sur Amazon !](https://static.iphoneaddict.fr/wp-content/uploads/2022/10/iPad-10-2022-Coloris.jpg)
![J'ai vu le futur du solaire à Munich [VLOG]](https://lokan.fr/wp-content/uploads/2025/05/lokan-salon-solaire-munich-1280x853.jpeg)
AppSec : les RSSI se déchargent de l'AppSec, une bonne nouvelle pour les développeurs ? Humm...
Dans près d’une entreprise logicielle sur deux, la responsabilité du suivi de la sécurité n’est plus du ressort de la RSSI. C'est l'étonnante conclusion du rapport A CISO's guide to steering AppSec in the Age of DevSecOps publié par Checkmarx."À mesure que les applications gagnent en complexité et en évolutivité, sous l’effet combiné de l’intelligence artificielle, des micro-services et des architectures hybrides, les équipes d’ingénierie assument une responsabilité croissante dans la livraison de solutions à la fois sécurisées et évolutives. Dans un contexte de cycles de développement toujours plus courts et de lignes de code en constante expansion, les décisions stratégiques en matière d’AppSec, tout comme les budgets qui les accompagnent, sont de plus en plus transférés aux développeurs. Objectif : intégrer la sécurité dès les premières étapes du cycle de développement de manière plus efficace." explique l'annonce du rapport.Le Secure by Design est un débat depuis 30 ans. Oui, il faut que la sécurité se fasse dès la conception et dans le code. Les équipes doivent s'assurer d'un code de qualité, respecter les règles de codage. Rappelons qu'un bug, ou une faille, découvert seulement en production ou en phase finale de développement, coûte cher à corriger car il faut lancer une itération. Plus le problème est identifié tôt, plus il est "rapide" à fixer. Le secure by design, ou l'AppSec au sens large, permet de réduire la surface d'attaque potentielle et réduire l'impact des TOP 10 de l'OWASP. Mais attention, les équipes sécurité, et donc le RSSI, ne doivent pas se décharger du AppSec et de tout faire peser sur les développeurs. Ce serait une erreur. Il ne faut pas oublier que l'AppSec dépasse le rôle du développeur et concerne l'ensemble du cycle de l'application. 49 % des RSSI interrogés déclarent que les acheteurs prennent régulièrement en compte la sécurité des applications dans leurs décisions d'achat.24 % indiquent que la sécurité applicative est toujours un critère déterminant dans ces choix. Cette tendance est particulièrement marquée en Europe, où 58 % des répondants affirment que la sécurité est systématiquement prise en compte, contre 33 % en Asie-Pacifique et seulement 8 % en Amérique du Nord.Il serait temps que la sécurité par défaut soit un critère mais malheureusement, les délais toujours plus serrés nuient à l'AppSec car encore trop souvent, les développeurs doivent travailler dans l'urgence ou avec des spécifications floues ou trop complexes. D'autre part, avec des codes générés par l'IA dont la sécurité et la qualité ne sont pas forcément assurées, on introduit une nouvelle incertitude dans l'AppSec.L'étude de Checkmarx met également en lumière une décentralisation croissante des décisions en matière de sécurité, avec un rôle renforcé des équipes de développement, tant sur le plan opérationnel que budgétaire. Dans les entreprises développant des ogiciels, la responsabilité de la sécurité est désormais partagée :50 % continuent de l’attribuer aux RSSI,43 % la transfèrent aux équipes de développement.56 % des organisations indiquent que la majorité de leurs équipes de développement sont pleinement intégrées aux programmes AppSecOui, il était temps que les développeurs soient pleinement intégrés au AppSec mais, comme nous l'avons dit plus haut, il ne faut pas que le RSSI s'en lave les mains : "ah non, c'est pas moi, c'est lui". « À mesure que la responsabilité de la sécurité se déplace vers les équipes de développement, les budgets suivent la même voie. Les RSSI doivent désormais exercer leur influence non pas en imposant des barrières, mais en définissant un cadre clair : protéger sans freiner l’innovation. » poursuit Jonathan Rende.Pour faire du secure by design, de l'AppSec au niveau du code, il faut sensibiliser, former, établir des règles claires, laisser le temps nécessaire.Si 62 % des RSSI déclarent présenter des indicateurs AppSec à leur conseil d’administration, la majorité d’entre eux se contentent de rapporter le volume de vulnérabilités, sans les relier à des enjeux métier concrets. Seuls 25 % parviennent à établir un lien clair entre ces risques techniques et leurs conséquences sur la réputation de la marque, la conformité réglementaire ou la performance économique. Ce décalage illustre l’urgence, pour les RSSI, de repositionner la sécurité dans une logique de gestion des risques business, condition indispensable pour obtenir un engagement durable de la Direction.Catégorie actualité: SécuritéImage actualité AMP:
Dans près d’une entreprise logicielle sur deux, la responsabilité du suivi de la sécurité n’est plus du ressort de la RSSI. C'est l'étonnante conclusion du rapport A CISO's guide to steering AppSec in the Age of DevSecOps publié par Checkmarx.
"À mesure que les applications gagnent en complexité et en évolutivité, sous l’effet combiné de l’intelligence artificielle, des micro-services et des architectures hybrides, les équipes d’ingénierie assument une responsabilité croissante dans la livraison de solutions à la fois sécurisées et évolutives. Dans un contexte de cycles de développement toujours plus courts et de lignes de code en constante expansion, les décisions stratégiques en matière d’AppSec, tout comme les budgets qui les accompagnent, sont de plus en plus transférés aux développeurs. Objectif : intégrer la sécurité dès les premières étapes du cycle de développement de manière plus efficace." explique l'annonce du rapport.
Le Secure by Design est un débat depuis 30 ans. Oui, il faut que la sécurité se fasse dès la conception et dans le code. Les équipes doivent s'assurer d'un code de qualité, respecter les règles de codage. Rappelons qu'un bug, ou une faille, découvert seulement en production ou en phase finale de développement, coûte cher à corriger car il faut lancer une itération. Plus le problème est identifié tôt, plus il est "rapide" à fixer. Le secure by design, ou l'AppSec au sens large, permet de réduire la surface d'attaque potentielle et réduire l'impact des TOP 10 de l'OWASP.
Mais attention, les équipes sécurité, et donc le RSSI, ne doivent pas se décharger du AppSec et de tout faire peser sur les développeurs. Ce serait une erreur. Il ne faut pas oublier que l'AppSec dépasse le rôle du développeur et concerne l'ensemble du cycle de l'application.
- 49 % des RSSI interrogés déclarent que les acheteurs prennent régulièrement en compte la sécurité des applications dans leurs décisions d'achat.
- 24 % indiquent que la sécurité applicative est toujours un critère déterminant dans ces choix.
- Cette tendance est particulièrement marquée en Europe, où 58 % des répondants affirment que la sécurité est systématiquement prise en compte, contre 33 % en Asie-Pacifique et seulement 8 % en Amérique du Nord.
Il serait temps que la sécurité par défaut soit un critère mais malheureusement, les délais toujours plus serrés nuient à l'AppSec car encore trop souvent, les développeurs doivent travailler dans l'urgence ou avec des spécifications floues ou trop complexes. D'autre part, avec des codes générés par l'IA dont la sécurité et la qualité ne sont pas forcément assurées, on introduit une nouvelle incertitude dans l'AppSec.
L'étude de Checkmarx met également en lumière une décentralisation croissante des décisions en matière de sécurité, avec un rôle renforcé des équipes de développement, tant sur le plan opérationnel que budgétaire. Dans les entreprises développant des ogiciels, la responsabilité de la sécurité est désormais partagée :
- 50 % continuent de l’attribuer aux RSSI,
- 43 % la transfèrent aux équipes de développement.
- 56 % des organisations indiquent que la majorité de leurs équipes de développement sont pleinement intégrées aux programmes AppSec
Oui, il était temps que les développeurs soient pleinement intégrés au AppSec mais, comme nous l'avons dit plus haut, il ne faut pas que le RSSI s'en lave les mains : "ah non, c'est pas moi, c'est lui". « À mesure que la responsabilité de la sécurité se déplace vers les équipes de développement, les budgets suivent la même voie. Les RSSI doivent désormais exercer leur influence non pas en imposant des barrières, mais en définissant un cadre clair : protéger sans freiner l’innovation. » poursuit Jonathan Rende.
Pour faire du secure by design, de l'AppSec au niveau du code, il faut sensibiliser, former, établir des règles claires, laisser le temps nécessaire.
Si 62 % des RSSI déclarent présenter des indicateurs AppSec à leur conseil d’administration, la majorité d’entre eux se contentent de rapporter le volume de vulnérabilités, sans les relier à des enjeux métier concrets. Seuls 25 % parviennent à établir un lien clair entre ces risques techniques et leurs conséquences sur la réputation de la marque, la conformité réglementaire ou la performance économique. Ce décalage illustre l’urgence, pour les RSSI, de repositionner la sécurité dans une logique de gestion des risques business, condition indispensable pour obtenir un engagement durable de la Direction.
