Comment DevSecOps habilite les développeurs citoyens

D'ici 2025, total création de données globales atteindra 181 zettaoctets. Pour les entreprises, ces données sont un atout, leur permettant de tirer parti d'une variété de plates-formes technologiques pour créer des expériences client hautement personnalisées qui fidélisent et attirent de nouvelles affaires. Cependant, ces expériences dépendent des infrastructures cloud utilisant des modes de sécurité partagés. C'est là que réside le risque, et il augmente à mesure que la technologie se développe pour intégrer une nouvelle armée de développeurs citoyens utilisant des plates-formes low-code et no-code.

Comprendre et surmonter la mentalité d'héritage 

Gartner estime que d'ici 2025, 70 % des applications d'entreprise seront construites à partir de plates-formes low-code et no-code telles que Salesforce et ServiceNow. Répondre avec un état d'esprit basé sur l'héritage est un moyen sûr de mettre en échec plus des deux tiers des applications d'entreprise.   

« L'état d'esprit d'héritage » est un descripteur approprié pour les problèmes qui affligent l'infrastructure. Cela évoque des enfants riches et gâtés qui dépendent entièrement du travail accompli et des personnes qui les ont précédés. Ce n'est pas une bonne façon de construire un héritage, et c'est une façon tout aussi mauvaise de construire un système.

Lorsque vous avez un état d'esprit hérité, vous supposez que l'infrastructure est définie. La plate-forme est sûre et la sécurité est intégrée. La confiance est supposée simplement parce que la technologie était là avant l'administrateur.

Cet état d'esprit d'héritage affecte les plates-formes low-code et no-code. Les utilisateurs comptent sur la sécurité d'une plate-forme pour les transporter à travers l'ensemble de l'infrastructure de l'entreprise. Au lieu de cela, la sécurité de cette plate-forme ne devrait s'appliquer qu'à cette plate-forme.

Supposons que les développeurs Salesforce créent un programme d'affectation automatisé pour les nouveaux prospects. Ils l'utilisent dans Salesforce pour les affectations internes, et c'est très bien. Ils peuvent compter sur la sécurité de la plate-forme. Ils décident de l'étendre pour améliorer l'automatisation. Ils connectent ce programme à un CRM externe comme ServiceNow, SAP ou Oracle. L'esprit d'héritage prend le dessus : Salesforce est sûr. ServiceNow, SAP ou le tiers est sûr.

Donc, Salesforce + tiers = sûr.

Mais, il y a beaucoup d'inconnues dans ce signe plus. Comment connecter en toute sécurité et de manière conforme le programme interne créé dans Salesforce au programme externe créé dans la plateforme tierce ? Il y a beaucoup de place pour l'erreur dans ce seul personnage.  

Et ce n'est qu'une connexion. De nombreux programmes créés dans Salesforce en touchent des centaines d'autres. Ce sont des centaines d'inconnues traitées comme le signe plus décrit ci-dessus par des personnes qui ont peu ou pas d'expérience en développement.  

La seule solution est de ramener ce développement sur terre avec un retour aux principes DevSecOps.

Établir le cadre DevSecOps 

DevSecOps Les cadres ont été écrits, réécrits et réécrits depuis la création du concept. Il n'est pas nécessaire de réinventer la roue lors de leur établissement, surtout lorsque SAFECode et la Cloud Security Alliance a construit six piliers :

1. Responsabilité collective: La sécurité est la responsabilité de chaque personne dans l'entreprise, mais les gens ne peuvent pas respecter des normes qu'ils ne connaissent pas. Des responsables doivent être chargés de piloter la politique de cybersécurité et de s'assurer qu'elle est diffusée dans toute l'entreprise.  
2. Collaboration et intégration : Les connaissances doivent être partagées et transférées. La moitié de la raison pour laquelle les entreprises tombent dans l'état d'esprit hérité est que tous ceux qui connaissaient l'ancien système ont disparu. Le partage continu des connaissances aide à éliminer ce problème.
3. Mise en œuvre pragmatique : La mise en œuvre pragmatique est liée à l'expérience du développeur. Les processus difficiles, banals et peu maniables ne sont pas suivis longtemps. La sécurité doit être intégrée aux pratiques de développement, c'est-à-dire que chaque ligne de code nécessite une ligne de test. Une entreprise performante irait plus loin en utilisant un outil pour automatiser chaque ligne de code de test.
4. Conformité et développement : Les exigences de conformité doivent guider le processus de développement d'une manière qui ne permette pas aux développeurs de s'en écarter. Un développeur pour une institution financière, par exemple, travaillerait sur une plate-forme conçue pour être conforme à la loi Gramm-Leach-Bliley. Le développeur n'a pas besoin de connaître les tenants et les aboutissants individuels de la loi pour être conforme, car ils sont intégrés à la plate-forme.  
5. Automation: Les tâches prévisibles, répétables et à volume élevé doivent être automatisées dans la mesure du possible pour alléger la charge des développeurs et réduire le risque d'erreur humaine.
6. Moniteur: Les infrastructures cloud modernes changent et se développent. Il est essentiel d'en garder une trace - idéalement, grâce à une forme d'orchestration qui permet une vue d'un coup d'œil de toutes les différentes interconnexions.

Dans un peu ou pas de code l'environnement, ces piliers ne sont pas aussi simples qu'on pourrait s'y attendre. Les personnes qui utilisent ces outils sont souvent des experts métier peu familiarisés avec les fondamentaux de DevSecOps.

Réunir les personnes, les processus et la technologie

L'utilisation de plates-formes low-code et no-code peut en fait aider à combler ce déficit de compétences. Les employés veulent acquérir de nouvelles compétences. Les entreprises peuvent soutenir cela en établissant un cadre DevSecOps axé sur les personnes, les processus et la technologie. 

• processus: Dans un environnement de confiance zéro, les développeurs low-code et no-code n'ont pas à se soucier d'établir des connexions qui mettent en danger l'intégrité du système, car ils sont incapables de le faire. Ils n'ont aucune autorité de base en dehors de leur système isolé.  
• Personnes: Une culture de responsabilité est différente d'une culture de blâme. La responsabilisation signifie que les individus se sentent à l'aise de signaler un problème ou une erreur parce que l'accent est mis sur le problème et non sur la personne.
• Technologie: La technologie est le plus grand obstacle à la bonne mise en œuvre des principes DevSecOps, car elle échappe aux développeurs. Ils doivent utiliser ce que l'organisation leur donne. Si cette technologie ne fonctionne pas, les développeurs proposeront des solutions de contournement qui ne sont ni sûres ni sûres. Essentiellement, la technologie devient un grand générateur de Shadow IT.

Nous vivons une époque passionnante pour le développement. De plus en plus de personnes ont la possibilité de créer des logiciels, de tester des stratégies et d'améliorer la valeur commerciale. Mais avec cela vient le risque. Les entreprises qui cherchent des moyens de se décharger de ce risque sur la technologie garderont leur développement terre à terre tout en laissant de la place à l'exploration.