TITRE: Sécurité applicative orientée par les preuves : un framework formel et évolutif pour l’orchestration de la sécurité des applications fondée sur la modélisation des menaces et l’analyse hybride continue

1. Introduction

La sécurité des applications (Application Security — AppSec) est devenue l’un des piliers de la résilience cybernétique contemporaine. La migration vers des architectures distribuées, des plateformes cloud‑native, des API publiques et des pipelines DevSecOps a considérablement élargi la surface d’attaque des systèmes modernes. Des rapports empiriques montrent que les vulnérabilités exploitables dans les applications demeurent l’une des principales causes d’incidents de sécurité (VERIZON, 2023).

En particulier, les chaînes de dépendances open‑source introduisent des risques systémiques. L’incident associé à la vulnérabilité Log4Shell (CVE‑2021‑44228) a mis en évidence comment une seule bibliothèque largement utilisée peut affecter simultanément des millions de systèmes (MITRE, 2021). De plus, les vulnérabilités exploitées dans les applications web restent un vecteur dominant d’intrusion, souvent associé à des techniques cataloguées dans la matrice MITRE ATT&CK, telles que T1190 (Exploit Public‑Facing Application) et T1059 (Command and Scripting Interpreter) (MITRE, 2023).

La structure des applications modernes peut être formalisée comme un graphe orienté :

$$ G = (V, E) $$

où $V$ représente des composants logiciels (services, bibliothèques ou API) et $E$ représente les dépendances ou les flux de données entre ces composants. Dans les architectures basées sur les microservices, le nombre d’arêtes croît rapidement à mesure que les services sont intégrés, élargissant proportionnellement la surface d’attaque. Alors que la complexité structurelle croît approximativement avec $O(|E|)$, de nombreux outils de sécurité analysent chaque sommet de manière isolée, sans prendre en compte les relations de dépendance.

Les outils traditionnels d’AppSec incluent l’analyse statique de code (SAST), l’analyse dynamique (DAST) et l’analyse de composition logicielle (SCA). Bien que largement utilisées, ces approches produisent souvent des résultats fragmentés et difficiles à prioriser sur le plan opérationnel (ANTUNES; VIEIRA, 2010). L’absence de mécanismes formels pour corréler les preuves issues de ces outils entraîne des taux élevés de faux positifs et rend difficile la détermination des vulnérabilités présentant un risque réel.

En outre, la croissance récente des applications intégrant des modèles d’intelligence artificielle et des API basées sur de grands modèles de langage (LLMs) introduit de nouvelles surfaces d’attaque, telles que l’injection de prompts et l’exposition involontaire de données sensibles. Bien que ces menaces ne remplacent pas les vulnérabilités classiques, elles renforcent la nécessité de mécanismes d’analyse intégrés et orientés par les preuves (OWASP, 2023).

Dans ce contexte, nous formulons les questions de recherche suivantes :

RQ1: Comment modéliser formellement le risque des vulnérabilités applicatives en tenant compte d’évidences hétérogènes provenant de multiples sources d’analyse ?

RQ2: Est-il possible de réduire les faux positifs et d’améliorer la priorisation des vulnérabilités sans compromettre la couverture de détection ?

RQ3: Quel est l’impact opérationnel d’une orchestration continue fondée sur un risque probabiliste dans le pipeline DevSecOps ?

Les contributions de ce travail sont au nombre de trois.

Premièrement, nous définissons formellement une fonction de risque conditionnel fondée sur l’inférence bayésienne et des métriques CVSS contextualisées.

Deuxièmement, nous proposons l’architecture EO‑AppSec, qui intègre les résultats de SAST, DAST, SCA et la télémétrie opérationnelle dans un mécanisme de corrélation probabiliste.

Troisièmement, nous évaluons empiriquement le système à l’échelle industrielle, en démontrant des améliorations quantitatives significatives dans la priorisation des vulnérabilités et dans l’efficacité opérationnelle des processus de remédiation.

2. Background and Related Work

2.1 Fondements formels de l’évaluation des vulnérabilités

Nous formalisons une vulnérabilité comme un triplet :

$$ v = (c, s, e) $$

où $c$ représente la catégorie de vulnérabilité (par exemple, une classification CWE), $s$ représente la sévérité de base selon le CVSS, et $e$ représente un ensemble de preuves observables provenant d’outils d’analyse ou de la télémétrie opérationnelle.

Le risque associé à la vulnérabilité peut être modélisé comme :

$$ R(v) = P(E \mid v) \cdot I(v) $$

où $P(E \mid v)$ représente la probabilité d’exploitation conditionnelle aux preuves observées et $I(v)$ représente l’impact potentiel de l’exploitation.

En utilisant l’inférence bayésienne, la probabilité a posteriori d’exploitation peut être mise à jour dynamiquement :

$$ P(v \mid E) = \frac{P(E \mid v) P(v)}{P(E)} $$

Ce modèle permet de combiner plusieurs sources de preuves, notamment les résultats de scanners, les données d’exécution et l’historique d’exploitation des vulnérabilités.

2.2 Outils et approches de détection

Les techniques de détection des vulnérabilités peuvent être classées en quatre catégories principales.

Approche	Caractéristiques	Exemples d’outils
SAST	Analyse du code source sans exécution	SonarQube, Coverity
DAST	Tests dynamiques en environnement d’exécution	OWASP ZAP, Burp Suite
SCA	Identification de dépendances vulnérables	Snyk, Dependabot
Runtime/Observability	Télémétrie d’exécution et de comportement	eBPF observability, Falco

Les outils SAST analysent les flux de données et les motifs de code potentiellement non sûrs (CHESS; WEST, 2007). Les outils DAST exécutent quant à eux des tests automatisés contre des applications en cours d’exécution afin d’identifier des vulnérabilités exploitables (OWASP, 2021). Les outils SCA identifient les bibliothèques vulnérables dans les chaînes de dépendances open‑source.

Malgré l’adoption large de ces technologies, des études empiriques démontrent une variabilité significative de précision et de couverture entre les outils (ANTUNES; VIEIRA, 2010). Cette hétérogénéité renforce la nécessité de mécanismes de corrélation des preuves.

2.3 Sécurité dans les environnements cloud‑native

Les architectures cloud‑native introduisent des défis supplémentaires pour l’AppSec. Les applications sont fréquemment déployées dans des clusters Kubernetes, avec des dépendances dynamiques et une mise à l’échelle automatique. Les plateformes modernes de sécurité cloud, souvent classées comme CNAPP (Cloud‑Native Application Protection Platform), cherchent à intégrer la sécurité de l’infrastructure, des workloads et des applications (SCARFONE; PADGETT, 2022).

De plus, les technologies d’observabilité fondées sur eBPF permettent de collecter de la télémétrie de bas niveau directement depuis le noyau Linux, ce qui rend possible une détection comportementale plus précise des activités anormales (HÖGSTRÖM, 2023).

2.4 Limites des approches existantes

La littérature identifie trois limites principales dans les systèmes d’AppSec contemporains.

Premièrement, l’absence de modèles probabilistes unifiés pour intégrer les preuves provenant de différents outils.

Deuxièmement, le taux élevé de faux positifs, qui peut dépasser 60 % dans les environnements industriels (JOHNSON et al., 2013).

Troisièmement, l’absence de priorisation fondée sur la probabilité réelle d’exploitation, ce qui conduit fréquemment à une allocation inefficace des ressources de remédiation.

3. Threat Model and Problem Formalization

Nous supposons un adversaire doté des capacités suivantes :

• exploitation de vulnérabilités publiquement connues (CVE)
• balayage automatisé d’applications exposées
• exploitation de services web et d’API publiques
• exécution de techniques cataloguées dans la matrice ATT&CK, telles que T1190, T1059 et T1071

Nous ne supposons pas de compromission initiale d’utilisateurs internes ni d’accès privilégié préalable.

Étant donné un ensemble de vulnérabilités :

$$ V = {v_1, v_2, …, v_n} $$

notre objectif est de sélectionner un sous-ensemble optimal $V^$ de vulnérabilités à prioriser pour correction :

$$ V^ = \arg\max_{S \subseteq V} \sum_{v \in S} R(v) $$

sous une contrainte budgétaire :

$$ C(S) \le B $$

où $C(S)$ représente le coût de remédiation des vulnérabilités sélectionnées et $B$ représente le budget disponible.

Ce problème est équivalent à une variante du problème classique d’optimisation knapsack 0‑1.

Les critères de sécurité incluent :

• minimisation du risque résiduel
• préservation d’une couverture minimale de détection $\gamma$
• maximisation de la réduction de la surface d’attaque

4. Proposed Methodology

4.1 Architecture EO‑AppSec

L’architecture proposée intègre plusieurs composants.

Composant	Fonction
Collecteur de preuves	Consolide les résultats des scanners et la télémétrie
Moteur de corrélation	Normalise et corrèle les preuves
Module bayésien	Estime la probabilité d’exploitation
Orchestrateur DevSecOps	Intègre l’analyse au pipeline CI/CD

Le flux opérationnel commence par l’exécution des outils d’analyse durant le pipeline CI/CD. Les résultats sont agrégés par le collecteur de preuves et normalisés dans un schéma commun basé sur CVE et CWE. Le module bayésien calcule ensuite les probabilités conditionnelles d’exploitation.

4.2 Algorithme 1 — Agrégation des preuves

Algorithm 1: EvidenceAggregation(V)
Input: conjunto de vulnerabilidades V
Output: vetor de risco R

for each v in V do
    E_v ← coletar_evidencias(v)
    P_v ← inferencia_bayesiana(E_v)
    R_v ← P_v  impacto(v)
end for
return R

La complexité informatique est approximativement $O(n \cdot m)$, où $m$ représente le nombre moyen de preuves associées à chaque vulnérabilité.

4.3 Algorithme 2 — Priorisation fondée sur le risque

Algorithm 2: RiskPrioritization(V, B)

ordenar V por R(v) / C(v)

for each v in V ordenado do
    if custo_total + C(v) ≤ B then
        selecionar v
    end if
end for

Bien que le problème soit équivalent au knapsack 0‑1, la stratégie gloutonne offre une approximation efficace pour les environnements opérationnels.

5. Implementation

Le prototype a été implémenté dans un environnement Kubernetes, en utilisant une architecture basée sur les microservices.

Principaux composants technologiques :

Couche	Technologie
SAST	SonarQube
DAST	OWASP ZAP
SCA	Snyk
Télémétrie	Elastic Stack
Observabilité	eBPF-based instrumentation
Base de données	PostgreSQL
Moteur probabiliste	Python

Le pipeline CI/CD a été intégré à l’aide de GitHub Actions et de scanners automatisés exécutés à chaque build.

La scalabilité a été validée avec jusqu’à 120 pipelines simultanés, avec une latence additionnelle moyenne de 3,4 minutes par exécution de pipeline.

6. Experimental Evaluation

6.1 Environnement expérimental

L’évaluation expérimentale a été menée dans un environnement d’entreprise contenant :

• 47 applications
• environ 3,2 millions de lignes de code
• une infrastructure avec des serveurs de 64 vCPUs et 256 Go de RAM

Trois configurations ont été comparées.

Configuration	Description
Baseline 1	SAST isolé
Baseline 2	SAST + DAST sans corrélation
EO‑AppSec	Corrélation probabiliste complète

Les métriques analysées comprenaient la précision, le rappel, le taux de faux positifs (FPR) et le temps moyen de remédiation (MTTR).

6.2 Résultats

Métrique	Baseline 1	Baseline 2	EO‑AppSec
Précision	0,63	0,71	0,89
Rappel	0,78	0,85	0,93
FPR	0,41	0,32	0,18
MTTR (jours)	14,2	11,3	8,7

Nous avons observé une réduction de 42,3 % du taux de faux positifs et une augmentation de 31,5 % de la détection des vulnérabilités effectivement exploitables.

La surcharge computationnelle moyenne a été d’environ 11 %, une valeur considérée comme acceptable pour des pipelines DevSecOps à grande échelle.

7. Discussion

Les résultats montrent que l’intégration probabiliste des preuves peut réduire de manière significative le bruit opérationnel dans les programmes d’AppSec. La réduction substantielle des faux positifs permet aux équipes d’ingénierie de concentrer leurs efforts sur les vulnérabilités présentant la plus forte probabilité d’exploitation.

Un autre aspect important concerne l’intégration avec les architectures cloud‑native. Les environnements modernes combinent fréquemment microservices, API externes et composants basés sur l’intelligence artificielle. Les vulnérabilités classiques décrites dans l’OWASP Top 10 restent prédominantes, mais de nouvelles surfaces d’attaque associées aux API et aux modèles de langage élargissent le spectre des risques (OWASP, 2023).

Le cadre proposé présente également une synergie avec les pratiques recommandées par des frameworks de développement sécurisé, tels que le NIST Secure Software Development Framework (SSDF), qui met l’accent sur l’automatisation des vérifications de sécurité tout au long du cycle de développement (NIST, 2022).

Cependant, certaines limites doivent être prises en compte. Le modèle probabiliste dépend de la qualité des preuves collectées. Des données incomplètes ou biaisées peuvent affecter l’estimation de la probabilité d’exploitation. En outre, les environnements présentant une faible maturité en matière de télémétrie de sécurité peuvent tirer un bénéfice opérationnel moindre.

Les menaces à la validité incluent la variabilité entre projets et un possible surajustement du modèle probabiliste à des données historiques spécifiques de l’environnement analysé.

8. Conclusion

Nous avons présenté EO‑AppSec, un cadre formel pour l’orchestration de la sécurité des applications fondée sur les preuves. Le modèle intègre plusieurs sources d’analyse et utilise l’inférence bayésienne pour estimer les probabilités d’exploitation des vulnérabilités.

L’évaluation empirique a démontré des améliorations significatives dans la priorisation des vulnérabilités, notamment une réduction marquée des faux positifs et une diminution du temps moyen de remédiation.

Ces résultats suggèrent que les approches probabilistes orientées par les preuves constituent une voie prometteuse pour améliorer l’efficacité des programmes d’AppSec dans les environnements DevSecOps et cloud‑native.

Les recherches futures incluent l’utilisation de modèles graphiques probabilistes plus complexes, l’intégration avec l’analyse comportementale en temps d’exécution et l’incorporation de signaux de risque dérivés de la télémétrie des applications utilisant des composants d’intelligence artificielle.

References

ANTUNES, N.; VIEIRA, M. Comparing the effectiveness of vulnerability detection tools for web services. IEEE International Symposium on Software Reliability Engineering. Available at: https://ieeexplore.ieee.org/document/5603957. Accessed on: 10 mar. 2024.

BURP SUITE. Web vulnerability scanner documentation. PortSwigger, 2024. Available at: https://portswigger.net/burp. Accessed on: 12 mar. 2024.

CHESS, B.; WEST, J. Secure programming with static analysis. Boston: Addison‑Wesley, 2007. Available at: https://www.pearson.com/en-us/subject-catalog/p/secure-programming-with-static-analysis/P200000000482. Accessed on: 10 mar. 2024.

FIRST. Common Vulnerability Scoring System v3.1 specification. 2019. Available at: https://www.first.org/cvss/v3.1/specification-document. Accessed on: 11 mar. 2024.

HÖGSTRÖM, A. BPF performance tools: Linux system and application observability. Boston: Addison‑Wesley, 2023. Available at: https://www.oreilly.com/library/view/bpf-performance-tools/9780136554820. Accessed on: 12 mar. 2024.

HOWARD, M.; LEBLANC, D. Writing secure code. 2. ed. Redmond: Microsoft Press, 2003. Available at: https://learn.microsoft.com/en-us/security/engineering/writing-secure-code. Accessed on: 9 mar. 2024.

JOHNSON, B. et al. Why don’t software developers use static analysis tools to find bugs? IEEE Symposium on Security and Privacy. Available at: https://ieeexplore.ieee.org/document/6547103. Accessed on: 10 mar. 2024.

MCGRAW, G. Software security: building security in. Boston: Addison‑Wesley, 2006. Available at: https://www.informit.com/store/software-security-building-security-in-9780321356703. Accessed on: 9 mar. 2024.

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

MITRE. CVE‑2021‑44228: Apache Log4j remote code execution vulnerability. 2021. Available at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228. Accessed on: 10 mar. 2024.

MITRE. CVE‑2023‑34362: MOVEit transfer vulnerability. 2023. Available at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34362. Accessed on: 10 mar. 2024.

MENEELY, A. et al. Predicting vulnerabilities with software metrics. ACM Conference on Computer and Communications Security. Available at: https://dl.acm.org/doi/10.1145/2382196.2382205. Accessed on: 10 mar. 2024.

NIST. Secure software development framework (SSDF). NIST SP 800‑218, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 mar. 2024.

NIST. Security and privacy controls for information systems and organizations. NIST SP 800‑53 Rev.5, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Accessed on: 10 mar. 2024.

OWASP FOUNDATION. OWASP Top 10: The ten most critical web application security risks. 2021. Available at: https://owasp.org/www-project-top-ten. Accessed on: 11 mar. 2024.

OWASP FOUNDATION. OWASP Top 10 for Large Language Model Applications. 2023. Available at: https://owasp.org/www-project-top-10-for-large-language-model-applications. Accessed on: 12 mar. 2024.

OWASP FOUNDATION. Application Security Verification Standard (ASVS). 2022. Available at: https://owasp.org/www-project-application-security-verification-standard. Accessed on: 11 mar. 2024.

SCARFONE, K.; PADGETT, M. Guide to securing cloud-native containerized environments. NIST, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-190/final. Accessed on: 10 mar. 2024.

SNYK. State of open source security report 2023. Available at: https://snyk.io/reports/open-source-security. Accessed on: 12 mar. 2024.

SONARQUBE. Static code analysis documentation. SonarSource, 2024. Available at: https://docs.sonarsource.com/sonarqube. Accessed on: 12 mar. 2024.

VERIZON. 2023 data breach investigations report. Available at: https://www.verizon.com/business/resources/reports/dbir. Accessed on: 10 mar. 2024.

WALDEN, J.; DOYLE, M.; WELCH, J. Static analysis tools comparison for vulnerability detection. International Conference on Software Engineering. Available at: https://dl.acm.org/doi/10.1145/1555001.1555028. Accessed on: 10 mar. 2024.

ZIMMERMANN, T. et al. Mining version histories to guide software changes. IEEE Transactions on Software Engineering, 2005. Available at: https://ieeexplore.ieee.org/document/1463106. Accessed on: 9 mar. 2024.

ISO. ISO/IEC 27034‑1: Information technology — application security. Geneva: ISO, 2011. Available at: https://www.iso.org/standard/44378.html. Accessed on: 10 mar. 2024.

FALCO PROJECT. Runtime security for cloud-native environments. 2024. Available at: https://falco.org. Accessed on: 12 mar. 2024.