Les failles de votre logiciel, suivies jusqu'à leur correction
Votre logiciel s'appuie sur des dizaines de bibliothèques. À chaque scan, nous comparons leurs versions exactes aux bases publiques de vulnérabilités, et relevons les paquets abandonnés par leur mainteneur.
Le rapport montre ce qui reste à corriger, ce qui a été corrigé, et en combien de temps.
Rapport de sécurité des dépendances
Votre application
21 septembre 2026
espace-clientÀ corriger
PHPcomposer.lock
1 Critique1 Faible
JavaScriptpnpm-lock.yaml
Ce que montre le rapport
Une mesure que vous pouvez croire
Corrigé, c'est constaté
Une fois la correction livrée, un nouveau scan du dépôt vérifie que la faille a disparu. C'est lui qui la donne corrigée : la date et le délai depuis sa détection sont mesurés, pas déclarés.
Une faille toujours présente au scan suivant garde sa date de détection : le délai continue de courir.
Rapport de sécurité des dépendances
Votre application
MoyenneTwig : exécution de code dans le mode bac à sable
- Paquet
twig/twig v3.10.2- Référence
CVE-2026-29105- Détectée le
- 14 sept. 2026
- Corrigée le
- 24 sept. 2026
- Délai
- 10 jours
Les paquets abandonnés
Une bibliothèque abandonnée par son mainteneur ne recevra plus de correctif : la prochaine faille découverte y restera. Le rapport la relève comme un point à traiter, au même titre qu'une vulnérabilité.
Rapport de sécurité des dépendances
Votre application
frontÀ corriger
JavaScriptpackage-lock.json
1 Haute1 Moyenne1 Abandonné
Les versions exactes, pas les intentions
Pour affirmer qu'une bibliothèque est vulnérable, il faut connaître sa version exacte. Elle est écrite dans le fichier de verrouillage du dépôt : sans lui, les versions installées sont inconnues, et le rapport le dit plutôt que de conclure.
C'est le dernier commit du dépôt qui est analysé, et le rapport l'affiche : vous savez quelle version de votre logiciel a été vérifiée.
Rapport de sécurité des dépendances
Votre application
back-officeAnalyse incomplète
PHPcomposer.lock
JavaScriptpackage.json
Échec
Un échec se voit
Un dépôt que le scan n'a pas pu lire s'affiche en échec, avec sa raison. Un cas réel nous l'a appris : un outil d'audit s'arrêtait sans rien analyser, et le dépôt paraissait sain alors qu'il portait plus d'une centaine de vulnérabilités hautes.
Depuis, un silence ne vaut jamais « rien à corriger » : il faut la preuve que l'analyse est allée au bout.
Rapport de sécurité des dépendances
Votre application
extranetÉchec du scan
site-vitrineRien à corriger
Le déroulé
D'une faille détectée à sa correction constatée
- 1
Scan régulier
Tous les dépôts du projet sont scannés à la fréquence prévue par votre contrat de maintenance.
- 2
Points à corriger
Chaque faille et chaque paquet abandonné sont relevés, par dépôt et par langage, avec leur gravité.
- 3
Mise à jour
L'équipe met à jour les bibliothèques concernées et livre la correction.
- 4
Vérification
Un nouveau scan du dépôt confirme la disparition du point : il passe à « corrigé », daté.
Les outils
Les technologies derrière ce rapport
Dépendances
Composer
Le gestionnaire de dépendances de PHP. Son audit compare les versions exactes du fichier de verrouillage aux avis de sécurité publiés et relève les paquets abandonnés.
Dépendances
npm, Yarn, pnpm
Les gestionnaires de paquets de JavaScript. Leurs audits relèvent les failles connues, le registre npm signale les paquets dépréciés par leur mainteneur.
Dépendances
OSV-Scanner
Le scanner de Google, adossé à la base ouverte OSV. Il relève les failles connues des images Docker qui font tourner votre application, système compris.
Vos dépôts
GitLab
La plateforme où vit votre code. smartplatform.cloud lit vos dépôts par son API : rien n'est installé ni exécuté sur votre code.
Questions fréquentes
Faut-il un compte pour lire le rapport ?
Non. Le rapport s'ouvre par un lien de partage, que vous pouvez transmettre à un associé, un auditeur ou un autre prestataire. Ce lien peut être révoqué.
Quels langages sont analysés ?
PHP, avec Composer, et JavaScript, avec npm, Yarn ou pnpm. Un dépôt écrit dans un autre langage est affiché « non analysable » plutôt que passé sous silence. Les images Docker qui font tourner votre application sont aussi contrôlées, avec OSV-Scanner.
Et un dépôt qui n'est pas maintenu par SmartBooster ?
Il est scanné comme les autres, et son rapport porte la mention « Dépôt non géré par SmartBooster ». Vous mesurez tout votre parc de la même façon.
Que veulent dire CVE et gravité ?
Une CVE est l'identifiant public d'une faille, sa gravité celle publiée avec elle. Nous les expliquons sur smartbooster.io : CVE, CWE, CVSS : nommer, noter et prioriser une faille.
Ce que vous aimeriez vérifier sur vos dépendances
Dites-nous ce qui vous manque pour suivre la sécurité de vos logiciels : vos besoins orientent les prochains outils de la plateforme.