Vue d’ensemble du développement et des opérations de sécurité

Comment Microsoft implémente-t-il des pratiques de développement sécurisé ?

Le cycle de développement de la sécurité de Microsoft (SDL) est un processus d’assurance en matière de sécurité axé sur le développement et le fonctionnement des logiciels sécurisés. SDL fournit des exigences de sécurité détaillées et mesurables pour les développeurs et ingénieurs de Microsoft afin de réduire le nombre et la gravité des vulnérabilités dans nos produits et services. Toutes les équipes de développement logiciel Microsoft doivent respecter les exigences sdl, et nous mettons continuellement à jour le SDL pour refléter l’évolution du paysage des menaces, les meilleures pratiques du secteur et les normes réglementaires en matière de conformité.

Comment SDL de Microsoft améliore-t-il la sécurité des applications ?

Le processus SDL chez Microsoft peut être considéré en cinq phases de développement : exigences, conception, implémentation, vérification et publication. Il commence par définir les exigences logicielles en gardant à l’esprit la sécurité. Pour atteindre cet objectif, nous posons des questions de sécurité sur ce que l’application doit accomplir. L’application doit-elle collecter des données sensibles ? L’application peut-elle effectuer des tâches sensibles ou importantes ? L’application doit-elle accepter les entrées provenant de sources non fiables ?

Une fois les impératifs de sécurité pertinents identifiés, nous concevons nos logiciels de façon à intégrer des fonctionnalités de sécurité répondant à ces exigences. Nos développeurs implémentent les exigences de SDL et de conception dans le code, que nous vérifions via la révision manuelle du code, l’automatisation automatisée des outils de sécurité et le test de pénétration. Enfin, avant que le code ne puisse être publié, les nouvelles fonctionnalités et les modifications matérielles font l’objet d’un examen final de la sécurité et de la confidentialité pour s’assurer que toutes les exigences sont remplies.

Comment Microsoft teste-t-il le code source pour détecter les vulnérabilités courantes ?

Pour aider nos développeurs à mettre en œuvre les exigences de sécurité pendant le développement du code et après sa publication, Microsoft leur propose une suite d’outils de développement sécurisés qui permettent de vérifier automatiquement le code source et de détecter les failles de sécurité. Microsoft définit et publie une liste d’outils approuvés que nos développeurs peuvent utiliser, tels que les compilateurs et les environnements de développement, ainsi que les vérifications de sécurité intégrées exécutées automatiquement dans les pipelines de build Microsoft. Nos développeurs utilisent les dernières versions des outils approuvés pour profiter des nouvelles fonctionnalités de sécurité.

Avant que le code puisse être archivé dans une branche de mise en production, sdl nécessite une révision manuelle du code par un réviseur distinct. Les analystes de code vérifient les erreurs de codage et vérifient que les modifications de code répondent aux exigences SDL et de conception, réussissent les tests fonctionnels et de sécurité et fonctionnent de manière fiable. Ils examinent également la documentation, les configurations et les dépendances associées pour s’assurer que les modifications de code sont correctement documentées et ne provoqueront pas d’effets secondaires inattendus. Si un analyste trouve des problèmes lors de la révision du code, il peut demander à l’auteur de soumettre à nouveau le code avec les modifications suggérées et des tests supplémentaires. Les analystes de code peuvent également décider de bloquer entièrement l’archivage du code qui ne répond pas aux exigences. Une fois que le code a été jugé satisfaisant par le réviseur, le réviseur fournit l’approbation requise pour que le code puisse passer à la phase de déploiement suivante.

En plus des outils de développement sécurisés et de la révision manuelle du code, Microsoft applique les exigences SDL à l’aide d’outils de sécurité automatisés. La plupart de ces outils sont intégrés au pipeline de validation et analysent automatiquement le code pour détecter les failles de sécurité à mesure qu’il est archivé et que de nouvelles builds sont compilées. Par exemple, l’analyse statique du code pour les failles de sécurité courantes et les analyseurs d’informations d’identification qui analysent le code pour les secrets incorporés. Les problèmes découverts par les outils de sécurité automatisés doivent être résolus avant que les nouvelles builds puissent passer une révision de sécurité et être approuvées pour la publication.

Comment Microsoft gère-t-il les logiciels open source ?

Microsoft a adopté une stratégie de haut niveau pour la gestion de la sécurité open source, qui utilise des outils et des flux de travail conçus pour :

• Comprendre les composants Open source utilisés dans nos produits et services.
• Suivez l’emplacement et la façon dont ces composants sont utilisés.
• Déterminez si ces composants présentent des vulnérabilités.
• Répondre correctement lorsque des vulnérabilités sont découvertes et qui affectent ces composants.

Les équipes Microsoft Engineering sont responsables de la sécurité de tous les logiciels open source inclus dans un produit ou un service. Pour atteindre cette sécurité à grande échelle, Microsoft a intégré des fonctionnalités essentielles aux systèmes d’ingénierie par le biais de la gouvernance des composants (CG), qui automatise la détection open source, les flux de travail des exigences juridiques et les alertes pour les composants vulnérables. Les outils cg automatisés analysent les builds chez Microsoft à la recherche de composants open source et des vulnérabilités de sécurité associées ou des obligations légales. Les composants découverts sont enregistrés et envoyés aux équipes appropriées pour les avis d’entreprise et de sécurité. Ces examens sont conçus pour évaluer les obligations légales ou les vulnérabilités de sécurité associées aux composants Open source et les résoudre avant d’approuver les composants à des fins de déploiement.

Réglementations externes connexes & certifications

Les services en ligne de Microsoft sont régulièrement auditées pour vérifier la conformité aux réglementations et certifications externes. Reportez-vous au tableau suivant pour la validation des contrôles liés au développement et au fonctionnement de la sécurité.

Azure et Dynamics 365

Audits externes	Section	Date du dernier rapport
ISO 27001/27002 Déclaration d’applicabilité Certificat	A.12.1.2 : Contrôles de gestion des modifications A.14.2 : Sécurité dans les processus de développement et de support	6 novembre 2023
ISO 27017 Déclaration d’applicabilité Certificat	A.12.1.2 : Contrôles de gestion des modifications A.14.2 : Sécurité dans les processus de développement et de support	6 novembre 2023
SOC 1 SOC 2 SOC 3	SDL-1 : Méthodologie du cycle de vie du développement de la sécurité (SDL) SDL-2 : Exigences de contrôle de sécurité documentées dans les versions SDL-4 : Séparation des environnements de test et de production SDL-6 : Analyses des programmes malveillants sur les builds de code source SDL7 : révision semi-annuelle de SDL	17 novembre 2023

Microsoft 365

Audits externes	Section	Date du dernier rapport
FedRAMP (Office 365)	SA-3 : Cycle de vie du développement du système	31 juillet 2023
ISO 27001/27002/27017 Déclaration d’applicabilité Certification (27001/27002) Certification (27017)	A.12.1.2 : Contrôles de gestion des modifications A.14.2 : Sécurité dans les processus de développement et de support	Mars 2024
SOC 1 SOC 2	CA-03 : Gestion des risques CA-18 : Gestion des modifications CA-19 : Surveillance des modifications CA-21 : Test de modification CA-38 : Configurations de base CA-46 : Révision de sécurité	23 janvier 2024

Ressources

• Vidéo : Développement et fonctionnement de la sécurité Microsoft 365
• Cycle de vie du développement de la sécurité de Microsoft