Intégration de la sécurité (DevSecOps)
La sécurité intégrée à chaque phase du pipeline. Scan automatisé des vulnérabilités, détection de secrets, vérifications de conformité. Décalez la sécurité vers la gauche pour trouver les problèmes tôt. La sécurité comme code, pas une réflexion après coup.
Porte de sécurité dans le pipeline
a1c4e07feat: export invoices to ERP
- Détection de secretsEn attente
- Analyse statique du codeEn attente
- Analyse des dépendancesEn attente
- Analyse de l'infrastructureEn attente
Porte de mise en production
En attente des contrôles de sécurité
$ dotnet list package --vulnerable --include-transitive
Exemple illustratif
La sécurité à chaque étape
Le « shift left » consiste à trouver les problèmes là où ils coûtent le moins cher à corriger, sans supprimer les contrôles plus loin dans la chaîne.
Pendant le développement
Des analyseurs dans l'IDE, la détection de secrets avant chaque commit et des stratégies de branche qui exigent une pull request relue.
Pendant le build
Analyse statique du code comme CodeQL, analyse des dépendances pour les vulnérabilités connues et les licences, et détection de secrets à chaque push.
Avant le déploiement
Templates d'infrastructure vérifiés par rapport aux policies, images de conteneurs analysées et approbations de production enregistrées.
En production
Microsoft Defender for Cloud pour la posture de sécurité et la détection des menaces, avec des alertes intégrées au même processus d'astreinte.
Sécuriser le pipeline lui-même
Un pipeline capable de déployer en production est une cible de choix pour les attaquants. Nous le traitons comme un système de production.
- Aucun secret dans le code ou le YAML. Les secrets sont stockés dans Azure Key Vault et lus à l'exécution ; la détection de secrets intercepte tout ce qui serait commité par erreur.
- Fédération d'identités de charge de travail. Les connexions de service vers Azure utilisent des identifiants fédérés au lieu de secrets client stockés qui expirent ou fuient.
- Moindre privilège. Chaque identité de pipeline ne peut déployer que vers les resource groups et environnements dont elle a besoin.
- Environnements protégés. Les déploiements en production exigent des approbations et des contrôles, et chaque exécution est journalisée pour l'audit.
- Des dépendances fiables et figées. Les packages proviennent de flux de confiance comme Azure Artifacts, les versions sont verrouillées et les mises à jour sont proposées automatiquement par des outils comme Dependabot ou Renovate.
Des preuves d'audit en prime
Comme chaque modification passe par le même pipeline, vous disposez d'un historique traçable de qui a modifié quoi, quels contrôles ont été exécutés et qui a approuvé la mise en production. Cet historique facilite les audits selon des référentiels comme ISO 27001 ou NIS2, avec beaucoup moins de collecte manuelle de preuves.