Radar de dépendances · Projets GitLab et GitHub
DevWatcher lit les fichiers de verrouillage de vos projets GitLab et GitHub, demande à OSV ce qui touche chaque paquet à la version exacte installée, puis rédige ce que la mise à jour apporte, ce qu’elle coûte et par quoi commencer. Trié par gravité : la question du matin n’est pas « qu’est-ce qui s’est passé », c’est « je commence par quoi ».
Accès réservé aux comptes du domaine synertechweb.com et aux adresses explicitement autorisées.
Bandes de gravité · CVSS
lodash · affecté : >=4.0.0 <4.17.21 · corrigé en 4.17.21
toNumber, trim et trimEnd s’effondrent sur une chaîne construite pour ça : le temps de traitement part en vrille et le processus cesse de répondre.
Action recommandée
Monter à 4.17.21. Correctif de sécurité sans rupture d’API — la montée se fait dans le fichier de verrouillage, pas dans le code.
Projet touché
boutique-web · installé : 4.17.20
Une exécution par nuit
Déclenchée à 10:00 UTC, soit 06:00 à Montréal l’été. Cinq étapes, dans cet ordre, et chacune refuse de deviner à la place de la précédente.
Lit les fichiers de verrouillage, jamais les seuls manifestes : la plupart des vulnérabilités vivent dans les dépendances que personne n’a demandées. Le chemin complet est conservé.
Interroge OSV paquet par paquet, à la version exacte installée, puis les registres pour ce qui a pris du retard et les flux que vos dépendances justifient. Une requête de sécurité qui échoue fait échouer la collecte : une panne annoncée « zéro vulnérabilité » se lirait comme une bonne nouvelle.
Projette la collecte dans le radar. Repasser sur un inventaire inchangé ne crée rien, ne rajeunit aucune date de détection et ne touche à aucun statut posé à la main.
Un modèle rédige le résumé, les gains, les coûts et l’action. Chaque affirmation porte le numéro d’une source ; celles dont les numéros ne tombent pas juste sont écartées.
Au réveil, la liste est triée par gravité, et un digest part à l’heure que vous fixez avec ce qui est nouveau — rien d’autre. Un élément collecté mais pas encore rédigé le dit : une file d’attente annoncée se lit comme une file d’attente, une section vide comme une page cassée.
Première exécution complète, mesurée : 4 projets · 2 332 lignes d’inventaire · 122 avis · 122 éléments créés · 40 rédigés · 256 s
Ce que vous obtenez
Un manifeste liste ce que vous avez demandé ; un fichier de verrouillage liste ce qui est réellement installé, transitives comprises. Neuf formats sont lus, et un projet qui n’en a aucun vous le dit au lieu de rester silencieux.
Savoir qu’une dépendance est vulnérable ne dit pas s’il faut y toucher ce matin. Chaque élément porte donc ce que la montée de version apporte, ce qu’elle risque de casser, l’action recommandée et l’effort. Toute affirmation renvoie à une source numérotée ; celle qu’aucune source ne soutient n’est pas publiée.
Les jetons GitLab et GitHub sont chiffrés au repos sous une clé qui leur est propre, jamais réaffichés, jamais journalisés, et aucun appel à une forge ne part du navigateur. Le texte d’un élément est rédigé sans qu’aucun nom de projet n’atteigne le modèle : un élément est partagé entre les comptes qui le subissent, et les projets sont rattachés à l’affichage.
Sources
Deux questions distinctes, qu’il serait commode de confondre. Une source branchée est une source que le pipeline interroge. Une source citée est un lien qu’un avis porte — et un lien vers le NVD ne veut pas dire que le NVD a été interrogé.
GitHub Security Advisories · NVD (NIST)
| Niveau | Ce que c’est | Ce qu’il a le droit de faire |
|---|---|---|
| 1 | AutoritéOSV.dev, API GitLab, API GitHub, GitHub Security Advisories, NVD (NIST), CISA KEV, endoflife.date, Registres de paquets, Santé des dépendances | Peut appuyer une affirmation |
| 2 | Officielle éditorialeNotes de version, Flux officiels | Peut appuyer une affirmation |
| 3 | Signal communautaireHacker News, Lobste.rs | Peut seulement proposer un candidat |
| 4 | Newsletters | Peut seulement proposer un candidat |
Questions
Le domaine synertechweb.com, plus une liste d’adresses autorisées quelle que soit leur provenance — avec Google, ou avec une adresse et un mot de passe. La règle est vérifiée deux fois : à la création du compte, et à chaque ouverture de session — un compte créé quand son domaine était permis cesse d’ouvrir des sessions le jour où il ne l’est plus. Un compte à mot de passe n’en ouvre aucune avant que son adresse soit confirmée, puisque n’importe qui peut taper une adresse du domaine. Une variable vide retombe sur le domaine par défaut, jamais sur « tout le monde ».
Dans la base, chiffré sous une clé distincte de celle qui signe les sessions — les deux ne tournent pas au même rythme. Il n’est jamais réaffiché : seuls les quatre derniers caractères restent lisibles, de quoi reconnaître quel jeton a été collé et rien d’autre. Il voyage dans un en-tête et jamais dans une URL, et aucun appel à une forge ne part du navigateur. Côté GitHub, seul un jeton à portée fine est accepté : un jeton classique ne lit un dépôt privé qu’avec une portée qui permet aussi d’y écrire.
Non. Un même avis touche plusieurs comptes, il est donc analysé une fois et partagé : la consigne envoyée au modèle ne contient aucun nom de projet, et les projets touchés sont rattachés à l’affichage, dans le périmètre du lecteur. Deux tests le vérifient — l’un sur la consigne construite, l’autre sur le corps de la requête réellement envoyée.
Il vous le dit. Activer un projet donne l’un de quatre verdicts : fichier trouvé, manifeste seul, rien de reconnu, ou accès refusé. Un manifeste seul n’est pas inventorié à moitié — annoncer une fraction en ayant l’air complet est pire que ne rien annoncer. Et un verdict peut être redemandé depuis la ligne du projet, parce qu’un jeton qui a brièvement perdu l’accès laisserait sinon une erreur d’apparence définitive.
Un jeton d’accès personnel en lecture suffit. Les dépôts que le jeton atteint sont listés ; ceux que vous cochez sont inspectés sur-le-champ, et vous savez immédiatement lesquels peuvent être surveillés.