Premiers pas, et les questions qui reviennent

Dans la console, « Nouveau scan ». Déposez le lockfile de votre logiciel : package-lock.json (ou npm-shrinkwrap.json), pnpm-lock.yaml, yarn.lock, ou un SBOM CycloneDX au format JSON. Quatre mégaoctets au plus. Le dépôt demande un compte.

euvex en tire la nomenclature logicielle, le SBOM, cherche dans OSV.dev les vulnérabilités connues de chaque composant, et enregistre le résultat sous une adresse secrète. Le fichier déposé n'est pas conservé : seule la nomenclature l'est.

L'adresse d'alerte est préremplie avec celle du compte. Une autre adresse reçoit d'abord un lien de confirmation, et rien d'autre tant qu'elle ne l'a pas suivi.

Sur la page d'un scan, la colonne « Couverture » dit sur combien de composants la question des vulnérabilités a pu être posée : la ligne « interrogés », N sur M. Elle donne leur sens aux autres chiffres : « vulnérables 0 » ne veut rien dire tant qu'on ne sait pas sur combien on a cherché.

Un composant est interrogé quand une source sait le résoudre : OSV.dev par son identifiant de paquet, le purl, dès le dépôt ; la NVD par CPE, pour ceux qu'OSV ne résout pas, lors des revérifications programmées : toutes les dix minutes pendant les quarante-huit heures qui suivent le dépôt tant qu'un composant attend, puis chaque jour. Ceux qu'aucune source n'a pu interroger restent « non analysé » : souvent un purl qu'OSV n'indexe pas, comme pkg:generic ou pkg:conan, sans CPE ni version exacte pour la NVD, ou aucun identifiant du tout.

Un produit est une version d'une gamme. La gamme, celle qui porte le marquage CE, se reconnaît à son nom : deux versions de même nom forment une seule gamme.

Dans « Produits », section « Déclarer un produit » : un nom, une version, et, si vous l'avez, un scan choisi parmi ceux du compte qui ne sont rattachés à aucun produit, ou son identifiant, celui qui apparaît dans l'adresse du scan. Sur la page d'un scan non rattaché, « Déclarer ce produit » ouvre ce formulaire déjà rempli. Un scan se rattache aussi plus tard, depuis la fiche du produit, section « Scan logiciel », ou en déposant un scan depuis cette fiche : il remplace alors le scan actuel. Un produit porte un seul scan.

Chaque scan est revérifié une fois par jour : OSV.dev d'abord, puis la NVD pour les composants qu'OSV ne sait pas résoudre. Une vulnérabilité nouvelle entre dans « Alertes CVE », quel que soit le réglage.

Le « Seuil d'alerte » des réglages décide quels emails partent : toutes les sévérités, élevée et plus, ou critique seulement. Une sévérité inconnue passe tous les seuils, parce qu'elle n'est pas une sévérité basse. Le seuil filtre les emails, jamais la boîte d'alertes.

L'email part à l'adresse d'alerte du scan, une fois qu'elle a le droit de recevoir : celle du compte quand le compte est confirmé, une autre quand elle a suivi son lien de confirmation. Chaque email porte un lien de désabonnement.

L'article 14 du CRA demande au fabricant de signaler une vulnérabilité activement exploitée de son produit, ou un incident grave, selon trois échéances. Pour chaque cas, euvex ouvre un dossier, tient le décompte et prépare le contenu des rapports, avec un dossier imprimable.

Ouverture automatique : quand un composant du scan rattaché à un produit figure au catalogue CISA KEV des vulnérabilités activement exploitées. Le croisement a lieu à la création du produit avec un scan, au rattachement, au dépôt depuis la fiche du produit, et à chaque revérification quotidienne. L'adresse du compte, si elle est confirmée, en reçoit l'avis par email. Ouverture à la main, depuis le volet art. 14 du produit, pour un incident ou une vulnérabilité que le catalogue ne connaît pas.

Toutes les questions, et le glossaire des termes employés ici.