Connect(); 2016

Volume 31, numéro 12

Cet article a fait l'objet d'une traduction automatique.

ALM et DevOps - Sécuriser et fournir des fonctionnalités « Rugged DevOps »

Par Jean-Marc Prieur, Sam Guckenheimer ; 2016

La sécurité peut être une rubrique effrayant. Selon le rapport de sécurité Microsoft (bit.ly/2drid6a), l’année dernière 17,9 pour cent des ordinateurs de rapports a rencontré les menaces de sécurité. Et le degré d’urgence pour protéger plu que jamais. Le temps nécessaire pour compromettre presque toujours jours ou moins, si pas minutes ou moins, recherche Verizon dans son « rapport Investigations de divulgation de données 2016 » (vz.to/2dnpNk8).

Il existe souvent un conflit perceptible entre DevOps pratiques, dont l’objectif pour la vitesse, et les méthodes de sécurité, mettre en évidence les niveaux. Le conflit n’existe. En fait, un nombre de fournisseurs travaillent pour sécuriser davantage les pipelines DevOps. Et cela fait partie d’un mouvement vers DevOps robuste. Cet article décrit quatre extensions qui vient d’être disponibles via le Marketplace de Visual Studio Team Services (VSTS).

Commençons par une vue d’ensemble d’un pipeline DevOps robuste (voir Figure 1).

Le flux de travail DevOps robuste
Figure 1 le flux de travail DevOps robuste

L’objectif d’un pipeline DevOps robuste est de permettre aux équipes de développement rapide sans casser des choses en introduisant des vulnérabilités indésirables. Pour les études de cas d’équipes de mise en œuvre des opérations de développement robuste, reportez-vous au chapitre 22 de « Le DevOps Handbook » (Press révolution INFORMATIQUE, 2016) par GÈNE Kim, Jez Humble, Patrick Debois et John Willis (bit.ly/2dUXJW3).

Gestion des packages

Tout comme une équipe utilise le contrôle de version comme seule source de vérité pour le code source en cours, il peut reposer sur un gestionnaire de package comme unique source des composants binaires. À l’aide de gestion des packages binaires, une équipe de développement peut créer non seulement un cache local de composants approuvées, mais également en faire un flux de confiance pour le pipeline d’intégration continue (CI). Gestion des packages, présent dans VSTS et bientôt à Team Foundation Server (TFS), fait partie intégrante du flux de travail du composant. L’extension de la gestion de packages est disponible à partir de Visual Studio Marketplace (bit.ly/1VLXIzG).

Le rôle des composants de systèmes d’exploitation

Aujourd'hui, les développeurs sont beaucoup plus que jamais en productivité, en raison du large disponibilité des composants du logiciel réutilisable ouvrir la source. Il existe désormais une approche pratique à réutiliser, avec des runtimes disponibles sur Windows et Linux, tels que .NET Core et Node.js. En même temps, la productivité de la réutilisation des systèmes d’exploitation est fourni avec le risque que les dépendances réutilisés mettre des failles de sécurité. Par exemple, thesnyk.io service revendications 76 pour cent de ses utilisateurs de trouver des failles de sécurité dans leurs applications en raison des versions des packages Node.js qu’ils utilisent. 

Dans le monde de systèmes d’exploitation, il existe un nouveau concept, parfois appelé logiciel Composition Analysis (SCA), qui est représenté dans Figure 2. Elle implique des scénarios comme celui-ci :

Comme un développeur ou un responsable du développement, lorsque je consommer un composant OSS, créer une dépendance ou consommer des dépendances, je souhaite : démarrer avec la dernière version correcte afin d’éviter les vulnérabilités ancien ou de licence d’utilisation abusive ; valider qu’ils sont en fait les fichiers binaires corrects pour cette version ; dans le pipeline de versions, valider les fichiers binaires pour assurer qu’elles sont correctes et pour maintenir une nomenclature traçable ; en cas d’une vulnérabilité, notifiées immédiatement et être en mesure de corriger et de redéployer automatiquement afin d’éviter toute faille de sécurité ou une utilisation abusive de licence de logiciel réutilisé.

Création en toute sécurité les dépendances Open Source
Figure 2 Création en toute sécurité Open Source de dépendances

Deux fournisseurs qui fournissent désormais des services de gestion des systèmes d’exploitation avec VSTS et TFS sont WhiteSource et Veracode. Les deux présentent des extensions disponibles dans Visual Studio Marketplace. 

Présentation de la solution : Extension WhiteSource pour VSTS et TFS

Pour une équipe consomment des packages externes, le WhiteSource Extension aborde en particulier les questions de conformité de la sécurité, de qualité et de licence open source. Dans un monde où la plupart des violations ciblent des vulnérabilités connues dans les composants connus, il s’agit d’hygiène essentiel pour la consommation open source. Nous aborderons certaines de ses fonctions.

En permanence détecte tous les ouvrir composants sources dans votre logiciel WhiteSource l’extension (bit.ly/2dEMCC0) détecte automatiquement tous les composants open source, y compris leurs dépendances transitives, chaque fois que vous exécutez une build. Cela signifie que vous pouvez générer un rapport d’inventaire complet en quelques minutes, en fonction de la dernière génération que vous avez exécuté (voir Figure 3). Elle donne également votre sécurité, opérations de développement et équipes juridiques visibilité complètes processus de développement logiciel de votre organisation.

Composant de WhiteSource stock
Figure 3 WhiteSource composant stock

Alertes sur les vulnérabilités de sécurité Open Source et leurs correctifs lorsqu’un nouveau problème de sécurité est détecté, WhiteSource automatiquement génère une alerte et fournit des conseils de remédiation ciblé (voir Figure 4). Cela peut inclure des liens vers les correctifs, correctifs, les fichiers source appropriés et recommandations même modifier la configuration du système pour empêcher l’exploitation. 

Détection des composants vulnérables WhiteSource
Figure 4 WhiteSource détection des composants vulnérables

Automatiquement applique ouvrir Source de sécurité et les stratégies de conformité de licence conformément aux stratégies de l’entreprise, WhiteSource automatiquement approuve, rejette ou déclenche un processus d’approbation manuelle chaque fois qu’un nouveau composant open source est ajouté à une build. Les développeurs peuvent définir des stratégies en fonction des paramètres tels que de la gravité des vulnérabilités de sécurité, licence age de type ou de la bibliothèque. Dès qu’un développeur tente d’ajouter un composant source ouvert qui pose problème, le service envoie une alerte et échouer la build.

Pour la recherche des référentiels en ligne telles que GitHub et Maven centrale WhiteSource propose également une extension de navigateur innovantes. Même avant de choisir un nouveau composant, un développeur peut voir ses failles de sécurité, la qualité et les problèmes de licence, et si elle répond à la stratégie de la société.

Présentation de la solution : Extension pour VSTS : L’enrichissement d’analyseur de Code statique (SCA)

HPE sécurité Fortifiez SCA fournit une analyse statique de sécurité de l’application test à l’aide de VSTS et TFS (bit.ly/2dEWEOW). Ainsi, la sécurité des logiciels une partie du processus de codage en permettant aux développeurs pour rechercher les vulnérabilités de sécurité plus tôt dans le cycle de vie DevOps transparente.

Fortifiez SCA fournit un ensemble complet des analyseurs de sécurité des logiciels qui recherchent des violations de règles de codage spécifique à la sécurité et des conseils. Professionnels de la sécurité et les groupes de développement de l’utiliser pour analyser le code source d’application pour les problèmes de sécurité (voir Figure 5). Fortifiez SCA identifie les causes premières des failles de sécurité de logiciel et offre des résultats précis et classés de risques grâce à l’aide de la mise à jour de ligne de code.

Tâches de génération Visual Studio Team Services pour la sécurité HPE Fortifiez SCA
Tâches de génération figure 5 Visual Studio Team Services pour la sécurité HPE Fortifiez SCA

Fortifiez sur demande également une application de sécurité en tant que Service (SaaS). Renforcez la protection à la demande des tâches envoyer automatiquement les demandes d’analyse statique et dynamique pour la plate-forme d’applications SaaS (voir Figure 6). Pour les évaluations statiques, le projet est téléchargé vers Renforcez à la demande. Pour les évaluations dynamiques, renforcez à la demande utilise une URL préconfiguré l’application.

HPE sécurité Fortifiez sur la détection des vulnérabilités à la demande
Figure 6 HPE sécurité Fortifiez sur la détection des vulnérabilités à la demande

L’équilibrage de la vitesse et la profondeur

Dans le passé, l’analyse de sécurité était généralement une activité « sur le mur », faite peut-être qu’une seule fois par version. Cela crée un modèle désastreuse de sécurité spécialistes pour trouver les grands lots de problèmes en temps lorsque les développeurs sont sous la pression pour les ignorer et libérer la plupart des. DevOps robuste s’efforce d’effectuer toutes les activités de qualité, y compris la sécurité — continue et automatisée.

Toutes les extensions décrites ici peuvent analyser entièrement le code source de l’équipe. Il existe plusieurs points d’intégration dans le flux de travail de l’équipe d’analyse.

Requêtes d’extraction (PRs) constituent la méthode que DevOps équipes de soumettre les modifications. Avant la PR, un développeur doit être en mesure de voir l’effet des modifications du code et être certain ils fusionner correctement et n’introduit pas de nouveaux problèmes. Dans un processus DevOps, chaque PR est généralement faible et fusions sont continues, la branche principale de code permettre garder. Dans l’idéal, le développeur peut identifier les problèmes de sécurité avant le fournisseur de WhiteSource facilite ce processus de validation des dépendances avec son empreinte binaire ; Checkmarx fournit une analyse incrémentielle des modifications ; et Veracode comprend le concept d’un bac à sable de développement. Ces approches permettent au développeur de faire des essais avec les modifications avant de les envoyer.

De même, élément de configuration doit être optimisé pour la vitesse de commentaires le développement équipe immédiate de tous les sauts de génération. Comme dans le flux de relations publiques, lorsque l’analyse est insuffisant, il peut et doit être intégré dans la définition de build CI. Échec d’analyse peut interrompre la génération et les problèmes de sécurité peuvent être fixes immédiatement pour restaurer la build en vert.

En même temps, la remise continue (CD) doit être complète. Dans VSTS, CD est généralement gérée par le biais des définitions de version, dont la sortie de génération de progression au sein d’environnements, ou via des définitions de build supplémentaires qui peuvent être planifiées, peut-être quotidienne, plutôt que déclenché à chaque validation. Dans les deux cas, la définition peut analyser plus analyse statique (voir Figure 7). Le projet de code complet pouvant être analysé et les erreurs ou avertissements consulté en mode hors connexion sans bloquer le flux de l’élément de configuration.

La définition de Build peut déclencher une analyse de l’analyse statique du Code Source
Figure 7 la définition de Build peut déclencher une analyse de l’analyse statique du Code Source

Présentation de la solution : Extension Checkmarx pour VSTS

L’extension Checkmarx pour VSTS (bit.ly/2dVyuDg) permet aux développeurs non seulement analyser tout le code source, mais également à code nouveau ou modifié. Cette fonction analyse incrémentielle est un outil indispensable pour les développeurs dans des environnements CI car cela réduit les délais d’analyse des heures à quelques minutes seulement.

Une fois l’analyse terminée, Checkmarx remet un rapport concis détaillant la posture de sécurité du code analysé sur la page de résumé de projet VSTS, ce qui permet aux développeurs d’adresser et de réduire les vulnérabilités (voir Figure 8).

Services de Visual Studio Team Build, rapport des résultats d’analyse de Checkmarx
Services de la figure 8 Visual Studio Team Build, rapport des résultats d’analyse de Checkmarx

Checkmarx fournit également aux développeurs « Corriger idéalement » afin de réduire le temps de mettre à jour. Cela inclut un graphique visuel de graphe de flux de données qui indique l’emplacement idéal dans le code pour traiter plusieurs vulnérabilités dans le flux de données dans une seule ligne de code (voir Figure 9).

Emplacement du correctif Checkmarx mieux dans le graphique de flux de données
Figure 9 Checkmarx mieux correctif emplacement dans le graphique de flux de données

Personnalisation des règles, les équipes de développement également peuvent de modifier la vulnérabilité existante détection prédéfinies pour améliorer la détection et la précision des requêtes. Checkmarx décrit les règles dans une syntaxe c# simple.

Code sécurisé n'est qu’une partie de l’image

Code sécurisé est nécessaire, mais pas suffisante pour réaliser des opérations de développement robuste. Le Verizon « Rapport 2016 Data violation Intelligence » indique clairement les nombreux vecteurs d’attaque par les criminels qualifiés de compromettre leurs objectifs. Outre la protection de votre code, il est essentiel de protéger les informations d’identification et les secrets. En particulier, anti-hameçonnage sont de plus en plus sophistiquées.

Il existe plusieurs pratiques une équipe doit appliquer pour se protéger lui-même, comme nous allons maintenant aborder.

L’authentification et l’autorisation utiliser de l’authentification multifacteur même entre les domaines internes et l’administration juste-à-temps, telles que le PowerShell juste assez Administration (JEA), pour vous protéger contre l’élévation des privilèges (aka.ms/jea). Mots de passe différents pour différents comptes utilisateur limite les dommages en cas de vol d’un ensemble d’informations d’identification.

Utiliser le Pipeline de version CI/CD Cela permet de reconstruire l’infrastructure pour le pipeline de versions et la cadence peuvent également contenir des dommages. Si vous gérez l’Infrastructure en tant que Code avec Azure Resource Manager ou que vous utilisez PaaS Azure ou un service similaire, votre pipeline automatiquement créer de nouvelles instances et les détruire, en donnant les pirates pas de place pour masquer à l’intérieur de votre infrastructure (bit.ly/2dEY5wR). VSTS chiffrera les secrets dans votre pipeline, et vous devez faire pivoter les mots de passe comme vous le feriez autres informations d’identification.

Gérer les autorisations faire pour sécuriser le pipeline avec contrôle d’accès basé sur les rôles, comme vous le feriez pour votre code source. Vous souhaitez contrôler qui peut modifier la génération et des définitions de version que vous utilisez pour la production.

Analyse dynamique c’est le processus de test de l’application en cours d’exécution avec des modèles d’attaques connus. Par exemple, OWASP Zed (bit.ly/1fjloVy) est un analyseur dynamique open source populaire pour vérifier contre les vulnérabilités principales que owasp.orgtracks. Deux des partenaires abordées dans cet article, HPE sécurité et Veracode, fournissent des services analyse dynamiques, aussi.

Production analyse il s’agit d’une clé pratique DevOps. Les services spécialisés pour détecter des anomalies liées à des intrusions sont appelés des informations de sécurité et de gestion des événements. Centre de sécurité Azure se concentre sur les incidents de sécurité liés au cloud Azure (bit.ly/2dzcj5r).

Présentation de la solution : Extension Veracode pour VSTS

La plate-forme de sécurité d’Application Veracode est un SaaS qui permet aux développeurs d’analyser automatiquement une application des failles de sécurité. Veracode offre une sécurité statique application test (SAST), l’application dynamique (DAST) les tests de sécurité et SCA, permettant aux équipes de développement évaluer le code de tiers et des composants tiers pour un risque de sécurité (voir Figure 10).

Services de Visual Studio Team Build, rapport des résultats d’analyse de Veracode
Services de la figure 10 Visual Studio Team Build, rapport des résultats d’analyse de Veracode

L’extension Veracode VSTS (bit.ly/2dme4Vr) permet aux équipes de configurer une évaluation continue et automatisée de leurs applications en tant qu’une étape de génération ou de version à partir de leur pipeline CI/CD. L’étape de génération ou de version peut également être configuré pour automatiquement arrêter une build ou une version en fonction de la stratégie de sécurité d’application, ce qui permet aux développeurs d’intégrer des tests dans un pipeline entièrement automatisé de CD de sécurité. En outre, Veracode offre « Développeur Sandbox » analyse pour fournir des résultats sur les modifications d’un développeur avant la soumission. 

Pourquoi intégrer la sécurité d’analyse de votre Pipeline DevOps ?

Car il est désormais possible. Avec les nouvelles extensions sur le marché de VSTS, vous pouvez effectuer l’analyse d’une partie du pipeline de versions de votre équipe continue de la sécurité. Contrairement à dans le passé, lorsque les analyses ont été peu fréquentes et généré un mur de problèmes juste avant une version, vous pouvez traiter les avertissements et erreurs lorsqu’ils se produisent. En traitant les avertissements de sécurité par petits lots — avec chaque PR ou le même jour, vous pouvez réduire le travail dans la sécurité de composant et le code de processus et l’adresse en permanence.

Afin d’optimiser la vitesse, DevOps promeut l’idée de décalage vers la gauche. En d’autres termes, tout ce qui est intéressant de réaliser, est intéressant de réaliser en permanence dans le cadre d’un workflow DevOps. Lorsque vous apportez des modifications, rendre leur version et leur code. Cela crée une source de vérité : votre référentiel de code source et le magasin de gestion de packages approuvés. Lorsque vous mettez à jour, mettre à jour la source de vérité.

Le rapport 2016 « état de DevOps » (bit.ly/28NI32i) à partir de Puppet, meilleurs, en plus de souplesse plus élevé et des résultats de la fiabilité, devait également les meilleurs résultats de sécurité. En intégrant les objectifs du secteur InfoSec (sécurité) des informations dans le travail de développement et les opérations quotidien, qu’ils passent moins de temps à corriger les problèmes de sécurité 50 pour cent. Si vous intégrez la sécurité de votre pipeline DevOps, vous avez un moyen pour créer, tester et déployer des mises à jour automatique. Cela va raccourcir le temps de mettre à jour lorsque de nouvelles vulnérabilités. Mises à jour de sécurité deviennent tout comme les autres mises à jour et peuvent suivre le même flux automatisé.

Les pratiques de sécuriser la réutiliser. Lors de l’analyse en continu des packages, vous pouvez dépendent et savez que vous ne sont pas sélectionner leurs vulnérabilités. En outre, lorsque de nouvelles vulnérabilités sont découvertes en réalité, vous pouvez être averti immédiatement afin de sécurité devient exploitable. Vous pouvez récupérer les nouvelles versions de package, modifier votre code en fonction des besoins, tester et de version, sans avoir à attendre que les pirates découvrir la vulnérabilité.

DevOps démarré en divisant les silos entre le développement et les opérations. Maintenant, vous pouvez décomposer le mur suivant, entre les opérations de développement et InfoSec. Plutôt que de créer des obligations de sécurité qui doivent être traité trop tard, vous pouvez l’empêcher de se répandre dans le pipeline.

La combinaison de ces avantages vous permet d’accéder rapidement. En intégrant automation de sécurité dans votre pipeline, vous pouvez l’utiliser comme accélérateur. Après tout, les pirates passera pour des cibles faciles. Et comme cette vieille blague a, si vous êtes dans un tiers dans les bois et une baisse camping apparaît, il n’est pas l’ours que vous deviez outrun, mais la baisse d’autres cibles potentiels.


Sam Guckenheimer fonctionne dans les Services de Cloud de Visual Studio.  Il est l’auteur de trois ouvrages sur les pratiques de développement agile et un livre électronique sur le trajet de Visual Studio Team Services vers le cloud cadence. Contactez-le à samgu@microsoft.com ou sur Twitter : @samguckenheimer.


Jean-Marc Prieur est responsable de programme senior chez Microsoft, la préparation et gèrent la remise des expériences dans Visual Studio et Visual Studio Team Services axée sur le contrôle de la dette technique, y compris les outils d’analyse architecture.  Contactez-le à jmprieur@microsoft.com ou sur Twitter : @jm_prieur.

Merci aux experts techniques suivants d'avoir relu cet article : Amit Ashbel, Michael droite, Laura Rosenberg et Rotenberg Maya
Amit Ashbel, directeur du Marketing produits chez Checkmarx, Michael droite Senior Product Manager - enrichissement sécurité HPE, Joanna Rosenberg, Marketing de Solution à Veracode et Rotenberg Maya, chef de Marketing chez WhiteSource.