Surmonter les principaux défis de sécurité du développement low-code/no-code piloté par l’IA

Les plateformes de développement low-code ont changé la façon dont les gens créent des solutions métier personnalisées, notamment des applications, des flux de travail et des copilotes. Ces outils donnent le pouvoir aux développeurs citoyens et créent un environnement plus agile pour le développement d’applications. L’ajout de l’IA à ce mélange n’a fait que renforcer cette capacité. Le fait qu’il n’y ait pas suffisamment de personnes dans une organisation qui ont les compétences (et le temps) pour construire le nombre d’applications, d’automatisations, etc. nécessaires pour faire progresser l’innovation a donné naissance au paradigme low-code/no-code. Maintenant, sans besoin de formation technique formelle, les développeurs citoyens peuvent utiliser des plateformes conviviales et l’IA générative pour créer, innover et déployer des solutions pilotées par l’IA.

Mais à quel point cette pratique est-elle sécurisée ? La réalité est qu’elle introduit une multitude de nouveaux risques. Voici la bonne nouvelle : vous n’avez pas à choisir entre la sécurité et l’efficacité que l’innovation menée par les entreprises offre.

Un déplacement au-delà de la compétence traditionnelle

Les équipes IT et de sécurité sont habituées à concentrer leurs efforts sur l’analyse et la recherche de vulnérabilités écrites dans le code. Ils se sont concentrés sur le fait de s’assurer que les développeurs créent des logiciels sécurisés, en garantissant que le logiciel est sécurisé, puis, une fois qu’il est en production, en le surveillant pour détecter les écarts ou les activités suspectes après coup.

Avec l’essor du low-code et no-code, plus de personnes que jamais créent des applications et utilisent l’automatisation pour créer des applications en dehors du processus de développement traditionnel. Ces personnes sont souvent des employés ayant peu ou pas d’expérience en développement de logiciels, et ces applications sont créées en dehors de la compétence de la sécurité.

Cela crée une situation dans laquelle l’IT n’est plus en train de tout construire pour l’organisation, et l’équipe de sécurité manque de visibilité. Dans une grande organisation, vous pourriez avoir quelques centaines d’applications construites en un an grâce au développement professionnel ; avec le low-code/no-code, vous pourriez en avoir beaucoup plus. C’est un grand nombre d’applications potentielles qui pourraient passer inaperçues ou non surveillées par les équipes de sécurité.

Une multitude de nouveaux risques

  Certains des risques de sécurité potentiels associés au développement low-code/no-code incluent :

1. Hors de la compétence de l’IT – comme mentionné précédemment, les développeurs citoyens travaillent en dehors des lignes des professionnels de l’IT, ce qui crée un manque de visibilité et un développement d’applications fantômes. De plus, ces outils permettent à un nombre infini de personnes de créer des applications et des automatisations rapidement, avec seulement quelques clics. Cela signifie qu’il y a un nombre incalculable d’applications créées à un rythme effréné par un nombre incalculable de personnes, sans que l’IT n’ait une vision d’ensemble.
2. Aucun cycle de vie de développement de logiciels (SDLC) – Le développement de logiciels de cette manière signifie qu’il n’y a pas de SDLC en place, ce qui peut entraîner des incohérences, des confusions et un manque de responsabilité, en plus des risques.
3. Des développeurs novices – ces applications sont souvent construites par des personnes ayant moins de compétences techniques et d’expérience, ouvrant la porte aux erreurs et aux menaces de sécurité. Ils ne pensent pas nécessairement aux implications de sécurité ou de développement de la même manière qu’un développeur professionnel ou quelqu’un ayant plus d’expérience technique. Et si une vulnérabilité est découverte dans un composant spécifique qui est intégré dans un grand nombre d’applications, elle peut être exploitée sur plusieurs instances.
4. De mauvaises pratiques d’identité – la gestion des identités peut également être un problème. Si vous souhaitez habiliter un utilisateur commercial à construire une application, la première chose qui pourrait l’arrêter est un manque de permissions. Souvent, cela peut être contourné, et ce qui se passe, c’est qu’un utilisateur utilise l’identité de quelqu’un d’autre. Dans ce cas, il n’y a pas de moyen de déterminer s’il a fait quelque chose de mal. Si vous accédez à quelque chose que vous n’êtes pas autorisé à faire ou que vous essayez de faire quelque chose de malveillant, la sécurité viendra rechercher l’identité empruntée car il n’y a pas de moyen de distinguer entre les deux.
5. Aucun code à analyser – cela entraîne un manque de transparence qui peut entraver la dépannage, le débogage et l’analyse de sécurité, ainsi que les préoccupations de conformité et réglementaires possibles.

Ces risques peuvent tous contribuer à des fuites de données potentielles. Quelle que soit la façon dont une application est construite – qu’elle soit construite avec un système de glisser-déposer, une invite de texte, ou du code – elle a une identité, elle a accès à des données, elle peut effectuer des opérations et elle doit communiquer avec les utilisateurs. Les données sont déplacées, souvent entre différents endroits de l’organisation ; cela peut facilement briser les frontières ou les barrières de données.

La confidentialité des données et la conformité sont également en jeu. Des données sensibles vivent dans ces applications, mais elles sont gérées par des utilisateurs commerciaux qui ne savent pas (ni même pensent à) les stocker correctement. Cela peut entraîner une série de problèmes supplémentaires, notamment des violations de conformité.

Retrouver la visibilité

Comme mentionné, l’un des grands défis du low-code/no-code est qu’il n’est pas sous la compétence de l’IT/sécurité, ce qui signifie que les données traversent les applications. Il n’y a pas toujours une compréhension claire de qui crée réellement ces applications, et il y a un manque général de visibilité sur ce qui se passe réellement. Et pas toutes les organisations sont même pleinement conscientes de ce qui se passe. Ou elles pensent que le développement citoyen n’a pas lieu dans leur organisation, mais il se produit presque certainement.

Alors, comment les dirigeants de la sécurité peuvent-ils reprendre le contrôle et atténuer les risques ? La première étape consiste à examiner les initiatives de développement citoyen au sein de votre organisation, à découvrir qui (si quelqu’un) dirige ces efforts et à vous connecter avec eux. Vous ne voulez pas que ces équipes se sentent pénalisées ou entravées ; en tant que dirigeant de la sécurité, votre objectif devrait être de soutenir leurs efforts, mais de leur fournir une éducation et des conseils pour rendre le processus plus sûr.

La sécurité doit commencer par la visibilité. La clé est de créer un inventaire d’applications et de développer une compréhension de qui construit quoi. Avoir ces informations aidera à garantir que si une faille de sécurité se produit, vous pourrez retracer les étapes et déterminer ce qui s’est passé.

Établissez un cadre pour ce que ressemble un développement sécurisé. Cela inclut les politiques et les contrôles techniques nécessaires qui garantiront que les utilisateurs prennent les bonnes décisions. Même les développeurs professionnels font des erreurs lorsqu’il s’agit de données sensibles ; il est encore plus difficile de contrôler cela avec les utilisateurs commerciaux. Mais avec les bons contrôles en place, vous pouvez rendre difficile la prise de mauvaises décisions.

Vers un low-code/no-code plus sécurisé

Le processus traditionnel de codage manuel a entravé l’innovation, notamment dans les scénarios de temps de marché concurrentiels. Avec les plateformes low-code et no code d’aujourd’hui, même les personnes sans expérience de développement peuvent créer des solutions pilotées par l’IA. Bien que cela ait rationalisé le développement d’applications, cela peut également compromettre la sécurité et la sûreté des organisations. Il n’est pas nécessaire de choisir entre le développement citoyen et la sécurité ; les dirigeants de la sécurité peuvent s’associer aux utilisateurs commerciaux pour trouver un équilibre entre les deux.