logoChat01.ai

Projet de Fin d’Études Titre : Développement d’un...

Creado el: 19 de febrero de 2026

Respondido usando GPT-5.2 Thinking por Chat01

Pregunta

Projet de Fin d’Études

Titre : Développement d’une application basée sur l’IA qui permet de vérifier les serveurs affectés par une CVE donnée

Contexte du projet

L’entreprise gère un parc informatique composé de plusieurs serveurs, hébergeant des applications critiques et des services métiers. La gestion des vulnérabilités constitue un enjeu majeur afin de garantir la disponibilité, l’intégrité et la confidentialité des données.

Chaque jour, de nouvelles vulnérabilités sont publiées sous forme de CVE (Common Vulnérabilités and Exposures). L’analyse de ces CVE et l’identification des serveurs concernés au sein de l’infrastructure de l’entreprise sont actuellement réalisées de manière partiellement manuelle, reposant sur :

· La consultation de bases de données publiques (NVD, Niffler),

· L’analyse des descriptions techniques des CVE,

· La comparaison avec les configurations connues des serveurs.

Ce processus est long, répétitif et dépend fortement de l’expertise humaine, ce qui peut entraîner des retards dans la détection des failles critiques. Dans ce contexte, l’intégration de l’Intelligence Artificielle apparaît comme une solution innovante pour automatiser, fiabiliser et accélérer l’identification des serveurs vulnérables.

  1. Problématique

Plusieurs difficultés liées à la gestion des vulnérabilités :

· Le nombre élevé de CVE publiées régulièrement rend leur suivi complet difficile.

· Les descriptions des CVE sont souvent complexes, techniques et non standardisées.

· L’analyse manuelle nécessite des connaissances approfondies sur les systèmes, les versions logicielles et les configurations spécifiques des serveurs.

· Le temps de réaction entre la publication d’une CVE et l’identification des serveurs affectés peut être trop long, augmentant ainsi le risque d’exploitation.

Problématique principale :

Comment mettre en place, au sein de l’entreprise, une application intelligente capable d’analyser automatiquement une CVE donnée et de déterminer précisément quels serveurs de l’infrastructure sont réellement affectés, afin d’améliorer l’efficacité du processus de gestion des vulnérabilités.

  1. Objectifs du projet

Objectif général

L’objectif principal de ce projet est de concevoir et développer une application basée sur l’Intelligence Artificielle permettant d’automatiser l’identification des serveurs affectés par une CVE, afin d’assister les équipes IT.

Objectifs spécifiques

· Étudier le processus actuel de gestion des vulnérabilités au sein de l’entreprise et identifier ses limites.

· Concevoir une application capable de :

o Saisir ou importer une référence CVE,

o Récupérer et analyser automatiquement les informations associées à cette CVE.

· Appliquer des techniques d’IA (NLP / machine Learning) pour :

o Extraire les composants impactés (systèmes d’exploitation, services, versions, produits),

o Interpréter les descriptions techniques des CVE.

· Analyser les caractéristiques des serveurs de l’entreprise (inventaire, OS, versions, services).

· Mettre en place une corrélation intelligente entre les CVE et l’environnement réel des serveurs.

· Identifier et classifier les serveurs :

o Vulnérables,

o Non affectés,

o À vérifier manuellement.

· Développer une interface utilisateur facilitant :

o La visualisation des serveurs impactés,

o L’évaluation du niveau de risque,

o La proposition de recommandations (correctifs, mises à jour).

  1. Intérêt pour l’entreprise

La réalisation de ce projet permettra à l’entreprise de :

· Réduire le temps de détection des vulnérabilités critiques.

· Diminuer les erreurs humaines liées à l’analyse manuelle.

· Améliorer la réactivité face aux menaces de sécurité.

· Optimiser le travail des équipes IT et sécurité.

· Disposer d’un outil intelligent adapté à son infrastructure réelle.

Méthodologie

Phase 1 : Analyse de l’existant et étude des besoins

Cette phase consiste à comprendre le contexte opérationnel de l’entreprise et les pratiques actuelles en matière de gestion des vulnérabilités.

Les principales activités de cette phase sont :

· Étude de l’infrastructure informatique (serveurs, systèmes d’exploitation, services, applications).

· Analyse des outils actuellement utilisés pour la détection et le suivi des vulnérabilités.

· Identification des limites du processus existant (temps de réponse, erreurs, manque d’automatisation).

· Recueil des besoins fonctionnels et non fonctionnels auprès des équipes IT et sécurité.

· Définition du périmètre du projet et des contraintes (sécurité, performances, compatibilité).

Livrables :

· Document d’analyse des besoins

· Cahier des charges fonctionnel

· Diagramme de l’existant

Phase 2 : Étude technique et choix des technologies

Cette phase vise à définir l’architecture globale de la solution et à sélectionner les technologies les plus adaptées aux besoins du projet.

Les actions menées incluent :

· Étude des bases de données CVE (NVD, Niffler) et des formats de données associés.

· Analyse des techniques d’Intelligence Artificielle adaptées au projet (NLP, Mlflow,machine learning).

· Choix des outils et frameworks de développement (langages, bibliothèques IA, bases de données).

· Définition de l’architecture applicative (backend, frontend, moteur IA).

Livrables :

· Architecture technique de la solution

· Diagrammes UML (cas d’utilisation, composants)

· Justification des choix technologiques

Phase 3 : Collecte et préparation des données

Cette phase est essentielle pour garantir l’efficacité des modèles d’Intelligence Artificielle.

Elle comprend :

· Collecte des données CVE (descriptions, scores CVSS, produits affectés).

· Structuration et nettoyage des données textuelles.

· Extraction des informations clés (produits, versions, OS, services).

· Collecte des informations techniques des serveurs de l’entreprise (inventaire).

· Normalisation des données afin de faciliter la phase de corrélation.

Livrables :

· Base de données CVE structurée

· Dictionnaires de données

· Jeu de données prêt pour l’analyse IA

Phase 4 : Conception et développement du moteur intelligent

Dans cette phase, le cœur du projet est développé.

Les travaux réalisés incluent :

· Implémentation des algorithmes de NLP pour l’analyse des descriptions des CVE.

· Développement du moteur de corrélation intelligent entre les CVE et les serveurs.

· Mise en place d’un système de classification des serveurs (vulnérable / non vulnérable / à vérifier.

Pensamiento

Refining plan for user methodology and Niffler clarification

It seems "Niffler" refers to various unrelated projects, not a vulnerability database. In the write-up, I’ll avoid referencing "Niffler," unless it’s an internal tool. Instead, I'll suggest using NVD, MITRE CVE, and other resources. I’ll help the user finish their methodology phases and propose the architecture in French, focusing on data ingestion, correlation, and AI integration using tools like CVSS, KEV, EPSS, and RAG with LLM.

Proposing UML diagrams, tech stack, and KPIs for methodology

I’ll describe the UML diagrams and tech stack, including Python with FastAPI, Postgres, Elastic, and a vector DB (pgvector). I’ll incorporate ML tools like spaCy and transformers, along with CI/CD, security practices, and KPIs like precision/recall for detecting vulnerabilities, model metrics, and human-in-the-loop. I'll also prepare data, map CVEs to CPEs, and use synthetic labels for training. Refine the problem statement and propose a solution approach with deliverables and timeline.

Proposing Phase 4 continuation and architecture proposal

I’ll continue from Phase 4 and address Phases 5-7, proposing a detailed architecture and plan. I’ll specify ML methods like NER for extracting products and versions, mapping to a CPE dictionary, and combining rule-based with ML approaches. I'll also cover the real configuration impact, using configuration management or agentless scanning for evidence collection. I’ll define both functional and non-functional requirements, including security, performance, and integration considerations. All external facts are cited, like NVD and CISA KEV.

Proposing Phase 4 with deliverables and corrections

I’ll suggest components for the project, like the data collector, inventory connector, NLP engine, correlation engine, UI, and authentication. Then, I'll outline deliverables for Phase 4—such as the NLP and correlation modules, classification model, and API. For Phase 5, I'll cover application development, followed by testing and deployment in Phases 6 and 7. I'll also suggest evaluation through offline testing with historical CVEs and user feedback. A small correction: CVE stands for "Common Vulnerabilities and Exposures," not "Vulnernabilités."

Thought for 1m 26s

Respuesta

Voici une proposition de complétion + structuration (prête à être intégrée dans ton document de PFE) : architecture cible, approche IA, et suite de la méthodologie (phases 4 → 7) avec livrables et critères d’évaluation.

1) Ajustements utiles au cadrage (pour un PFE plus “solide”)

  • Sources CVE : pour la donnée “référence”, cite clairement CVE.org (MITRE) et NVD (NIST). Le NVD est le dépôt gouvernemental US qui fournit les infos exploitables pour l’automatisation (CVE, CPE, CVSS, etc.). (NVD)
  • Accès technique aux CVE : privilégier l’API NVD 2.0 (plutôt que du scraping), qui fournit les objets CVE dans une structure JSON standard. (NVD)
  • Point clé “réellement affecté” : le matching “produit/version” ne suffit pas toujours. Certaines CVE nécessitent des conditions de configuration (feature activée, option précise, module chargé, exposition réseau…). Ton application doit donc produire un statut + une preuve + un niveau de confiance.

2) Architecture fonctionnelle proposée (simple, claire, défendable)

A. Ingestion & Normalisation

  1. Entrée utilisateur : CVE-ID (ex: CVE-2025-xxxx) ou import CSV.

  2. Collecte CVE :

    • NVD API (détails, CVSS, références, CPE/configurations). (NVD)
    • (Optionnel) Data feeds NVD pour mise à jour locale/quotidienne si besoin d’autonomie. (NVD)
    • (Optionnel) CISA KEV pour savoir si c’est exploité “in the wild” (priorisation). (CISA)
    • (Optionnel) OSV pour dépendances open-source, si votre parc inclut beaucoup de libs. (OSV)

  3. Normalisation :

    • Normaliser produits/versions vers un format pivot (ex: CPE quand possible).
    • Exploiter les CPE Applicability Statements (logique AND/OR, versions, exclusions) quand elles existent. (cve.org)

B. Inventaire serveurs (ground truth interne)

  • Connecteurs (selon ce qui existe en entreprise) :
    • CMDB / inventaire,
    • Ansible facts / scripts SSH,
    • agents EDR (si dispo),
    • parsing de “installed packages” (rpm/dpkg), services, versions, OS kernel, middleware.
  • Sortie inventaire : pour chaque serveur → OS, packages, versions, services actifs, configurations clés, tags (prod/dev), criticité.

C. Moteur IA + Corrélation (le “cœur”)

  • NLP/IA : extraction d’entités (produit, version, composant, condition).
  • Règles + matching CPE : matching déterministe quand le NVD fournit des CPE/configurations fiables.
  • Raisonnement “conditions” : quand la CVE dépend d’une option (ex: “si VerifyHostKeyDNS est activé…”), générer une checklist et chercher des indicateurs côté serveur.
  • Classification finale :
    • Vulnérable (preuve forte),
    • Non affecté (preuve forte),
    • À vérifier (incertitude / manque de données / condition non vérifiée).

D. Restitution

  • Dashboard : liste serveurs impactés + filtre (criticité, environnement, score).
  • Fiche CVE : résumé, conditions, preuves trouvées, recommandations (patch/workaround), liens officiels.

3) Approche IA recommandée (réaliste pour un PFE)

Tu peux vendre une approche hybride (très crédible en cybersécurité) :

  1. Baseline déterministe (très important)
  • Si la CVE a des CPE/configurations dans NVD : parser l’arbre AND/OR + versions + exclusions (c’est très défendable académiquement). (cve.org)
  • Matching inventaire → CPE (ou mapping package → produit).
  1. NLP (NER + normalisation)
  • Objectif : quand les CPE sont absents / incomplets, extraire depuis le texte :
    • produit, éditeur, module, version range, OS, prérequis.
  • Techniques :
    • spaCy/Transformers (NER),
    • règles d’extraction de versions (regex robustes),
    • dictionnaire synonymes (OpenSSH vs openssh-server, etc.).
  1. Scoring de confiance (très utile en entreprise)
  • Ex : 0–100% basé sur :
    • correspondance produit/version,
    • preuve de service actif,
    • preuve de config impactée,
    • qualité/complétude des données inventaire.

4) Complétion de ta méthodologie (Phase 4 → Phase 7)

Phase 4 : Conception & développement du moteur intelligent (complétée)

Activités

  • Implémentation du parsing CVE (API NVD) + stockage local (BD). (NVD)
  • Extraction automatique :
    • entités : produit / version / composant / OS / condition,
    • conversion vers format pivot (CPE si possible). (cve.org)
  • Développement corrélation :
    • matching CPE ↔ inventaire,
    • gestion des plages de versions,
    • règles “conditions de vulnérabilité” (features, options).
  • Classification : vulnérable / non affecté / à vérifier + score confiance.
  • Génération d’explications :
    • “Pourquoi ce serveur est marqué vulnérable ?”
    • “Quelle preuve manque pour trancher ?”

Livrables

  • Moteur NLP (extraction + normalisation)
  • Moteur de corrélation (règles + scoring)
  • Schéma BD + pipeline d’ingestion CVE
  • API interne (endpoints : /cve/{id}, /servers, /assessment)

Phase 5 : Développement de l’application (backend + frontend)

Activités

  • Backend (ex: FastAPI / Spring Boot) :
    • endpoints de recherche CVE, lancement analyse, export (CSV/PDF).
  • Frontend (ex: React/Angular) :
    • écran “CVE → serveurs affectés”
    • écran “serveur → CVE qui le touchent”
    • filtres + tri (criticité, KEV, CVSS).
  • Authentification/autorisation (SSO si possible), audit logs.

Livrables

  • Application web fonctionnelle
  • Documentation API (OpenAPI/Swagger)
  • Maquettes + parcours utilisateur

Phase 6 : Tests, validation et évaluation

Activités

  • Tests unitaires : parsing NVD, extraction versions, matching.
  • Tests d’intégration : pipeline complet CVE → classification.
  • Validation métier (avec équipe sécu/ops) sur un set de CVE réelles.
  • Évaluation IA (si tu as un dataset de vérité terrain) :
    • précision, rappel, F1 sur “serveur vulnérable”.
  • Mesure gain opérationnel :
    • temps moyen avant/après,
    • réduction du “manuel”.

Livrables

  • Rapport de tests + résultats
  • Jeu de CVE de validation + scénarios
  • Tableau de métriques (précision/rappel + temps gagné)

Phase 7 : Déploiement, sécurité et documentation

Activités

  • Déploiement (Docker/K8s ou VM) + CI/CD
  • Stratégie mise à jour CVE (API périodique / feeds)
  • Sécurité :
    • chiffrement secrets,
    • RBAC,
    • journalisation,
    • minimisation des données exposées (inventaire).
  • Documentation finale + guide utilisateur + guide admin.

Livrables

  • Guide déploiement + exploitation
  • Dossier sécurité (menaces, mesures)
  • Rapport final PFE + manuel utilisateur

5) Bonus “pro” : priorisation du risque (facultatif mais très apprécié)

Ajoute un module de priorisation basé sur :

  • CVSS (impact technique),
  • KEV CISA (exploité activement). (CISA)
    Tu obtiens un score “corrigé” orienté production : Critique et exploité ≠ Critique mais théorique.

6) Attention à un point dans ton texte : “Niffler”

Le terme Niffler ne correspond pas, dans les sources publiques, à une base CVE reconnue (on trouve surtout des projets logiciels sans lien direct avec les vulnérabilités). Si c’est un outil interne à ton entreprise, garde-le. Sinon, remplace par : NVD, CVE.org, CISA KEV, OSV, etc. (GitHub)

Si tu veux, je peux aussi te proposer :

  • un cahier des charges fonctionnel structuré (acteurs, UC, exigences NFR),
  • une architecture technique (schéma composants + flux),
  • et une trame de rapport PFE (chapitres + contenu attendu).

Compartir este Q&A