Surveiller les dépendances de vos logiciels en PME : la méthode en une semaine

Vous êtes responsable informatique, CTO d'une petite équipe ou développeur à qui l'on a confié « la sécurité ». Un client vient d'envoyer un questionnaire, un auditeur arrive dans deux mois, ou vous avez simplement lu un article sur une attaque par la chaîne d'approvisionnement. Vous voulez mettre en place une surveillance sérieuse des dépendances, sans équipe sécurité et sans y passer vos soirées.

Voici une méthode en cinq jours, à raison d'une à deux heures par jour. Elle marche avec des outils open source seuls ou avec un service comme Lysbor, qui automatise les étapes 2 à 5.

Le principe est celui d'un carnet de santé. Jour 1, on liste les patients. Jour 2, on fait le bilan. Jour 3, on décide des soins. Jour 4, on installe le suivi automatique. Jour 5, on écrit les règles et on sait les montrer à l'inspecteur.

Jour 1 : faire la liste de ce qui tourne

Avant de surveiller, il faut savoir quoi surveiller. Listez dans un tableau :

• chaque application ou service en production, et son dépôt de code ;
• son langage et son gestionnaire de paquets (npm, pip, Maven, Go…) ;
• s'il est livré en image de conteneur, et dans quel registre ;
• un responsable technique.

Vérifiez que chaque dépôt contient un lockfile commité. Sans lui, les versions exactes ne sont pas connues et rien de sérieux n'est possible. C'est souvent la première correction à faire.

Jour 2 : le premier bilan

Générez un SBOM par application, ou utilisez directement les lockfiles, et confrontez-les à une base de vulnérabilités. Options :

• en ligne de commande, avec des scanners open source comme OSV-Scanner, Grype ou Trivy ;
• sans rien installer, en déposant un lockfile sur la page de test de Lysbor, qui donne en trente secondes les vulnérabilités, les paquets malveillants et un plan de correction.

Ne vous affolez pas du nombre. Un premier bilan affiche souvent plusieurs dizaines de vulnérabilités par application, dont la plupart ne sont pas urgentes.

Jour 3 : trier et corriger l'urgent

Appliquez une règle de priorisation simple :

1. Paquet malveillant : retrait immédiat et renouvellement des secrets exposés.
2. Vulnérabilité exploitée (catalogue KEV) : correction cette semaine.
3. Critique ou élevée avec probabilité d'exploitation notable (EPSS) : correction ce mois-ci.
4. Le reste : planifié avec les montées de version régulières.

Raisonnez par mise à jour plutôt que par vulnérabilité : une seule montée de version d'un framework ferme souvent une dizaine de failles. Faites les deux ou trois mises à jour qui retirent le plus de risque, testez, livrez.

Pour ce que vous ne corrigez pas tout de suite, notez une décision : pourquoi, qui décide, jusqu'à quand.

Jour 4 : automatiser la surveillance

C'est l'étape qui transforme un audit ponctuel en protection durable.

1. Génération automatique du SBOM à chaque build : notre tutoriel CI donne les fichiers pour GitHub Actions et GitLab CI.
2. Confrontation quotidienne à une base à jour, même quand le code ne bouge pas : de nouvelles vulnérabilités sont publiées tous les jours.
3. Alertes ciblées : seulement sur ce qui est nouveau, avec la version corrigée, dans le canal où l'équipe travaille déjà (Slack, Teams, e-mail). Une alerte qui répète chaque jour les mêmes 80 lignes finit ignorée.
4. Contrôle des nouvelles dépendances avant la fusion : un paquet malveillant ou publié il y a quelques heures ne doit pas entrer sans vérification.

Avec des outils open source, ces briques demandent de l'assemblage (planification, stockage de l'historique, déduplication des alertes). Avec Lysbor, c'est un envoi de lockfile ou une ligne dans la CI, et l'essai de 14 jours suffit à tout mettre en place.

Jour 5 : écrire les règles et préparer la preuve

Rédigez une page, pas plus :

• le périmètre : les applications de la liste du jour 1 ;
• les sources : base OSV, catalogue KEV, scores EPSS ;
• les délais de correction par niveau, par exemple 7 jours pour une critique, 30 pour une élevée, 90 pour une moyenne, immédiat pour une vulnérabilité exploitée ou un paquet malveillant ;
• les exceptions : qui peut accepter un risque, pour combien de temps, avec quelle justification ;
• la revue : un point mensuel de 15 minutes sur les indicateurs.

Cette page, avec l'historique automatique des détections et des corrections, répond à l'essentiel de ce qu'un client, un assureur ou un auditeur NIS2 ou ISO 27001 demandera sur vos composants logiciels.

Et ensuite : 15 minutes par semaine

Une fois en place, la surveillance ne doit pas devenir un travail à temps partiel :

• lire la synthèse hebdomadaire des nouvelles vulnérabilités ;
• traiter les alertes urgentes au fil de l'eau ;
• vérifier une fois par mois que les délais sont respectés et que les exceptions arrivées à échéance sont revues.

Si cela prend plus de temps, c'est souvent le signe d'un outil trop bruyant ou d'une règle de priorisation trop large.

Budget indicatif

Questions fréquentes

Combien de temps faut-il pour mettre en place une surveillance des dépendances ?

Avec un service hébergé, moins d'une heure pour les premiers projets, et une semaine pour faire les choses proprement (inventaire, tri initial, automatisation, politique écrite). Avec des outils open source à assembler, comptez plusieurs jours de plus.

Faut-il une équipe sécurité ?

Non. La méthode est pensée pour être tenue par un responsable technique ou un développeur référent. L'automatisation fait le travail répétitif, l'humain décide des priorités et des exceptions.

Comment recevoir les alertes de vulnérabilités rapidement ?

En confrontant vos inventaires chaque jour à une base à jour et en envoyant les nouveautés dans le canal que l'équipe lit déjà (Slack, Teams, e-mail). Lysbor le fait chaque nuit ou plus souvent selon l'offre, et n'envoie que ce qui est nouveau, avec la version corrigée.

Que faire si un client demande la preuve de notre suivi ?

Lui transmettre votre politique d'une page et un rapport daté : inventaire, vulnérabilités ouvertes, tendance, délais de correction, décisions justifiées. Le rapport PDF de posture de Lysbor est conçu pour cet usage.