08. Sécurité DevSecOps & CI/CD
08. Sécurité DevSecOps & CI/CD
Pipeline DevSecOps complet : Sécurité shift-left
Le Shift-Left consiste à intégrer les contrôles de qualité et de sécurité le plus tôt possible dans le cycle de développement afin de détecter et corriger les problèmes avant la mise en production.
Static application
Security Testing
Static application security testing (SAST)
| Outil | Type |
|---|---|
| Semgrep | Open source |
| SonarQube | Qualité & sécurité |
| GitHub Advanced Security | Intégré GitHub |
| Checkmarx | Commercial |
| Fortify SCA | Commercial |
| Veracode Static Analysis | SaaS |
| CodeQL | Open source (GitHub) |
Fonctionnement
Dynamic application
Security Testing
Dynamic application security testing (DAST)
| Outil | Type |
|---|---|
| OWASP ZAP | Open source |
| Burp Suite | Référence du marché |
| Invicti (Netsparker) | Commercial |
| Acunetix | Commercial |
| Rapid7 InsightAppSec | SaaS |
| StackHawk | Cloud Native |
Nuclei : Scanner de vulnérabilités applicatives
| Concept | Détecte | Cas d’usage cloud |
|---|---|---|
| • Outil open source développé par ProjectDiscovery • Scanner de vulnérabilités basé sur des templates YAML • Fonctionne comme un DAST léger et automatisable • Très utilisé en prime aux bogues, pentest et CI/CD • Plus de 8 000 templates communautaires | • Vulnérabilités connues (CVE) • Mauvaises configurations • Secrets exposés • Endpoints sensibles • Headers de sécurité manquants • Expositions cloud (S3, Kubernetes, API, etc.) | • Scan d’API REST et GraphQL • Vérification de buckets S3 publics • Détection d’API Gateway exposées • Contrôle d’environnements Kubernetes • Validation de services cloud accessibles depuis Internet • Contrôle de sécurité avant mise en production |
Software composition analysis
- Le Software Composition Analysis (SCA) consiste à analyser les bibliothèques et dépendances open source utilisées par une application afin d’identifier les vulnérabilités connues, les composants obsolètes et les risques liés à la chaîne d’approvisionnement logicielle.
- Objectif : détecter et corriger les vulnérabilités introduites indirectement par les dépendances tierces.
| Ce que vérifie un SCA | Dépendances directes et transitives |
|---|---|
| • Dépendances directes et transitives • Versions utilisées • Vulnérabilités connues (CVE) • Composants obsolètes • Licences open source • Présence dans un SBOM | Mon application └── express |
| Mon application └── express ├── body-parser ├── send | |
| └── debug |
Comparaison de solutions
| Snyk | Dependabot | OWASP Dependency-Check |
|---|---|---|
| Version gratuite et payante | Intégré nativement à GitHub | Open source |
| Plugin VS Code et IntelliJ | Création automatique de Pull Requests | Support multi-langages |
| Analyse des dépendances et CVE | Détection des dépendances vulnérables | Analyse basée sur les bases NVD/CVE |
| Contrôles dans les Pull Requests | Mise à jour automatique des versions vulnérables | Calcul des scores CVSS |
| Correctifs automatiques via Pull Requests | Intégration GitHub simple | Intégration CI/CD |
| Support conteneurs, IaC et code | Focalisé sur les dépendances GitHub | Rapports détaillés de vulnérabilités |
| Approche DevSecOps complète | Solution simple et automatisée | Référence open source pour le SCA |
Renovate : Gestion automatisée des dépendances
Renovate : Fonctionnement
Software bill of materials (SBOM)
| Pourquoi utiliser un SBOM ? | ||
|---|---|---|
| Sécurité | Conformité | Gouvernance |
| • Identification rapide des composants vulnérables • Réponse accélérée aux nouvelles CVE • Amélioration de la visibilité sur la Supply Chain | • Gestion des licences open source • Réponse aux exigences réglementaires • Facilitation des audits | • Inventaire logiciel centralisé • Suivi des versions utilisées • Gestion des risques fournisseurs |
| Un SBOM fournit la liste complète des composants d’un logiciel afin d’améliorer la visibilité, la sécurité et la | ||
| maîtrise de la chaîne d’approvisionnement logicielle. |
Comparatif des formats SBOM
| SPDX | CycloneDX | SWID | |
|---|---|---|---|
| Origine | Linux Foundation (2010) | OWASP Foundation (2017) | ISO/IEC 19770-2 |
| Format principal | JSON, RDF, Tag-Value | JSON (recommandé), XML | XML |
| Orientation | Licences & conformité | Sécurité & Supply Chain | Inventaire logiciel |
| Standard | ISO/IEC 5962 | Standard OWASP | ISO/IEC 19770-2 |
| Points forts | Gestion des licences, conformité open source, gouvernance | Vulnérabilités, VEX, dépendances, CI/CD, conteneurs | Gestion d’actifs, inventaire, déploiement |
| Support CVE | Oui (moins riche) | Excellent support natif | Limité |
| Support VEX | Partiel | Natif | Non |
| Écosystème | GitHub, NTIA, conformité fournisseurs | AWS, Docker, GitHub, Trivy, Snyk, Dependency-Track | ITAM, SAM, grands SI |
| Points faibles | Plus verbeux et complexe | Moins centré sur les licences | Peu utilisé pour la sécurité applicative |
| Cas d’usage idéal | Audit, conformité, licences | DevSecOps, SBOM sécurité, CI/CD | Inventaire logiciel d’entreprise |
Choix du format
Vulnerability Exploitability eXchange (VEX)
VEX permet au créateur d’un logiciel de communiquer si une CVE connue est réellement exploitable dans son produit. Intégré nativement dans CycloneDX 1.4+.
| Information VEX | Utilité sécurité |
|---|---|
| Rôle | Fournir un statut d’exploitabilité pour une vulnérabilité identifiée dans un produit ou composant |
| Lien avec le SBOM | Le SBOM liste les composants et VEX précise si les vulnérabilités associées ont un impact réel |
| Vulnérabilité concernée | Référencer une CVE ou une faille connue analysée dans un contexte précis |
| Statut d’impact | Indiquer si le produit est affecté, non affecté, corrigé ou encore en cours d’analyse |
| Justification | Expliquer pourquoi une vulnérabilité est ou n’est pas exploitable dans ce produit |
| Priorisation | Concentrer les efforts sur les vulnérabilités réellement exploitables |
| Réduction du bruit | Limiter les faux positifs générés par les scanners SCA ou les analyses SBOM |
| Automatisation | Permettre aux outils de sécurité de trier automatiquement les vulnérabilités selon leur impact réel |
| Décision sécurité | Justifier une absence d’action, déclencher une correction, appliquer une mitigation ou surveiller un risque |
Dependency-Track : Plateforme de gestion continue des sboms
| Concept | Workflow intégré | Architecture | |
|---|---|---|---|
| • Plateforme SBOM-native (OWASP) : ingère SPDX et CycloneDX • Corrèle chaque composant avec NVD, OSV, VulnDB, GitHub Advisory • Alerte proactive : nouveau CVE = notification immédiate • Dashboard de risque par projet / équipe / organisation • API REST pour intégration CI/CD et SIEM • Alternatives : Snyk (commercial) · Mend · FOSSA • éploiement : Docker self-hosted ou Dependency-Track Cloud | • Plateforme SBOM-native (OWASP) : ingère SPDX et CycloneDX • Corrèle chaque composant avec NVD, OSV, VulnDB, GitHub Advisory • Alerte proactive : nouveau CVE = notification immédiate • Dashboard de risque par projet / équipe / organisation • API REST pour intégration CI/CD et SIEM • Alternatives : Snyk (commercial) · Mend · FOSSA • éploiement : Docker self-hosted ou Dependency-Track Cloud | • CI/CD génère SBOM (Syft/cdxgen) à chaque build • Upload automatique vers Dependency-Track (API) • D-Track corrèle avec toutes les bases CVE • Si CVE critique → webhook → alert Slack/PagerDuty • VEX peut être émis directement depuis D-Track • Tableau de bord CISO : risque agrégé par portfolio • Historique : évolution du score de risque dans le temps | • Frontend : Vue.js SPA (UI de gestion • Backend : Quarkus (Java) REST API • Base de données : PostgreSQL • Message queue : Alpine (events asy • Intégrations : Jira · GitHub · GitLab Slack · Teams • Auth : OIDC / LDAP / AD (SSO enterprise) • Déploiement : docker-compose ou Helm chart |
La sécurité en continue
Approche consistant à surveiller, vérifier et améliorer en permanence la sécurité des systèmes, applications, infrastructures et identités tout au long de leur cycle de vie.
Lambda, Step Functions, Cloud Run
Sans serveur, sans réseau traditionnel, sans OS à patcher mais avec une surface d’attaque radicalement différente centrée sur les permissions IAM et les déclencheurs d’événements. Paradigme Serverless : Pas de serveur à gérer → Pas de port 22 → Pas d’OS à patcher. MAIS : chaque fonction = 1 identité IAM · chaque déclencheur = 1 vecteur d’attaque · chaque variable d’env = 1 risque de secret exposure.
Sécurité du serverless
Le serverless réduit la gestion de l’infrastructure, mais déplace les risques vers les identités, les événements, les permissions, les dépendances, les secrets et l’observabilité.
| Dimension | Enjeu de sécurité |
|---|---|
| Identités d’exécution | Chaque fonction ou service serverless doit utiliser une identité dédiée avec des permissions minimales |
| Déclencheurs | Les sources capables d’invoquer une fonction doivent être strictement contrôlées |
| Événements | Les messages entrants doivent être filtrés, validés et limités pour éviter les traitements non prévus |
| Secrets | Les secrets ne doivent pas être stockés dans le code ou exposés dans les variables d’environnement |
| Dépendances | Les bibliothèques, layers, images ou packages utilisés par les fonctions doivent être scannés et maintenus |
| Réseau privé | Les fonctions doivent accéder aux ressources sensibles via VPC/VNet, points de terminaison privés ou connectivité maîtrisée |
| Journalisation | Les logs doivent permettre l’audit sans exposer de secrets, tokens ou données sensibles |
| Résilience | Retries, timeouts, quotas et dead-letter queues doivent éviter les boucles, pertes ou surcoûts |
| Surface d’attaque | APIs, points de terminaison publics, permissions excessives et intégrations événementielles deviennent les principaux points d’exposition |
Secrets Management & architecture sécurisée Lambda
Une fonction Lambda ne doit jamais embarquer de secrets en dur : elle doit récupérer des secrets à la demande, avec une identité IAM limitée et des accès réseau contrôlés.
| Élément | Description |
|---|---|
| Principe | La fonction Lambda utilise son rôle IAM pour récupérer uniquement les secrets nécessaires |
| Stockage des secrets | AWS Secrets Manager ou Systems Manager Parameter Store |
| Accès aux secrets | Récupération dynamique, éventuellement avec cache via l’extension AWS Parameters and Secrets Lambda Extension |
| Permissions | Rôle IAM dédié, principe du moindre privilège, accès limité par secret, ressource et action |
| Réseau | Lambda placée dans un VPC si elle doit accéder à des ressources privées |
| Accès privé | VPC Endpoint / PrivateLink pour accéder à Secrets Manager sans passer par Internet public |
| Journalisation | Logs CloudWatch sans exposition de secrets dans les traces, erreurs ou variables affichées |
Cas d’usage :
- Connexion sécurisée à une base de données depuis Lambda
- Récupération d’un mot de passe, token API ou certificat depuis Secrets Manager
- Rotation centralisée des secrets sans redéployer le code
- Accès privé à une base RDS, un cache Redis ou une API interne
- Suppression des secrets stockés dans le code, les variables CI/CD ou les dépôts Git
- Contrôle fin des permissions par fonction Lambda
Sécurité des architectures serverless et événementielles
Les orchestrateurs serverless (Step Functions, Cloud Run, EventBridge) enchaînent des fonctions. Une faille dans la chaîne = compromission de l’ensemble du pipeline.
| Composant serverless | Objectif de sécurité | AWS | Azure | GCP |
|---|---|---|---|---|
| Source d’événement | Autoriser uniquement les événements issus de sources légitimes | S3, EventBridge, SNS | Event Grid, Blob Storage, Service Bus | Eventarc, Cloud Storage, Pub/Sub |
| Routage événementiel | Filtrer les événements pour éviter les déclenchements non prévus | EventBridge rules | Event Grid subscriptions | Eventarc triggers |
| Traitement serverless | Exécuter le traitement avec une identité dédiée et des droits minimaux | Lambda | Azure Functions | Cloud Functions, Cloud Run |
| Orchestration | Encadrer les étapes, conditions, erreurs, retries et compensations | Step Functions | Durable Functions, Logic Apps | Workflows |
| File / message broker | Découpler les traitements et absorber les pics sans perte d’événements | SQS, SNS | Service Bus, Storage Queues | Pub/Sub |
| Messages en échec | Isoler les événements non traités pour analyse, reprise ou investigation | SQS DLQ, EventBridge DLQ | Service Bus DLQ, Event Grid dead-letter | Pub/Sub dead-letter topic |
| Retries automatiques | Maîtriser les relances pour éviter doublons, boucles ou surconsommation | Lambda retries, EventBridge retries | Azure Functions retries, Event Grid retry policy | Eventarc retries, Pub/Sub retry policy |
| Payload événementiel | Limiter les données sensibles et valider le contenu avant traitement | Validation applicative, IAM, KMS | Managed identities, Key Vault, RBAC | IAM, Secret Manager, Cloud KMS |
| Traçabilité | Suivre le cycle complet d’un événement, du déclenchement au traitement | CloudWatch, X-Ray, CloudTrail | Monitor, Application Insights, Activity Logs | Cloud Logging, Cloud Trace, Audit Logs |
Prêt pour lundi
| # | Action | Commande | Durée / Coût | Impact |
|---|---|---|---|---|
| 1 | Installer Gitleaks en pre-commit hook | pip install pre-commit && echo 'repos:\n- repo: https://github.com/gitleaks/gitleaks\n hooks:\n - id: gitleaks' > .pre-commit-config.yaml | 15 min / Gratuit | Bloque les secrets avant le commitcloud |
| 2 | Remplacer les clés statiques par OIDC federation | # GitHub Actions: permissions: id-token: write + aws-actions/configure-aws-credentials@v4 avec role-to-assume | 1h / Gratuit | Plus jamais de clé AWS dans votre pipeline (credentials temporaires uniquement) |
| 3 | Générer un SBOM sur votre application principale | syft . -o cyclonedx-json > sbom.json && grype sbom:sbom.json | 20 min / Gratuit | Inventaire de toutes vos dépendances + CVEs connues en une commande |