Alimenter sa stack

La stack d’un projet est la liste des éditeurs et produits que TechWatchAlert surveille pour vous. C’est elle qui détermine quelles CVE deviennent des alertes : tout part de là.

Note

L’API publique v1 est en lecture seule (GET /v1/organizations/{org_id}/projects/{id}/stack). L’alimentation se fait dans l’application, par les quatre chemins décrits ici. (Un rapport de scan déposé par la CI — POST …/scans — ne remplit pas la stack : il la confronte à ce qui est réellement installé.)

Avant même d’avoir un compte

La page Testez votre stack accepte un manifeste, un SBOM ou une liste « nom version » et montre en quelques secondes les failles connues de ces versions, les exploitées d’abord. Rien n’est conservé ; si vous créez ensuite un compte, les composants reconnus préremplissent la stack de votre premier projet, et les failles déjà publiées arrivent aussitôt dans vos alertes.

Quel chemin choisir ?

Vous avez…	Chemin	Précision des alertes
Une URL en production	Détecter depuis une URL	★★★ éditeur et version détectés
Un dépôt de code	Importer un manifeste	★★★ versions exactes des lockfiles
Un SBOM CycloneDX	Importer un SBOM	★★★ identifiants normalisés
Rien de tout ça	Recherche ou préréglage	★★ nom du produit seul

Les trois premiers renseignent un éditeur normalisé (issu d’un CPE) en plus du nom du produit. C’est ce qui permet d’écarter les CVE d’un homonyme : deux produits nommés nginx chez deux éditeurs différents ne déclenchent pas les mêmes alertes.

1. Rechercher

Le champ Ajouter à la stack cherche parmi les éditeurs et les produits en même temps — pas besoin de choisir le type à l’avance, il est affiché sur chaque résultat.

• Les résultats apparaissent dès le premier caractère tapé — pas avant : un palmarès affiché à champ vide n’a rien à voir avec ce que vous cherchez.
• Une ligne par produit, avec en dessous les éditeurs qui le publient. Ces libellés viennent des CVE, où le même éditeur s’écrit de dix façons (redhat, Red Hat, Inc., redhat.com) : ils vous situent le produit, mais ne servent pas de critère d’alerte.
• Le nombre de CVE connues donne une idée de l’exposition.
• Au clavier : ↑ ↓ pour naviguer, Entrée pour ajouter, , pour valider et enchaîner, Échap pour fermer, Retour arrière sur un champ vide pour retirer le dernier ajout.
• Le bouton ⓘ à droite du champ rappelle tout ça à la demande.

Ajouter un nom absent du catalogue

La dernière ligne de la liste propose toujours « Ajouter “votre saisie” ». Un produit qu’aucune CVE ne mentionne encore reste parfaitement surveillable — c’est même le seul moyen d’être alerté sur sa première CVE. Ces éléments portent un badge 0 CVE tant qu’aucune CVE ne les cite ; le badge disparaît de lui-même le jour où c’est le cas.

2. Coller une liste

Collez directement plusieurs noms séparés par des virgules, points-virgules, tabulations ou retours à la ligne — taper une virgule valide aussi l’entrée en cours :

nginx, openssl, postgresql, redis

Chaque nom devient une entrée. Elles sont ensuite rattachées automatiquement au catalogue pour récupérer l’éditeur quand le nom correspond exactement.

3. Importer un manifeste ou un SBOM

Importer un fichier accepte un SBOM CycloneDX (JSON ou XML) ou un manifeste de dépendances :

Écosystème	Fichiers reconnus
npm	package.json, package-lock.json, npm-shrinkwrap.json
PyPI	requirements*.txt, Pipfile.lock, poetry.lock
Go	go.mod
Composer	composer.json, composer.lock
Maven	pom.xml
RubyGems	Gemfile.lock
Cargo	Cargo.lock

Taille maximale : 5 Mo, 5 000 composants.

Versions : seules les versions exactes sont retenues

Une contrainte de plage (^4.17.21, >=2.0, ~1.2) ne dit pas ce qui est réellement installé. Enregistrer sa borne basse ferait taire des CVE qui s’appliquent — le pire des deux mondes. Ces composants sont donc importés sans version, c’est-à-dire surveillés sur toutes les versions.

Concrètement : un lockfile (package-lock.json, poetry.lock, Gemfile.lock, Cargo.lock, composer.lock) donne des versions exactes et donc des alertes précises. Un manifeste de premier niveau (package.json, composer.json) donne surtout des plages. Préférez le lockfile quand vous l’avez.

Écran de revue

Rien n’est enregistré avant votre validation. Chaque composant indique s’il est déjà cité par une CVE et s’il est déjà dans la stack. Les composants sans CVE connue sont décochés par défaut mais cochables — à vous de voir s’ils valent une surveillance.

4. Détecter depuis une URL

Détecter depuis une URL analyse les en-têtes et le HTML d’une page pour reconnaître les technologies servies. C’est le chemin le plus rapide et souvent le plus précis : les signatures rendent des CPE complets, donc éditeur et version pré-remplis.

Rien n’est enregistré : ni l’URL, ni les technologies, tant que vous n’avez pas validé l’écran de revue. Pour un suivi continu de la même URL, passez plutôt par URLs surveillées, qui rescanne périodiquement et peut alimenter la stack automatiquement.

Attention

Le scan est limité à 10 URL par tranche de 5 minutes et par compte. Les adresses privées (réseau local, loopback) sont refusées.

Préréglages

Sur une stack vide, six préréglages posent une base modifiable en un clic : Web PHP / LAMP, Node & front, Python, Java / JVM, Conteneurs & K8s, Poste de travail. Ils ne remplacent pas un inventaire réel, mais évitent la page blanche.

Régler le bruit

Deux réglages par élément, modifiables à tout moment depuis le tableau :

• Sévérité minimale — le seuil sous lequel aucune alerte n’est levée. Toutes remonte tout, Critique seulement le pire.
• Version — vide = toutes les versions. Renseignée, elle écarte les CVE dont les plages affectées ne la couvrent pas, ce qui réduit fortement le bruit.

Voir GET /v1/…/stack pour relire la stack depuis l’API.