Quand DevSecOps devrait se lire SecDevOps

0

Dans le domaine du développement, la sécurité des produits et applications livrés est un enjeu crucial. La sécurité doit être considérée comme une condition préalable à tout lancement projet. Elle doit être intégrée à l’ensemble du cycle de vie du projet, du développement au déploiement, en utilisant des méthodes flexibles et l’approche DevOps. Cette approche permet de garantir une sécurité optimisée de tous les maillons de la chaîne, du développement au contexte de livraison et d’intégration continue des produits.

I –  Pourquoi la sécurité doit-elle être prise en compte dès le début du cycle de vie du projet ? 

Plus vous découvrez une vulnérabilité tardivement, plus elle coûte cher à réparer ; c’est pourquoi les organisations passent par une nouvelle dynamique, le modèle DevSecOps.

Afin d’accompagner la démarche de Shifting left, le « Security as Code » représente cette nouvelle ère, en apportant la sécurité à la vitesse du DevOps. DevSecOps ne signifie pas que la sécurité doit être mise en œuvre uniquement au niveau « Sec ». Il va de soi que la sécurité doit être la plus transparente et transverse entre les développeurs, les équipes opérationnelles et les experts en sécurité. Cela signifie qu’il faut renforcer le code, au moment de sa création. Cela peut se faire en incorporant des politiques de sécurité automatisées, des tests et des analyses à chaque étape du pipeline CI/CD afin de détecter systématiquement les vulnérabilités et faux positifs en phase de Dev, avant qu’ils puissent survenir en phase de production. Cela permet aux équipes de développement d’économiser le temps et les efforts nécessaires pour résoudre les problèmes après le déploiement.

“La sécurité est le fer de lance des développeurs logiciels. Aujourd’hui, il est vital pour le bon fonctionnement d’une application d’intégrer la sécurité dès le début du processus de développement. Sans prendre en considération la sécurité dès le début, la mise sur le marché de l’application est vouée à être retardée, voire compromise. En fin de compte, DevSecOps et SecDevOps sont des approches légèrement différentes mais avec un même objectif global : fournir des logiciels rapidement tout en évitant les défauts de sécurité.” souligne Stéphane de Saint-Albin, Vice-président, Application & Cloud Security et Président, Rohde & Schwarz Cybersecurity SAS.

L’approche DevOps réunit le développement et les opérations pour un cycle de vie du logiciel plus efficace et permet de réduire considérablement le temps de développement du logiciel. La tendance DevSecOps est précisément née comme une réponse au problème de sécurité en permettant de combler le fossé entre les cycles de publication continus et les besoins de sécurité en abordant la sécurité à chaque étape du SDLC. L’approche DevSecOps a déplacé la sécurité vers la gauche, préconisant la mise en œuvre de pratiques de sécurité dès les premières étapes de planification et de conception, en passant par le développement et les tests.

Via cette approche, les développeurs assurent la responsabilité principale de la sécurité lors de l’écriture du code, et les tests de sécurité sont effectués tout au long du processus de développement, et non une fois celui-ci terminé. Peu importe qu’on l’appelle DevSecOps ou SecDevOps, tant que la sécurité dans le SDLC est gérée et implantée. 

II – Comment mettre en place le modèle DevSecOps ? 

Le modèle DevSecOps implique d’intégrer la sécurité aux processus de développement des applications, du début à la fin. Cela nécessite de nouveaux outils et l’adoption d’une nouvelle culture d’entreprise. Les équipes DevOps doivent automatiser la sécurité pour protéger l’environnement global et les données, ainsi que le processus d’intégration/de distribution continue.

Lorsque vous vous engagez sur la voie de la livraison d’applications sécurisées, vous pouvez découvrir un certain nombre de technologies naissantes comme SCA, SAST, DAST, IAST, WAF, RASP, en cours de projet. En fonction de votre objectif final et de la maturité de vos efforts de développement logiciel, vous devez décider quelle technologie répond le mieux aux besoins de votre équipe DevSecOps.

Aujourd’hui, la nouvelle tendance est la « sécurité en tant que code » qui s’appuie sur les avantages des deux concepts ci-dessus, en décrivant la sécurité, à proximité du code source, d’une manière simple, reproductible et automatisable. Comme son nom l’indique, il s’agit de définir la sécurité, dans un simple fichier de configuration, en tant que code.

Les solutions SAST, SCA, DAST et de protection des applications natives du cloud sont des marchés clairs qui permettent aux organisations de transférer la sécurité de gauche à la phase de construction et de test.

En outre, les solutions de protection des applications natives du cloud computing, comme R&S®Trusted Application Factory, ne protègent pas seulement la phase d’exécution de votre application, mais offrent également des outils pendant la phase de construction pour augmenter le niveau de votre politique de sécurité appliquée.

R&S Trusted Application Factory est une solution qui s’adresse aux équipes DevSecOps avec pour objectif d’ajouter de la sécurité, de la simplicité et de la visibilité.

  • Sécurité : en intégrant la sécurité au plus près de l’application, il est possible de définir une sécurité plus précise et plus pertinente. Cette couche de sécurité est déployée sous forme de micro-WAF pour pouvoir monter à l’échelle ou la faire évoluer en même temps que l’application. Le fait même d’inclure la configuration de la sécurité à l’intérieur même du code de l’application permet de conserver en permanence une sécurité à jour et alignée avec la version de l’application.
  • Simplicité : pour simplifier la collaboration, il faut intégrer la solution de sécurité dans l’univers des équipes DevSecOps. Ainsi, il faut utiliser les mêmes outils, langages et concepts.
  • Visibilité : il est nécessaire de fournir de la visibilité aux différents utilisateurs et responsables : développeurs, infrastructure et sécurité. R&S ®Trusted Application Factory suit l’application de sa conception à son exécution en production, et fournit des indicateurs sur sa sécurité tout au long de son cycle de vie.

III –  La sécurité au service du développement commercial

Cependant, il ne suffit pas d’être innovant. Vous devez vous assurer que vos innovations parviennent rapidement à vos clients potentiels, ou du moins avant qu’elles ne se généralisent. Dans le monde actuel où la concurrence est féroce, le délai de mise sur le marché (ou la vitesse de mise sur le marché) est l’un des modes de différenciation les plus importants pour les applications. Il contribue non seulement à la satisfaction des clients, mais aussi à la croissance des revenus et des parts de marché de l’entreprise.

Les entreprises doivent équilibrer leurs délais de commercialisation et leur niveau d’innovation avec un autre facteur crucial : la sécurité des applications. L’absence de ce troisième facteur peut affaiblir votre objectif global d’offrir une expérience client enrichie. L’interaction entre ces trois éléments peut en fait déterminer la réussite de votre application sur le marché.

Imaginez que vous parveniez à mettre votre application sur le marché en toute hâte, mais qu’elle ne réponde pas aux attentes des clients en termes d’innovation ou de sécurité. Cela ouvrira la porte au triomphe de vos concurrents.  La mise en œuvre d’un modèle DevSecOps peut vous aider dans ce difficile exercice d’équilibre. Analysez dès maintenant les trois aspects mentionnés dans votre processus de livraison d’applications, pour savoir si votre organisation est sur le point d’atteindre les résultats souhaités.

About Author

Stephane de Saint Albin

Stéphane de Saint Albin a plus de 20 ans d’expérience dans l’industrie informatique. Il a travaillé pour des éditeurs de logiciels de toutes tailles, tels que Microsoft, 4D et Symantec, dans des fonctions Marketing, Product Management, Business Développement et Commerciales. Avant de rejoindre DenyAll, Stéphane était responsable de la business unit sécurité de Neowave, une PME française spécialisée dans la RFID et la carte à puce, dans laquelle il a investi. Auparavant, il a passé 11 ans chez Symantec, dont 6 aux USA. Stéphane a rejoint DenyAll est Avril 2011. Il est responsable de la stratégie, des alliances et ventes OEMs, des fusions et acquisitions et du Marketing.

Leave A Reply