Electronique Mag - Le journal de l'électronique.

Mais ces dernières années, des violations de séécuritéé de grande ampleur ont fait de la protection des données une préoccupation majeure des équipes de développement de produits. Avec la mise en place des RGPD, la sécurité doit être une priorité.

Par conséquent, qui est prêt à prendre la responsabilité des applications futures et actuelles déployées chaque jour par les organisations informatiques modernes ?

Nous avons posé ces questions à plus de 1 500 développeurs et décideurs informatiques (ITDM) de toute l’Europe.

Dans cet article et le magazine ci-dessous, nous analyserons les résultats, supprimerons les tensions et définirons les prochaines étapes clés.

Que peuvent faire les développeurs ?

Les enjeux sont plus élevés. La sécurité doit être la priorité numéro un.

La bonne nouvelle, c’est que les développeurs sont d’accord avec cela.

Les développeurs (92 %) et les décideurs (88 %) nous rassurent sur le fait qu’ils prennent toutes les précautions nécessaires lors de l’élaboration de nouvelles applications.

De plus, tous s’accordent à dire que la sécurité des données est leur préoccupation principale lors de la fourniture de nouveaux logiciels, et ce pour 53 % des décideurs informatiques et 47 % des développeurs. C’est une bonne nouvelle.

Qu’en est-il des logiciels que nous concevons ?

Cependant, ce consensus disparaît lorsqu’il s’agit d’écrire un logiciel. Mais pourquoi ?

L’équilibrage des priorités fait défaut.

Il ne peut y avoir de sécurité sans disposer au préalable de fonctionnalités, donc la responsabilité est naturellement répartie entre différentes organisations. La bonne nouvelle est que les décideurs informatiques et les développeurs sont pour la plupart assez d’accord sur la répartition des responsabilités. Il n’y a donc pas de source de conflit ici.

Lorsque nous avons demandé aux développeurs quels étaient les principaux responsables de la sécurisation d’une application, seuls 29 % se sont cités, tandis que les autres désignaient les spécialistes sécurité (22 %), les chefs d’entreprise ayant présenté le projet (18 %), l’équipe d’exploitation (16 %) et même des membres de la sécurité qu’ils ne connaissaient pas (14 %).

Un résultat très comparable à celui des décideurs informatiques. La majorité d’entre eux (28 %) pensent qu’un spécialiste sécurité porte l’essentiel des responsabilités. Ils sont par ailleurs 21 % à estimer que ce sont les développeurs et 21 % supplémentaires à désigner le chef d’entreprise ayant effectué la présentation de la build.

Et donc, que signifie tout cela ? Lena Smart, responsable de la sécurité des systèmes d’information chez MongoDB, présente clairement la nature des défis : « Les exigences de contrôle et l’aspect pratique ont longtemps été en contradiction. Les développeurs sont soumis à la pression permanente de livrer dans les délais, en conformité avec les spécifications, en toute sécurité et à grande échelle. Cette difficulté ne fera que continuer. Ces conflits peuvent être élucidés lorsque l’on analyse la façon dont tout cela est géré dans les entreprises d’aujourd’hui. »

Comment faire pour concilier un haut niveau de sécurité avec le besoin de fournir rapidement des utilitaires aux utilisateurs ?

L’agilité, les microservices et le DevOps sont tous trois des disciplines qui ont beaucoup fait pour accélérer le rythme auquel les logiciels peuvent s’adapter à l’évolution des besoins de l’entreprise. Comment faire pour intégrer la sécurité à l’ensemble, et ne pas être obligé de l’ajouter en dernière minute, dans la précipitation et de manière bâclée ?

DevSecOps est la réponse.

Une rupture organisée

La mise en place d’une culture basée sur une approche de type « security as code » (SAC) avec une collaboration flexible et permanente entre les ingénieurs release et les équipes de sécurité contribuera à atténuer les difficultés. C’est une tâche impliquant les personnes, les processus et les technologies tout au long du pipeline de livraison des applications, de la conception et du codage au test et au support.

De cette façon, un juste équilibre sera trouvé entre les exigences de contrôle et l’aspect pratique, par lequel les boucles de rétroaction accorderont à la sécurité la priorité qu’elle mérite.

Le processus DevSecOps n’aura rien d’évident au départ. Il nécessitera à la fois un changement de culture et une évolution des compétences. Et pour le dire autrement, du travail et de la patience.

« Lorsque le processus DevSecOps est correctement appliqué, il peut fournir une plus grande visibilité et une meilleure compréhension de la façon dont les ressources sont utilisées. Il doit devenir et rester une part essentielle de la stratégie de développement d’une organisation », déclare Smart.

Cinq principes du DevSecOps

1. Miser sur l’intégration : La sécurité doit être intégrée. Envisagez tous les impacts, y compris négatifs, qu’une nouvelle fonctionnalité peut par inadvertance avoir, au lieu de vous focaliser sur son impact positif

2. Se montrer spécifique : Déterminez les besoins et les objectifs de votre propre organisation et choisissez les solutions adaptées à votre situation. Il n’existe pas de solution universelle.

3. Adopter une approche axée sur les personnes : Appliquez les principes de sécurité à chaque étape et à chaque collaborateur, y compris les développeurs. Il s’agit d’un sport d’équipe où les compétences et la culture comptent à parts égales.

4. Partager les informations : Une collaboration ouverte est essentielle dans DevSecOps. Partagez, apprenez et progressez constamment en communiquant en interne pour atteindre vos objectifs.

5. Être ambitieux : Ne mettez pas vos ambitions en sourdine. De nombreuses plateformes cloud offrent aujourd’hui des contrôles de sécurité intégrés pour toutes vos données. Optez pour le Cloud.

http://www.mongodb.com/