talon Surmonter les principaux défis de sécurité du développement Low-Code/No Code basé sur l'IA - Unite.AI
Suivez nous sur

Des leaders d'opinion

Surmonter les principaux défis de sécurité du développement Low-Code/No Code basé sur l'IA

mm

Publié le

 on

Plateformes de développement low-code ont changé la façon dont les gens créent des solutions commerciales personnalisées, notamment des applications, des flux de travail et des copilotes. Ces outils responsabilisent les développeurs citoyens et créent un environnement plus agile pour le développement d'applications. L’ajout de l’IA au mix n’a fait qu’améliorer cette capacité. Le fait qu'il n'y ait pas assez de personnes dans une organisation qui ont les compétences (et le temps) pour créer le nombre d'applications, d'automatisations, etc. nécessaires pour faire avancer l'innovation a donné naissance au low-code/no-code. paradigme. Désormais, sans avoir besoin d’une formation technique formelle, les développeurs citoyens peuvent tirer parti de plateformes conviviales et de l’IA générative pour créer, innover et déployer des solutions basées sur l’IA.

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

Un changement au-delà du champ de vision traditionnel

Les équipes informatiques et de sécurité sont habituées à concentrer leurs efforts sur analyser et rechercher les vulnérabilités écrites dans le code. Ils se sont attachés à s'assurer que les développeurs créent des logiciels sécurisés, à s'assurer que le logiciel est sécurisé, puis – une fois en production – à le surveiller pour déceler tout écart ou tout élément suspect après coup.

Avec la montée du low code et du 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. Il s'agit souvent d'employés ayant peu ou pas d'expérience en développement logiciel, et ces applications sont créées en dehors du champ de la sécurité.

Cela crée une situation dans laquelle le service informatique ne construit plus tout pour l’organisation et où l’équipe de sécurité manque de visibilité. Dans une grande organisation, vous pouvez créer quelques centaines d’applications en un an grâce au développement professionnel ; avec peu ou pas de code, vous pourriez obtenir bien plus que cela. Cela représente de nombreuses applications potentielles qui pourraient passer inaperçues ou ne pas être surveillées par les équipes de sécurité.

Une multitude de nouveaux risques

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

  1. Ce n'est pas du ressort de l'informatique : comme nous venons de le mentionner, les développeurs citoyens travaillent en dehors des lignes des professionnels de l'informatique, créant 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 rapidement des applications et des automatisations, en quelques clics seulement. Cela signifie qu'un nombre incalculable d'applications sont créées à un rythme effréné par un nombre incalculable de personnes, le tout sans que le service informatique ait une vue d'ensemble.
  2. Non cycle de vie du développement logiciel (SDLC) – Développer des logiciels de cette manière signifie qu'il n'y a pas de SDLC en place, ce qui peut conduire à des incohérences, de la confusion et un manque de responsabilité en plus des risques.
  3. Développeurs novices – Ces applications sont souvent créées par des personnes ayant moins de compétences techniques et d’expérience, ce qui ouvre la porte à des erreurs et à des menaces de sécurité. Ils ne pensent pas nécessairement aux ramifications en matière de sécurité ou de développement comme le ferait un développeur professionnel ou une personne ayant plus d'expérience technique. Et si une vulnérabilité est détectée dans un composant spécifique intégré à un grand nombre d’applications, elle peut potentiellement être exploitée sur plusieurs instances.
  4. Mauvaises pratiques d’identité – La gestion des identités peut également être un problème. Si vous souhaitez permettre à un utilisateur professionnel de créer une application, la principale chose qui pourrait l'arrêter est le manque d'autorisations. Souvent, cela peut être contourné et ce qui se produit, c'est qu'un utilisateur peut utiliser l'identité de quelqu'un d'autre. Dans ce cas, il n’y a aucun moyen de savoir s’ils ont fait quelque chose de mal. Si vous accédez à quelque chose auquel vous n'êtes pas autorisé ou si vous essayez de faire quelque chose de malveillant, la sécurité recherchera l'identité de l'utilisateur emprunté car il n'y a aucun moyen de faire la distinction entre les deux.
  5. Aucun code à analyser – Cela entraîne un manque de transparence qui peut entraver le dépannage, le débogage et l'analyse de la sécurité, ainsi que d'éventuels problèmes de conformité et de réglementation.

Ces risques peuvent tous contribuer à une fuite potentielle de données. Quelle que soit la manière dont une application est créée (qu'elle soit créée par glisser-déposer, par une invite textuelle ou par du code), elle a une identité, elle a accès aux 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 des données.

La confidentialité et la conformité des données sont également en jeu. Les données sensibles résident dans ces applications, mais elles sont gérées par des utilisateurs professionnels qui ne savent pas (ni même réfléchissent) comment les stocker correctement. Cela peut entraîner une multitude de problèmes supplémentaires, notamment des violations de conformité.

Retrouver de la visibilité

Comme mentionné, l'un des le grand défi avec peu ou pas de code est que cela ne relève pas de la compétence informatique/sécurité, ce qui signifie que les données traversent les applications. On ne sait pas toujours clairement 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 toutes les organisations ne sont pas pleinement conscientes de ce qui se passe. Ou bien ils pensent que le développement citoyen n’a pas lieu dans leur organisation, alors que c’est presque certainement le cas.

Alors, comment les responsables de la sécurité peuvent-ils prendre 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 (le cas échéant) dirige ces efforts et à se connecter avec eux. Vous ne voulez pas que ces équipes se sentent pénalisées ou gênées ; en tant que responsable de la sécurité, votre objectif devrait être de soutenir leurs efforts, mais de fournir une éducation et des conseils pour rendre le processus plus sûr.

La sécurité doit commencer par la visibilité. La clé pour cela est de créer un inventaire des applications et de comprendre qui construit quoi. Disposer de ces informations vous permettra de garantir qu'en cas de violation, vous serez en mesure de retracer les étapes et de comprendre ce qui s'est passé.

Établissez un cadre décrivant à quoi ressemble un développement sécurisé. Cela inclut les politiques et contrôles techniques nécessaires qui garantiront que les utilisateurs font les bons choix. 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 professionnels. Mais avec les bons contrôles en place, il peut être difficile de commettre une erreur.

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

Le processus traditionnel de codage manuel a entravé l’innovation, en particulier dans des scénarios de délais de mise sur le marché compétitifs. Avec les plateformes low-code et sans code d'aujourd'hui, même les personnes sans expérience en développement peuvent créer des solutions basées sur l'IA. Même si cela a rationalisé le développement d’applications, cela peut également mettre en danger la sûreté et la sécurité des organisations. Il n’est cependant pas nécessaire de choisir entre le développement citoyen et la sécurité ; les responsables de la sécurité peuvent s'associer aux utilisateurs professionnels pour trouver un équilibre entre les deux.

Michael est le co-fondateur et CTO de Zenité. Il est un expert du secteur de la cybersécurité qui s'intéresse au cloud, au SaaS et à l'AppSec. Avant Zenity, Michael était architecte senior chez Microsoft Cloud Security CTO Office, où il a fondé et dirigé les efforts de produits de sécurité pour l'IoT, les API, l'IaC et l'informatique confidentielle. Michael dirige l'effort de la communauté OWASP sur la sécurité low-code/no-code.