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.

Le gouvernement fédéral américain poursuit les coupes dans les budgets des agences officielles. C'est au tour de l'agence de la sécurité des infrastructures et de la cybersécurité d'être confrontée aux menaces et aux coupes budgétaires. La CISA pourrait perdre 491 millions $.

La CISA est accusé par Trump de contribuer à la censure et d'abandonner sa mission première. La menace est pour le moment de pure forme car le congrès américain doit valider cette réduction qui représente 17 % du budget de fonctionnement de l'agence. Un des reproches concerne la sécurité des élections et le président évoque les résultats de 2020 et la victoire de Biden. La maison blanche veut que la CISA se recentre sur les missions premières et qu'elle se préoccupe plus de censurer que de protéger les intérêts du pays. 

La CISA emploie 3 600 personnes et possède un budget de 3 milliards $. 

L'OWASP propose un top 10 des risques et vulnérabilités sur les LLM et les genIA en général. L'OWASP confirme que l'IA est loin d'être sécurisée, au contraire, les risques de sécurité se multiplient si l'implémentation est mal faite ou l'usage mal cadré. 

1 - injection : le prompt injection est un classique. Un prompt altère le fonctionnement prévu de la genIA et/ du LLM. Et peu à peu on influence son fonctionnement et on amène à générer des données sensibles ou des exemples d'attaque ou des réponses non prévues. Voir : jailbreaking LLM

2 - des données sensibles sont accessibles : trop d'entreprises laissent des données sensibles / privées sur les LLM. Ces données peuvent être accessibles. Il ne faut pas autoriser les LLM / genIA à accéder à ces données sauf dans un cadre strictement interne et déconnecté de l'extérieur

3 - les chaînes LLM constituent un risque et une surface d'attaque potentielle. Risque de corrompre les modèles ou les données, utiliser des API, des services non sécurisés

4 - données et modèles empoisonnés : cela signifie que les données ne sont pas qualifiés ou corrompues. Si ces données ne sont pas bonnes, le LLM sera biaisé et générera de fausses informations et de mauvaises réponses = déviance du modèle. Il faut vérifier l'origine des données et la conformité de celles-ci avec ce que l'on veut générer. Il faut aussi que le LLM soit bien défini et cadré.

5 - La gestion incorrecte des sorties fait spécifiquement référence à une validation et une gestion insuffisantes des sorties générées par le LLM. Et cela peut se propager et corrompre d'autres systèmes

6 - Trop d'agent IA peut nuire à la sécurité et au bon comportement. Avec les agents on peut perdre le contrôle de ce qu'il se passe et favoriser l'hallunication. La qualité médiocre d'un LLM est exploitée. L'agent ou la genIA ne fait pas la différence entre un bon LLM et un mauvais LLM

7 - Fuite au niveau du prompt : il ne faut pas que des identifications, des secrets ou données sensibles se retrouvent dans les réponses du prompt. Il doit "comprendre" ce qui peut être généré ou non. 

8 - Une mauvaise intégration peut être une source de vulnérabilités. Cela peut être accentué en utilisant du RAG.

9 - désinformation : finalement c'est une combinaison des précédents points

10 - consommation illimitée : on n'y pense pas forcément car un déni de services peut impacter un service IA, un genIA en le saturant de prompts qui va alors peser sur l'infrastructure. Cela peut être possible avec des prompts nombreux et longs, des requêtes envoyées en grande quantité dans un délai très court, des API mal limitées pouvant faire exploser les ressources, etc.