Déplacer DevOps vers DevSecOps

Lorsque vous créez ou modernisez une discipline Sécurité du développement, cet article décrit comment l’intégration de la sécurité dans les pratiques de développement permet de passer des opérations de développement (DevOps) aux opérations de sécurité des développeurs (DevSecOps) et contribue à sécuriser la livraison des applications.

Les organisations modernes s’appuient sur le développement rapide de logiciels pour offrir de l’innovation, répondre aux besoins de l’entreprise changeants et maintenir un avantage concurrentiel. DevOps permet cette agilité grâce à l’intégration et à la livraison continues. Toutefois, une vitesse accrue introduit également de nouveaux risques de sécurité.

Les cycles de mise en production continue réduisent le temps entre les décisions de conception et le déploiement de production, ce qui augmente la probabilité que les faiblesses soient introduites dans les environnements de production, notamment :

• Faiblesses de conception d’application
• Dépendances vulnérables
• Erreurs de configuration
• Failles d’automatisation de l’infrastructure
• Mauvaise gestion des secrets ou hygiène.

Risque DevOps

Les environnements DevOps modernes étendent la surface d’attaque sur les systèmes de développement, de pipeline et de production. Les outils DevOps tels que les référentiels de code source, les pipelines et les systèmes d’automatisation sont des cibles à valeur élevée pour les attaquants.

Si du code malveillant est introduit tôt, il peut passer par des contrôles de sécurité existants et atteindre des systèmes de production.

Les objectifs d’attaque courants sont les suivants :

• Injecter du code malveillant dans des artefacts de build.
• Compromettre les identités de développeur ou les comptes de service.
• Accéder à des données de production ou les exfiltrer.

Les attaquants ciblent souvent des applications personnalisées et des environnements de développement pour accéder à :

• Données organisationnelles ou client sensibles.
• Logique métier propriétaire et propriété intellectuelle.
• Infrastructure de production via des systèmes de développement compromis.
• Les clients en aval par le biais d’une compromission de la chaîne d’approvisionnement logicielle.

Les risques de sécurité potentiels sont résumés dans le diagramme suivant :

Risque d’application et de développement

Les charges de travail d’application peuvent être compromises par des faiblesses introduites pendant le développement ou par la compromission de l’infrastructure utilisée pour les générer et les déployer.

Risque	Cible	Résultat potentiel
Conception/implémentation de l’application	Les problèmes de sécurité introduits pendant la conception ou le développement peuvent exposer des charges de travail à des techniques d’attaque telles que : - Validation d’entrée incorrecte - Logique d’authentification ou d’autorisation non sécurisée - Chiffrement faible ou mal implémenté - Exposition des données sensibles par le biais de la logique d’application	Ces faiblesses peuvent permettre aux attaquants de : - Accéder ou manipuler des données d’application - Exécuter des opérations non autorisées - Maintenir l’accès persistant par le biais de défauts logiques implantés.
Infrastructure de développement/automatisation	Les attaques peuvent cibler : - Dépôts de code source - Générer des pipelines - Automatisation du déploiement - Modèles IaC (Infrastructure-as-code) - Développer des points de terminaison ou des identités de service	La compromission peut permettre aux attaquants de : - Insérer du code malveillant dans des artefacts de build - Modifier les configurations de déploiement - Maintenir l’accès persistant par le biais d’un défaut logique implanté - Obtenir des informations d’identification ou des secrets utilisés dans les environnements de production.
Chaîne d’approvisionnement des logiciels de développement	Les applications s’appuient généralement sur : - Bibliothèques tierces - Logiciels open source - Images de conteneur - Services de plateforme	Les vulnérabilités ou le code malveillant introduit par le biais de ces dépendances peuvent affecter : - Charges de travail de production organisationnelles - Environnements clients ou partenaires

L’intégration de la sécurité dans les processus de développement réduit la probabilité que ces risques se propagent en version de production.

Déplacement vers la gauche

Shift left est une approche d’ingénierie de sécurité qui intègre la sécurité plus tôt dans le cycle de vie du développement.

Au lieu de valider la sécurité en retard dans le processus, les organisations l’incorporent dans :

• Envisager
• Design
• Development
• Operations

Cela réduit le coût de correction et l’exposition aux risques.

Pour soutenir cette approche, les organisations doivent"

• Utilisez des bonnes pratiques structurées telles que le cycle de vie du développement de la sécurité (SDL) au début du processus, plutôt que tard lorsque les problèmes deviennent coûteux et difficiles à résoudre.
• Pour maintenir cette approche, intégrez la gouvernance, les risques et la conformité (GRC) à la stratégie de développement.

Qu’est-ce que DevSecOps ?

DevSecOps offre l’approche Shift Left en étendant DevOps et en intégrant la sécurité à chaque étape du cycle de vie du développement logiciel , de l’idée à la conception, au développement et aux opérations.

• Dans les approches de développement traditionnelles, la validation de la sécurité a souvent été effectuée comme une porte de qualité finale avant la mise en production. Cela a créé des retards, un coût de correction accru et a permis la persistance des vulnérabilités jusqu’à la fin du cycle de vie.

• DevSecOps intègre la sécurité plus tôt et l’intègre en continu dans les processus de développement et d’exploitation.

• DevSecOps réduit les frictions entre les équipes de développement, d’opérations et de sécurité, en les alignant sur les objectifs partagés de vitesse d’innovation, de fiabilité et de résilience de sécurité, et permettant aux équipes de résoudre les problèmes les plus importants au début et en continu.

• DevSecOps intègre la sécurité dans :

  • Conception architecturale
  • Implémentation de l’application
  • Automatisation de l’infrastructure
  • Processus de déploiement et d’exploitation

Benefits

DevSecOps permet aux équipes de développement, de sécurité et d’exploitation de :

• Identifiez et corrigez les problèmes plus tôt dans le cycle de vie.
• Réduisez l’exposition en production.
• Maintenez la vitesse de livraison tout en gérant les risques.

La sécurité fait partie de la façon dont les logiciels sont générés et remis, plutôt qu’un contrôle appliqué après la livraison.

Sécuriser le cycle de vie de l’innovation

L’innovation progresse généralement à deux étapes de cycle de vie :

Étape	Détails
Maturation de l’idée	Une fonctionnalité est conçue, implémentée et validée pour une utilisation initiale de production. Il commence par une nouvelle idée
Version initiale	Une première version de production répond aux critères de produit minimaux pour une utilisation sûre du produit. - Développement : les fonctionnalités répondent aux exigences minimales de l’entreprise. - Sécurité : les fonctionnalités répondent aux exigences de conformité réglementaire, de sécurité et de sécurité pour l’utilisation de la production. - Opérations: Les fonctionnalités répondent aux exigences de qualité, de performances et de prise en charge minimales pour être un système de production.

Après la version initiale, le développement devient itératif à mesure que les charges de travail évoluent avec :

• Modification de la tolérance aux risques
• Exigences et maturité de l’application
• Obligations réglementaires
• Conditions de menace

Intégrer la sécurité au développement

Les approches de développement traditionnelles valident la sécurité tard dans le cycle de vie, comme dernière étape de validation avant la mise en production, une fois la conception et l’implémentation terminées. Dans les environnements de développement modernes, le retard de la validation augmente :

• Complexité des vulnérabilités
• Coût de correction
• Retards opérationnels et interruptions
• Augmentation de l’exposition aux risques liés à l’exploitation active

DevSecOps intègre la sécurité en continu tout au long du développement et des opérations, pour résoudre les problèmes antérieurs, réduire les risques et améliorer la cohérence.

Pratiques clés

La sécurité doit être incorporée dans les processus de développement existants pour être efficace, évolutive et durable. Elle doit être intégrée directement à la façon dont les applications sont conçues, générées, déployées et exploitées, non implémentées dans un flux de travail distinct ou parallèle. Nous recommandons les actions suivantes :

• Cartographie des processus de bout en bout, de l’idée jusqu’au développement, au déploiement et aux opérations continues.
• Définition de rôles, d’outils et de responsabilités clairs pour la sécurité à chaque étape du cycle de vie.
• Établissement de chemins de correction cohérents pour les vulnérabilités, les défauts et les problèmes de conception.

Adapter les pratiques de sécurité en fonction du risque de charge de travail. Les applications critiques pour l’entreprise nécessitent une plus grande rigueur, tandis que les scénarios à faible risque peuvent suivre des approches simplifiées.

Au minimum, vérifiez que vous :

• Identifiez les étapes, les personnes et les technologies impliquées dans votre cycle de vie de développement.
• Définissez la façon dont les activités de sécurité s’intègrent à chaque étape, plutôt que de les traiter comme des points de contrôle distincts.
• Établissez des processus de gestion des modifications majeures et des correctifs de routine tout au long du cycle de vie.

Automatiser la sécurité dans le développement et le déploiement

L’automatisation est essentielle pour appliquer la sécurité de manière cohérente et à grande échelle dans le développement et les opérations.

• Intégrez des contrôles de sécurité et des outils directement dans des pipelines CI/CD.
• Automatisez les activités clés telles que la modélisation des menaces, l’analyse du code, la validation et l’application des stratégies.
• Utilisez l’infrastructure en tant que code (IaC) pour permettre des déploiements reproductibles et sécurisés.

Les bases de plateforme telles que les zones d’atterrissage Azure peuvent prendre en charge cette approche par

Les bases de plateforme telles que Azure zones d’atterrissage peuvent prendre en charge cette approche en fournissant des modèles standardisés pour la sécurité, la gouvernance et l’intégration de DevOps.

Résultats attendus

Les organisations qui passent de DevOps à DevSecOps peuvent :

• Réduire la probabilité que les vulnérabilités soient introduites dans les charges de travail de production
• Limiter la capacité des attaquants à exploiter l’infrastructure de développement ou l’automatisation
• Améliorer la résilience des applications à l’évolution des techniques d’attaque
• Prendre en charge les exigences de conformité réglementaire et organisationnelle
• Maintenir la vitesse de l’innovation sans augmenter le risque opérationnel ou de sécurité

Conseils sur la navigation dans le parcours

L’adoption de DevSecOps nécessite des changements organisationnels et culturels.

Changements de l’éducation et de la culture

Il s’agit d’étapes critiques précoces. L’équipe que vous avez doit développer de nouvelles compétences et adopter de nouvelles perspectives pour comprendre le modèle DevSecOps.

Le changement de l’éducation et de la culture prend du temps, le focus, le parrainage exécutif et un suivi régulier pour aider les individus à comprendre et à voir la valeur du changement.

L’évolution des cultures et des compétences peut parfois tirer parti de l’identité professionnelle des individus, ce qui crée un potentiel de résistance forte. Il est essentiel de comprendre et d’exprimer pourquoi, quoi et comment le changement pour chaque individu et sa situation.

La modification prend du temps

Vous ne pouvez bouger que aussi rapidement que votre équipe peut s’adapter aux implications de faire des choses de nouvelles façons. Les équipes doivent effectuer leurs tâches existantes lors de leur transformation.

Il est essentiel de hiérarchiser soigneusement ce qui est le plus important et de gérer les attentes quant à la rapidité de ce changement.

Adopter une approche progressive, en donnant la priorité aux éléments les plus importants et fondamentaux, est bénéfique pour votre organisation.

Ce changement entraîne des frictions temporaires

Toutes les nouvelles technologies, méthodologies et autres changements introduisent des frictions et de la confusion. Il est essentiel de se concentrer sur les frictions saines qui poussent la pensée critique à réduire les risques tout en évitant les frictions non saines qui ralentit les processus avec un avantage limité ou une réduction des risques.

Ressources limitées

Un défi auquel les organisations font généralement face tôt est de trouver des talents et des compétences dans le développement d’applications et de sécurité.

À mesure que les organisations commencent à collaborer plus efficacement, elles peuvent trouver des talents cachés, tels que des développeurs ayant un état d’esprit de sécurité ou des professionnels de la sécurité avec un arrière-plan de développement.

Postes en cours

Les applications changent rapidement. Outre les nouvelles fonctionnalités, la définition technique et la composition d’une application changent fondamentalement avec l’introduction de technologies telles que le cloud, serverless et l’IA.

Cette évolution change les pratiques de développement, la sécurité des applications et permet même aux non-développements de créer des applications.

Considérez un modèle SRE

Certaines implémentations DevSecOps combinent des opérations et des responsabilités de sécurité dans un rôle d’ingénieur de fiabilité de site (SRE).

Bien qu’un tel modèle puisse fonctionner, il s’agit souvent d’un changement extrême de la culture et des pratiques d’entreprise existantes.

Si vous envisagez un modèle SRE, nous vous recommandons de commencer par incorporer la sécurité dans DevOps à l’aide de gains rapides pratiques et de progrès incrémentiels décrits dans ce guide pour vous assurer que vous obtenez un bon retour sur investissement (ROI) et répondez aux besoins immédiats.

Cela ajoute de façon incrémentielle des responsabilités de sécurité à votre personnel d’exploitation et de développement, ce qui rapproche les équipes d’un état final SRE.

Étapes suivantes

Découvrez les meilleures pratiques de développement sécurisées.