Blogue

Technologie
SECDEVOPS et Emyode
14 septembre 2017
par Jean-Paul Lizotte

Les processus

Une des initiatives implémentées récemment chez Emyode, pour améliorer la valeur et la qualité livrée à la clientèle, fut de regarder l’intégration des principes « SecDevOPS » dans les flux de travaux, en utilisant l’inspection de code comme outil de base.

Puisqu’un des principes directeurs du « SecDevOPS » est d’assurer que les bonnes pratiques sont maintenues dans le temps, l’ajout de l’inspection du code nous paraissait comme un pas dans cette direction.

La réflexion derrière cette idée est d’établir des normes qui seront capitalisées globalement dans l’entreprise en ce qui concerne les règles de qualité de code. Donc le processus d’établir les normes et règles de qualité de code devient une activité multi-projet interactive où tous peuvent contribuer de leurs valeurs. À l’intérieur duquel, le centre d’excellence en collaboration avec les équipes de Dev peuvent établir des règles et des normes au-delà de celles de l’industrie.

Essentiellement, il s’agit de bénéficier de l’expérience Dev du passé et des erreurs du passé pour assurer un futur, libre des situations déjà rencontrées. Donc, une partie intégrante de l’amélioration en continu.

L’endroit où s’insère cette initiative dans la chaine des outils DevOPS est au moment de commettre du code dans le référentiel. Effectivement, dans les principes d’intégration continu, il y a la notion de « Gated check-in » qui se traduit par une validation de l’état du code avant d’accepter dans le référentiel quoi que ce soit. Ainsi, en plus de valider que le code compile et que les essais unitaires sont corrects, une étape de validation de qualité de code est insérée, basées sur un seuil personnalisé et par projet, ce qui empêche tout ajout au référentiel si le code n’est pas conforme.

De plus, le seuil de tolérance de la qualité de code est ajusté dans le temps vers la diminution des fautes. De cette façon, l’organisation peut planifier une orientation et une amélioration, dans le temps, de la qualité du code et de ses normes collectives.

Securité

L’aspect sécurité du « SecDevOPS » est perçu en deux facettes chez Emyode.

La première consiste à avoir une façon de faire qui prévient la dégradation des bonnes pratiques et ceci dans l’optique d’avoir de l’amélioration continu. Il s’agit là de sécuriser le processus, d’avoir de l’assurance que la dégradation de ce dernier ne peut avoir lieu et est contrôlée pour contribuer et devenir une vulnérabilité.

La deuxième facette consiste à faire en sorte qu’on peut détecter si dans le code des erreurs typiques d’implémentation ne créent pas des vulnérabilités proprement dites, des vecteurs d’attaque ou d’exposition d’informations sensibles. Dans le cas présent, il ne s’agit pas de test de pénétration de surface, mais plutôt de voir si une erreur junior ne viendra pas compromettre le produit. Par exemple, en vérifiant dans le code SQL si des jetons (wildcards) n’auraient pas été inclus, qu’une adresse IP fixe est codée dans le code. Là où l’injection d’une vulnérabilité peut arriver, on l’attrape et on l’expose. Les haches et le dépassement de capacité des espaces tampons peuvent être capturés et évités.

Tout cela ajoute une couche de sécurité additionnelle aux autres tests possibles (surface, charge, etc.).

Dans la chaine d’outils

Chez Emyode, on aime l’intégration horizontale. C’est intégral à la notre façon de gérer les équipes et le processus. Dans cet aspect, pour la gestion de la vie de cycle applicative (ALM), l’outil Visual Studio Team Services (VSTS) de Microsoft n’a pas d’égal. Du design à la livraison du logiciel, tout peut être suivi et maintenu de gauche à droite dans une seule interface Web. La visibilité du projet dans son ultime expression. Alors cette fameuse analyse du code, comment s’intègre-t-elle?

Une des particularités de VSTS est l’usage d’extensions. Les extensions de VSTS permettent d’enficher rapidement et efficacement des ajouts au flux de travail sans compromettre l’expérience utilisateur ou les processus existants. Une des extensions de VSTS permet justement l’intégration de l’outil en source libre SonarQube aux étapes de la compilation (build steps).

Le processus pour ajouter cette extentions enfichable est très simple. Et une fois cette extension en place il est possible de créer des « règles » d’acceptation, soit partagées ou uniques par projets. Les règles peuvent être de toutes sortes de nature, en partant du style jusqu’à la sécurité. Chacun des projets peut ainsi être coté et s’il ne respecte pas un seul défini en tant que niveau de passage (quality gate), la promotion du code de la version en cours peut être refusée d’emblée et enrichie d’une notification à son utilisateur de la raison spécifique.

Conclusion

Nous croyons réellement que l’initiative SecDevOPS sera une partie essentielle à l’amélioration continue de la valeur client chez Emyode. En promettant une meilleure façon de faire, de garder les processus légers, l’intégration de SonarQube nous permet d’ajouter encore plus de valeur sans soucis dans la compilation de notre code. Non seulement on peut avoir une notion de réussite et échec de notre intégration, mais si on veut, on peut faire une analyse complète objective des aspects du code, mesurés dans le temps. S’il y a beaucoup plus à faire pour rendre l’organisation imprégnée des principes SecDevOPS, nous croyons tout de même que cette méthode est efficace pour engager le pas avec un risque minimisé.