La plupart des RSSI estiment avoir une compréhension raisonnable de l’empreinte no-code de leur organisation. Ils savent que les employés créent de petites automatisations pour rationaliser les tâches. Ils supposent que quelques dizaines ou quelques centaines de flux de travail s’exécutent silencieusement dans l’entreprise. Mais lorsque les équipes de sécurité acquièrent enfin une réelle visibilité, une réalité différente apparaît.
Une entreprise mondiale s’attendait à trouver quelques centaines de flux de travail pour les utilisateurs professionnels. Le nombre réel était supérieur à 3 000. Un autre a découvert qu’un seul employé financier, sans formation d’ingénieur, avait créé plus de 150 automatisations. Un autre encore a découvert un flux de travail transférant silencieusement les e-mails professionnels d’un employé vers un compte Gmail personnel. Aucun d’entre eux n’a été enregistré, inspecté pour détecter les risques de sécurité ou surveillé.
Ce ne sont pas des anecdotes ; ce sont les symptômes d’un changement structurel. Les entreprises sont désormais de plus en plus exposées à une infrastructure fantôme, invisible, non gérée et non protégée.
La surface d’attaque cachée sans code
Les programmes AppSec traditionnels sont optimisés pour le code stocké dans des référentiels, transmis via des pipelines et déployé via CI/CD, et non pour les applications, connecteurs et automatisations sans code créés sur des plateformes telles que Power Platform, ServiceNow, Salesforce et UiPath.
Pendant ce temps, la plupart des organisations supposent que les automatisations destinées aux utilisateurs professionnels sont simples, à faible risque et de portée limitée. La réalité est plus complexe. Les développeurs citoyens sont désormais bien plus nombreux que les développeurs de logiciels traditionnels. De plus, ils connectent des sources de données ensemble, déclenchent des flux de travail multi-systèmes et appellent des API, et ne se contentent pas de créer des macros de base ou des utilitaires départementaux.
Étant donné que ces automatisations sont créées en dehors de la gouvernance de l’ingénierie, les outils de surveillance traditionnels ne les voient jamais. Ils ne passent pas par les révisions du code de sécurité, ne subissent pas de modélisation des menaces et ne génèrent pas les types de journaux attendus par les SIEM. Pourtant, ils effectuent des actions qui impactent directement les données de production et les processus métiers.
Cet angle mort se traduit souvent par des informations d’identification directement intégrées aux flux de travail. Il peut également créer une exposition SQL et OData dans des outils tels que Microsoft Power BI, des automatisations qui relient les environnements censés rester isolés et des données sensibles exposées en externe. Dans le pire des cas, les agents IA peuvent accéder à des tables de base de données entières car une option de configuration par défaut n’a jamais été modifiée.
Aucun de ces risques de sécurité ne représente une intention malveillante. Ils sont la conséquence inévitable d’un système optimisé pour la commodité plutôt que pour la surveillance.
Les workflows sans code deviennent du Shadow IT
Une fois que la sécurité prend conscience de l’ampleur du développement sans code, un problème plus profond apparaît : la propriété.
De nombreux workflows sans code sont liés à des comptes de service génériques, chacun comportant des centaines d’automatisations. D’autres appartiennent à d’anciens salariés. Les écarts de propriété persistent parce que les unités commerciales se construisent de manière indépendante, que l’informatique provisionne l’accès sans gouverner la logique ou les flux de données, et que la sécurité n’a de visibilité que sur les actifs qui touchent leurs outils.
Les agents IA amplifient ce problème. Lorsque les employés peuvent décrire un objectif en langage naturel, « résumer les transactions », « acheminer les exceptions », « extraire les enregistrements des clients » et que la plateforme génère automatiquement le flux de travail, la paternité devient abstraite. Un flux de travail généré par l’IA peut être répété sans propriété claire au fil du temps. La question « À qui appartient cela ? » devient matériellement plus difficile de répondre.
Ces lacunes en matière de propriété rendent la réponse aux incidents presque impossible. Si un flux de travail commence à exfiltrer des données ou si un connecteur élève soudainement ses privilèges, les équipes de sécurité ne savent pas qui comprend la logique, qui a fait les choix de conception ou si le comportement est attendu. Le seul recours consiste à désactiver complètement les flux de travail, perturbant ainsi les processus critiques en cours de route.
Pourquoi les outils AppSec manquent le risque sans code
Une fois qu’elles ont reconnu ce problème, la plupart des organisations se tournent vers les outils AppSec familiers, SAST, DAST, IAST, les tests d’intrusion et les révisions de politiques. Ces approches échouent souvent car les automatisations sans code produisent rarement du code que les scanners peuvent analyser ou exécuter dans des environnements dans lesquels les scanners peuvent s’exécuter en toute sécurité :
- Les journaux sont incohérents ou manquants.
- La traçabilité des données n’est pas claire.
- Les actions peuvent s’étendre sur plusieurs systèmes SaaS, chacun avec une visibilité partielle.
Même les systèmes de gouvernance des identités rencontrent des difficultés, car les flux de travail s’exécutent souvent sous des identités de service de longue durée auxquelles aucun humain ne peut être lié.
Ce qui émerge est une couche fantôme de logique métier qui se situe entièrement en dehors des limites des programmes traditionnels AppSec, DevSecOps et d’identité. Tant que la propriété reste fragmentée et que la découverte reste difficile à découvrir, la dette liée aux sûretés continue de croître de manière incontrôlée.
Comment gérer les risques de sécurité sans code
Le développement sans code ne va pas disparaître ; en fait, la génération de flux de travail assistée par l’IA ne fait que l’accélérer. Réprimer le développement citoyen ne fera qu’étouffer l’innovation et ne constitue pas une option viable. Une meilleure approche consiste à gagner en visibilité et à établir une gouvernance là où il n’en existe pas actuellement. Voici un processus en cinq étapes à considérer :
- Mettre en œuvre la découverte continue sur toutes les plateformes sans code pour identifier les flux de travail, leurs sources de données et leurs niveaux de privilèges.
- Attribuer une propriété explicite à chaque automatisation, y compris les flux de travail auparavant liés aux comptes de service ou aux anciens employés.
- Établir une gouvernance du cycle de vie couvrant le suivi des modifications, la gestion des versions et les critères de retrait.
- Surveiller les flux de travail au moment de l’exécution pour détecter une élévation de privilèges, un accès excessif aux données ou un comportement suspect du connecteur.
- Intégrer la gouvernance de l’automatisation dans les cadres de sécurité existants, de sorte que la logique construite par les citoyens bénéficie de la même surveillance que les applications traditionnelles.
Nous entrons dans une ère où les vulnérabilités les plus dangereuses ne se trouvent pas dans le code écrit par les équipes AppDev, mais dans les milliers de flux de travail et d’automatisations que les utilisateurs professionnels créent eux-mêmes. Plus tôt les organisations reconnaîtront et affronteront le patrimoine invisible du no-code, plus vite elles pourront réduire la dette de sécurité qui s’accumule au sein de leur infrastructure.
