La sécurité fait encore bande à part dans la plupart des organisations qui adoptent le DevOps. Une situation qui peut annuler les bénéfices du modèle, selon Van Kim Nguyen, conseiller sénior Agile-DevSecOps chez Desjardins. Expert en développement de logiciels et en transformation numérique, M. Nguyen a piloté des changements technologiques et culturels dans de grandes entreprises comme Pfizer, Adidas et la Banque Nationale. Le 26 février prochain à Québec, il fera une présentation lors de la conférence DevOps sur l’approche DevSecOps qui consiste à intégrer la sécurité au DevOps. 

Pourquoi inclure la sécurité dans le DevOps ?

Van Kim Nguyen : Parce que sans elle, il n’y a pas de livraisons en continu. Quand la sécurité n’est pas intégrée à l’approche DevOps, l’équipe de sécurité intervient à la fin du processus de développement. Cela augmente le risque de retard dans la livraison par la découverte de bogues si tard dans le processus. De plus, lorsqu’une organisation trouve une faille qui exige une nouvelle version une fois l’application développée, les tests de régression sont rarement pour ne pas dire jamais réexécutés. Cela afin d’éviter un retard de livraison. L’organisation déploie alors une application avec une fiabilité et une stabilité à haut risque. Avec l’approche DevSecOps, la question ne se pose plus.

Comment ça fonctionne ?

V.K.N. : La base de la conformité de sécurité applicative est facilement automatisable, comme c’est le cas avec les tests de qualité. Son insertion dans le processus d’intégration continue permet des vérifications à chaque changement de code. L’idée, c’est de trouver tous les problèmes possibles en amont, de les régler sans attendre et de poursuivre l’assemblage du logiciel. Au lieu de faire l’audit de sécurité d’un coup en aval, on le fait au fur et à mesure, diminuant de beaucoup le risque de découvrir des failles à l’aube de la mise en production. Cela dit, il y a de très bons outils d’automatisation et d’intégration continue de la sécurité, mais ils ne sont pas toujours utilisés à leur plein potentiel. Ce n’est pas tout le monde qui a les connaissances et les compétences requises pour déployer de tels outils. Ça prend un ingénieur de sécurité.

Qu’est-ce que le DevSecOps change dans la façon de travailler des gens ?

V.K.N. : Le DevSecOps implique une collaboration étroite et un niveau de confiance élevé entre l’équipe de la sécurité et celles du développement et des opérations. De plus, la sécurité devient une responsabilité partagée. Les développeurs, par exemple, doivent s’habituer à coder en tenant compte de la sécurité. D’ailleurs, avec l’automatisation, le code source peut être analysé en temps réel sur le plan de la sécurité à même l’environnement de développement (IDE). Les développeurs peuvent donc se réajuster à mesure qu’ils codent.

Est-ce que cette approche augmente la sécurité de l’application une fois qu’elle est déployée ?

V.K.N. : Oui. Comme on a pensé à la sécurité en amont, le niveau de confiance est plus élevé au moment du déploiement. Et sachez que les hackers ne vont pas perdre de temps à essayer de défoncer des portes fermées à double tour. Il y a bien assez de portes ouvertes pour les occuper.

Quelle erreur est fréquente en matière de DevSecOps ?

V.K.N. : Ne pas accompagner les employés. Croire qu’ils vont profiter de leurs temps libres pour s’initier à cette pratique. Le DevOps, ce n’est pas une méthode. C’est une culture. La culture de la collaboration, de la confiance, de la fin du travail en silos. Chez Desjardins, on a formé une équipe DevSecOps pour appuyer nos escouades de réalisation. On prend ces dernières une à une, on évalue leur niveau de maturité DevOps, et on dresse un plan d’action pour augmenter leur maturité et les accompagner dans leur évolution vers le DevSecOps. Il faut investir du temps et de l’argent dans l’accompagnement des gens. Sinon, le jello ne prendra pas.

Prolongez votre expérience et téléchargez notre livre blanc DevOps "S'approprier ses conceps pour mieux diriger" :