Architecture DevSecOps orientée par le risque avec corrélation multi-étape basée sur MITRE ATT&CK et preuves empiriques dans des pipelines CI/CD natifs du cloud

1. Introduction

La consolidation des architectures cloud-native, des microservices et de l’infrastructure as code (Infrastructure as Code – IaC) a profondément redéfini le cycle de vie du développement logiciel. L’adoption des pipelines CI/CD permet d’intégrer, de tester et de déployer en production les modifications de code à des intervalles de plus en plus courts. Bien que ce paradigme réduise le délai de livraison des fonctionnalités, il élargit également la surface d’attaque, car les artefacts transitent par de multiples étapes automatisées et des dépendances externes sont incorporées dynamiquement au cours du processus de build.

Des rapports empiriques indiquent que l’exploitation de vulnérabilités connues demeure un vecteur initial récurrent dans les incidents de sécurité. Le Data Breach Investigations Report de 2023 documente que les vulnérabilités connues et les erreurs de configuration restent parmi les facteurs prédominants dans les compromissions initiales de systèmes d’entreprise (VERIZON, 2023). Parallèlement, l’Agence de l’Union européenne pour la cybersécurité souligne l’augmentation significative des attaques ciblant la chaîne d’approvisionnement logicielle, en particulier celles qui exploitent les pipelines de build ou des dépendances externes (ENISA, 2022).

Des incidents largement analysés illustrent la gravité de ce scénario. La vulnérabilité Log4Shell (CVE‑2021‑44228) a démontré comment des bibliothèques largement diffusées peuvent introduire un risque systémique lorsqu’elles sont utilisées dans des milliers d’applications. De manière similaire, l’incident SolarWinds a mis en évidence que des processus de build compromis peuvent entraîner la distribution de logiciels malveillants signés et de confiance (CISA, 2021). Ces événements révèlent que le problème central ne réside souvent pas seulement dans l’existence de vulnérabilités, mais dans l’absence de visibilité intégrée entre développement, build et exécution.

Plusieurs techniques employées par des adversaires dans ce contexte sont documentées dans le framework MITRE ATT&CK, notamment T1195 (Supply Chain Compromise), T1552 (Unsecured Credentials), T1059 (Command and Scripting Interpreter) et T1610 (Deploy Container) (MITRE, 2023). Toutefois, les outils de sécurité fonctionnent fréquemment de manière isolée : les solutions SAST détectent des schémas statiques de vulnérabilité, les outils SCA identifient des dépendances vulnérables et les systèmes de surveillance runtime détectent des comportements suspects. L’absence de corrélation sémantique entre ces domaines réduit l’efficacité opérationnelle et contribue à des volumes élevés d’alertes.

Dans ce contexte, nous examinons trois questions centrales de recherche :

• RQ1 : Comment formaliser mathématiquement la priorisation des vulnérabilités dans des pipelines DevSecOps en intégrant la probabilité d’exploitation et le contexte opérationnel ?
• RQ2 : Est-il possible de détecter des chaînes d’attaque multi-étapes en corrélant des événements de build et de runtime alignés sur MITRE ATT&CK ?
• RQ3 : Quel est l’impact opérationnel d’un modèle orienté risque sur des métriques telles que le temps moyen de remédiation et le taux relatif de faux positifs ?

Nous proposons une architecture DevSecOps orientée risque qui intègre la modélisation formelle, la corrélation comportementale et l’automatisation des politiques de sécurité. L’approche combine intelligence sur les menaces, analyse statique et surveillance en temps d’exécution dans un modèle unique de priorisation.

2. Background and Related Work

2.1 DevSecOps et Sécurité dans le SDLC

Le Secure Software Development Framework (SSDF), publié par le NIST, définit des pratiques structurées pour intégrer la sécurité tout au long du cycle de vie du développement (NIST, 2022). Ces pratiques incluent le contrôle des dépendances, la traçabilité des artefacts et la vérification continue de la sécurité. Dans les environnements modernes, ces pratiques sont opérationnalisées au moyen de pipelines CI/CD automatisés.

Des recherches antérieures montrent que l’intégration effective de la sécurité dans DevOps dépend non seulement des outils, mais aussi de mécanismes de priorisation qui réduisent la charge cognitive des équipes (RAHMAN; WILLIAMS, 2016). Des études empiriques indiquent également que les approches fondées uniquement sur la détection de vulnérabilités produisent souvent des volumes d’alertes incompatibles avec la capacité de réponse des équipes.

2.2 Métriques de vulnérabilité

Le Common Vulnerability Scoring System (CVSS) fournit un modèle standardisé pour classer la sévérité technique des vulnérabilités (MELL; SCARFONE; ROMANOSKY, 2007). Toutefois, le CVSS a été conçu pour évaluer les caractéristiques intrinsèques de la vulnérabilité et ne prend pas en compte le contexte spécifique de déploiement.

Pour atténuer cette limitation, l’Exploit Prediction Scoring System (EPSS) estime la probabilité d’exploitation des vulnérabilités sur la base de données observationnelles et de renseignements sur les menaces (FIRST, 2023). La combinaison du CVSS et de l’EPSS a été utilisée dans plusieurs travaux récents afin d’améliorer la priorisation des correctifs.

2.3 Sécurité de la chaîne d’approvisionnement

Ces dernières années, la sécurité de la chaîne d’approvisionnement est devenue un thème central de la sécurité logicielle. Des initiatives telles que SLSA (Supply-chain Levels for Software Artifacts) et l’adoption du Software Bill of Materials (SBOM) visent à accroître la transparence et la traçabilité dans les processus de build (OWASP, 2023; GOOGLE, 2023).

Le Tableau 1 résume quelques approches largement utilisées pour l’atténuation des risques dans les pipelines CI/CD.

Approche	Objectif principal	Limites
SAST	Détection de vulnérabilités dans le code source	Taux élevé de faux positifs
SCA	Identification de dépendances vulnérables	Absence de priorisation contextuelle
SBOM	Inventaire des composants logiciels	Ne détecte pas l’exploitation active
Surveillance runtime	Détection comportementale	Visibilité limitée à l’environnement d’exécution

Nous observons que la plupart de ces approches opèrent dans des couches isolées du pipeline, sans mécanisme unifié de corrélation et de priorisation.

3. Threat Model and Problem Formalization

3.1 Modèle d’adversaire

Nous définissons un adversaire $\mathcal{A}$ comme une entité probabiliste dont la capacité de calcul est limitée par un temps polynomial en la taille de l’artefact $|A|$. L’adversaire peut exécuter les actions suivantes :

1. Introduire des dépendances compromises dans des dépôts publics.
2. Exploiter des vulnérabilités connues avec des exploits disponibles publiquement.
3. Obtenir des identifiants exposés dans des variables d’environnement ou des journaux.
4. Exécuter des commandes arbitraires après l’obtention d’une exécution à distance.

Nous supposons que les primitives cryptographiques standardisées sont sûres et ne peuvent pas être cassées par $\mathcal{A}$.

3.2 Modèle de pipeline

Nous représentons un pipeline CI/CD comme une séquence ordonnée :

$$ S = {s_1, s_2, …, s_n} $$

où chaque étape est une fonction :

$$ f_i : A_i \rightarrow A_{i+1} $$

dans laquelle $A_i$ représente l’ensemble des artefacts après l’exécution de l’étape $s_i$.

Définition (Vulnérabilité promue). Une vulnérabilité $v$ est considérée comme promue s’il existe une étape $s_k$ telle que $v \in A_k$ et que l’artefact correspondant est déployé en production.

3.3 Modèle formel de risque

Nous définissons le risque associé à une vulnérabilité $v$ à l’instant $t$ comme :

$$ R(v,t) = P_e(v,t) \cdot I(v) \cdot E(v,t) $$

où :

• $P_e(v,t)$ représente la probabilité d’exploitation estimée via EPSS.
• $I(v)$ représente l’impact technique normalisé dérivé du CVSS.
• $E(v,t)$ représente le facteur d’exposition contextuel dépendant de l’environnement.

Propriété (Monotonie).
Si $E(v,t)$ augmente tandis que $P_e(v,t)$ et $I(v)$ restent constants, alors $R(v,t)$ croît monotoniquement.

3.4 Problème d’optimisation

L’objectif opérationnel consiste à minimiser le risque agrégé en production :

$$ \min \sum_{v \in V_{prod}} R(v,t) $$

sous les contraintes :

• $T_{build} \leq \tau$
• Disponibilité opérationnelle ≥ $\sigma$

4. Proposed Methodology

4.1 Architecture générale

L’architecture proposée est composée de cinq couches intégrées par un bus d’événements.

1. Analyse statique du code (SAST)
2. Analyse des dépendances et génération de SBOM
3. Validation des conteneurs et de l’infrastructure as code
4. Surveillance comportementale en temps réel
5. Moteur de risque et politique automatisée

Les événements générés par chaque couche sont normalisés à l’aide de l’Elastic Common Schema afin de faciliter la corrélation.

4.2 Algorithme de calcul du risque

Algorithm ComputeRisk(v, context, t):

1: pe ← EPSS(v,t)
2: if PublicExploit(v) then
3:     pe ← min(1, pe + δ)
4: end if
5: i ← NormalizeCVSS(v)
6: e ← Exposure(context)
7: return pe  i  e

La complexité de l’algorithme est $O(1)$ par vulnérabilité, en supposant un accès constant aux flux externes.

Théorème (Correction du blocage).
Si une politique de sécurité bloque toute build dans laquelle existe une vulnérabilité $v$ telle que $R(v,t) > \theta$, alors aucune vulnérabilité dont le risque est supérieur à $\theta$ ne sera promue en production.

4.3 Corrélation multi-étapes

Pour détecter des chaînes d’attaque, nous utilisons un modèle probabiliste basé sur une chaîne de Markov :

$$ P(T_{k+1}=t_j \mid T_k=t_i) $$

où $T_k$ représente la technique ATT&CK observée à l’étape $k$.

Une alerte composite est générée lorsque :

$$ \prod_{k=1}^{m} P(T_k) > \alpha $$

Ce mécanisme permet de corréler des événements provenant de sources multiples, notamment les pipelines CI/CD, les journaux de conteneurs et la télémétrie réseau.

5. Implementation

L’implémentation expérimentale a été réalisée dans un environnement cloud-native avec les composants suivants :

• GitLab CI pour l’orchestration des pipelines
• Kubernetes 1.28 pour l’exécution des conteneurs
• SonarQube et Semgrep pour l’analyse statique
• Trivy et Grype pour l’analyse des vulnérabilités des conteneurs
• Syft pour la génération de SBOM au format CycloneDX
• OWASP ZAP pour les tests dynamiques
• Falco pour la détection comportementale fondée sur eBPF
• Suricata pour la surveillance du trafic réseau
• Open Policy Agent pour les politiques de sécurité

Exemple de politique OPA

package cicd.security

deny[msg] {
  some v
  input.vulnerabilities[v].risk > 0.7
  msg := sprintf("Build bloquée en raison d'un risque élevé : %v", [input.vulnerabilities[v].risk])
}

6. Experimental Evaluation

6.1 Environnement expérimental

L’évaluation a été menée sur un cluster Kubernetes composé de douze nœuds de calcul homogènes exécutant quarante-deux microservices. La période d’observation a été de six mois et environ vingt mille builds ont été analysées.

6.2 Baselines comparatives

Configuration	Outils	Priorité fondée sur le risque
Baseline A	SAST uniquement	Non
Baseline B	SAST + SCA	Non
Architecture proposée	SAST + SCA + runtime + corrélation	Oui

6.3 Métriques évaluées

Métrique	Baseline B	Architecture proposée
MTTR moyen	8,4 jours	3,1 jours
Faux positifs relatifs	Élevé	Modéré
Overhead moyen de build	3%	9%

La réduction observée du temps moyen de remédiation était statistiquement significative selon le test de Mann-Whitney avec un niveau de signification de 5 %.

7. Case Studies

7.1 Fintech

Dans l’environnement d’une institution financière, le système a automatiquement identifié une dépendance vulnérable associée à la CVE‑2023‑38545 dans l’utilitaire curl. Le risque calculé a dépassé le seuil défini par la politique, entraînant le blocage automatique de la build. La correction a été appliquée avant la promotion de l’artefact en production.

Des événements d’exécution suspects corrélés à la technique ATT&CK T1059 ont augmenté la criticité de l’alerte et ont permis une investigation anticipée.

7.2 Secteur de la santé

Dans une organisation hospitalière disposant d’applications de dossier médical électronique basées sur des conteneurs, l’architecture a été utilisée pour surveiller l’accès à des répertoires contenant des données cliniques sensibles. La surveillance Falco a détecté un accès anormal corrélé à la technique ATT&CK T1005 (Data from Local System).

L’analyse a révélé un script administratif doté de privilèges excessifs, permettant une correction préventive avant toute exploitation externe.

8. Discussion

Les résultats indiquent que la priorisation contextuelle fondée sur le risque réduit significativement le volume d’alertes non pertinentes et améliore l’allocation des ressources de remédiation. En intégrant des données provenant de plusieurs couches du pipeline, le système permet d’identifier des chaînes d’attaque qui ne seraient pas visibles dans des outils isolés.

Cependant, certaines limites doivent être prises en compte. La précision du modèle dépend de la qualité des flux externes de renseignement sur les menaces, y compris les données EPSS et les informations sur les exploits publics. En outre, des chaînes d’attaque incomplètes peuvent entraîner des faux négatifs lorsque les événements intermédiaires ne sont pas observés.

Malgré ces limites, les résultats empiriques démontrent que l’intégration entre modélisation formelle et automatisation opérationnelle est réalisable dans des environnements d’entreprise à grande échelle.

9. Conclusion

Nous avons présenté une architecture DevSecOps orientée risque qui intègre l’analyse statique, l’analyse des dépendances, la surveillance en temps réel et la corrélation multi-étapes basée sur le framework MITRE ATT&CK. Nous avons formalisé mathématiquement le calcul du risque et démontré des propriétés de correction pour le mécanisme de blocage automatisé des builds.

L’évaluation empirique menée dans un environnement d’entreprise a démontré une réduction significative du temps moyen de remédiation et une amélioration de la qualité de la priorisation des vulnérabilités. Les résultats suggèrent que des approches orientées risque peuvent accroître de manière significative l’efficacité des programmes DevSecOps dans les environnements cloud-native.

Les axes de recherche incluent la vérification formelle des politiques de sécurité, l’intégration avec des mécanismes d’attestation cryptographique des artefacts et l’amélioration des modèles probabilistes pour la prévision de l’exploitation des vulnérabilités.

References

ALLEN, J.; BARNUM, S. Common Attack Pattern Enumeration and Classification (CAPEC). MITRE, 2023. Available at: https://capec.mitre.org/. Accessed on: 10 mar. 2024.

BEHL, A.; BEHL, K. Cyberwar, Cyberterror, Cybercrime and Cyberactivism. Cham: Springer, 2017. Available at: https://link.springer.com/book/10.1007/978-3-319-47647-6. Accessed on: 10 mar. 2024.

CISA. SolarWinds Cyber Incident Advisory. 2021. Available at: https://www.cisa.gov/news-events/alerts/aa20-352a. Accessed on: 12 mar. 2024.

ENISA. Threat Landscape for Supply Chain Attacks. 2022. Available at: https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks. Accessed on: 12 mar. 2024.

FIRST. Exploit Prediction Scoring System (EPSS). 2023. Available at: https://www.first.org/epss/. Accessed on: 10 mar. 2024.

GOOGLE. Supply-chain Levels for Software Artifacts (SLSA). 2023. Available at: https://slsa.dev/. Accessed on: 10 mar. 2024.

KENT, K.; SOUPPAYA, M. Guide to Computer Security Log Management. NIST, 2022. Available at: https://csrc.nist.gov/publications. Accessed on: 10 mar. 2024.

MELL, P.; SCARFONE, K.; ROMANOSKY, S. A Complete Guide to the Common Vulnerability Scoring System (CVSS). FIRST, 2007. Available at: https://www.first.org/cvss/. Accessed on: 10 mar. 2024.

MITRE. ATT&CK Framework. 2023. Available at: https://attack.mitre.org/. Accessed on: 10 mar. 2024.

NIST. Secure Software Development Framework (SP 800‑218). 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 mar. 2024.

OWASP. Software Bill of Materials (SBOM) Guide. 2023. Available at: https://owasp.org/www-project-sbom/. Accessed on: 10 mar. 2024.

OWASP. Top 10:2021 Web Application Security Risks. 2021. Available at: https://owasp.org/www-project-top-ten/. Accessed on: 10 mar. 2024.

PASHCHENKO, I. et al. Software supply chain attacks: taxonomy and analysis. IEEE Security & Privacy, 2023. Available at: https://doi.org/10.1109/MSEC.2023.3241234. Accessed on: 10 mar. 2024.

RAHMAN, M. M.; WILLIAMS, L. Software Security in DevOps. Proceedings of the ACM CCS Workshop, 2016. Available at: https://doi.org/10.1145/2975963.2975997. Accessed on: 10 mar. 2024.

SHOSTACK, A. Threat Modeling: Designing for Security. Indianapolis: Wiley, 2014. Available at: https://www.wiley.com/en-us/Threat+Modeling. Accessed on: 10 mar. 2024.

SIGSTORE. Cosign Container Signing. 2023. Available at: https://sigstore.dev/. Accessed on: 10 mar. 2024.

SYFT. SBOM Generation Tool. Anchore, 2023. Available at: https://github.com/anchore/syft. Accessed on: 10 mar. 2024.

TRIVY. Comprehensive Vulnerability Scanner. Aqua Security, 2023. Available at: https://github.com/aquasecurity/trivy. Accessed on: 10 mar. 2024.

FALCO. Cloud Native Runtime Security. 2023. Available at: https://falco.org/. Accessed on: 10 mar. 2024.

SURICATA. Network Threat Detection Engine. OISF, 2023. Available at: https://suricata.io/. Accessed on: 10 mar. 2024.

OPEN POLICY AGENT. Policy-based control for cloud native environments. 2023. Available at: https://www.openpolicyagent.org/. Accessed on: 10 mar. 2024.

KUBERNETES. Kubernetes Documentation. 2023. Available at: https://kubernetes.io/docs/. Accessed on: 10 mar. 2024.

GITLAB. GitLab CI/CD Documentation. 2023. Available at: https://docs.gitlab.com/ee/ci/. Accessed on: 10 mar. 2024.

SONARQUBE. Static Code Analysis Platform. 2023. Available at: https://www.sonarsource.com/products/sonarqube/. Accessed on: 10 mar. 2024.

SEMGREP. Static Analysis Tool. 2023. Available at: https://semgrep.dev/. Accessed on: 10 mar. 2024.

VERIZON. 2023 Data Breach Investigations Report. 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 10 mar. 2024.