Centre de sécurité

Analyse locale des dépendances, du code, des fuites de mémoire et des conditions de concurrence, sans envoyer votre code nulle part.

Le Centre de sécurité effectue une analyse locale du projet, sans envoyer votre code nulle part. Les sources en ligne et la revue par IA sont facultatives et s’activent séparément.

Comment l’ouvrir

Barre latérale droite → Plus d'outils → Centre de sécurité (« Constats et secrets »).
Palette de commandes (Ctrl+Shift+A) : Centre de sécurité (vulnérabilités, fuites, courses).
Depuis l’onglet Prévention du panneau Qualité.

Cliquez sur Analyser le projet la première fois, puis sur Relancer l’analyse après des modifications.

Onglets

Onglet	Contenu
Résumé	L’état général et les constats les plus importants.
Dépendances	Bibliothèques présentant des vulnérabilités connues ou non maintenues.
Code	Vulnérabilités dans le code du projet.
Mémoire et concurrence	Fuites de ressources et conditions de concurrence.
Licences	Licences des dépendances.
Revue par IA	Une analyse facultative par le modèle, que vous activez avec Analyse par IA.

Dépendances

Sources de vulnérabilités

Dans Options → Sources de vulnérabilités :

Source	État	Ce qui est envoyé
Base locale de Yuli	Toujours active	Rien. Fonctionne hors ligne, avec les CVE connues des bibliothèques Java courantes (Struts, Log4j, commons, Spring, Jackson…), les composants non maintenus et les licences.
OSV.dev	Désactivée par défaut	Uniquement le groupe, l’artefact et la version de chaque dépendance.
OWASP Dependency-Check	Facultatif	Utilise une installation locale.

Avec la seule base locale, l’analyse est entièrement hors ligne. Activez OSV.dev si vous souhaitez consulter en plus GitHub Advisory et NVD.

Portée

Inclure le code de test.
Inclure les jars du serveur.

Code

L’analyse du code couvre Java, JSP, web.xml et les descripteurs Hibernate.

Catégorie	Exemples
Injection	SQL construit avec des données de la requête.
XSS	Sortie non échappée dans les JSP ou les servlets.
Désérialisation non sûre	Objets lus depuis des sources non fiables.
XXE	Parseurs XML non protégés.
Cryptographie faible	Algorithmes obsolètes.
TLS	Gestionnaires qui font confiance à n’importe quel certificat.
Redirections ouvertes	Destinations tirées de la requête.
Secrets	Identifiants écrits dans le code ou affichés dans les logs.

Un modèle de contamination (taint) par méthode suit les valeurs provenant de la requête (getParameter, getHeader, cookies) et des ActionForm de Struts. Lorsqu’un constat reçoit des données de l’utilisateur, sa confiance et sa gravité augmentent.

Mémoire et concurrence

Fuites

Connexions JDBC ou flux non fermés.
ThreadLocal sans remove().
Caches statiques qui croissent sans limite.
Threads qui ne s’arrêtent jamais.

Conditions de concurrence

État partagé dans les Servlets, les Actions Struts et les singletons.
SimpleDateFormat statique.
Double-checked locking.
Motifs check-then-act.

Pour confirmer une fuite à l’exécution, utilisez le panneau JVM : un histogramme mémoire répété montre quelles classes grossissent. Voir Exécuter et déboguer.

Où les rapports sont enregistrés

Dans le dossier .yuli/security/ du projet, que Yuli exclut de Git.

Prévention dans l’éditeur

En plus du Centre de sécurité, Yuli vérifie chaque fichier en direct pendant que vous écrivez et après chaque modification de l’agent : OWASP Top 10, CWE, performances, robustesse et accessibilité. Les constats apparaissent soulignés avec leur référence et la manière de les corriger. Voir Mesure par rapport à N−1.

SBOM et chaîne d’approvisionnement

La nomenclature logicielle (SBOM) se génère dans le Centre de gouvernance, onglet Chaîne d'approvisionnement, avec Écrire le SBOM. Formats : CycloneDX 1.5 JSON et SPDX 2.3 JSON. Voir Gate et Centre de gouvernance.

Avec l’agent

L’agent peut consulter le Centre de sécurité avec les outils yuli_security_center et yuli_security_scan, et proposer des corrections qui passent par la fenêtre de modifications comme toutes les autres.