Votre première alerte en trois étapes.
Comptez dix minutes en tout, dont deux pour déclarer votre stack. Cette page décrit ce que vous faites ; la référence de l'API, elle, vit dans la documentation technique.
En une phrase
Déclarez ce que vous exploitez, réglez le seuil de bruit, branchez un canal : à partir de là, vous ne recevez plus que les vulnérabilités qui touchent vos composants.
1. Déclarez votre stack
Trois façons, au choix, et elles se combinent :
- Importer un SBOM (Software Bill of Materials, l'inventaire des composants produit par votre chaîne de build) au format CycloneDX ou SPDX. C'est la voie la plus fiable : les versions y sont exactes.
- Saisir à la main éditeur, produit et version. Comptez deux minutes pour une dizaine de composants.
- Détecter depuis une URL publique : nous identifions les technologies visibles, vous confirmez ou vous corrigez.
Chaque ligne est traduite en identifiant CPE (Common Platform Enumeration), la nomenclature qui nomme un produit et sa version dans le référentiel CVE. C'est cet identifiant qui permet le rapprochement automatique — et c'est aussi pour cela qu'une version approximative produit des alertes approximatives.
Le piège courant
Déclarer « PHP » sans version. Vous recevrez alors toutes les CVE de toutes
les branches, y compris celles que vous n'exploitez pas : exactement le bruit que vous
cherchiez à supprimer. Déclarez php 8.1.28, pas php.
2. Réglez le seuil de bruit
Par défaut, vous recevez tout ce qui touche votre stack. La plupart des équipes redescendent en deux temps : un seuil de sévérité — souvent CVSS ≥ 7 — et une exception qui laisse tout passer si la CVE figure au catalogue KEV de la CISA, c'est-à-dire si son exploitation est constatée dans la nature.
L'ordre compte. Le CVSS mesure la casse potentielle ; l'EPSS estime la probabilité d'exploitation sous trente jours ; le KEV constate. Pour comprendre ce que vous réglez, lisez ce que mesure vraiment le CVSS et ce qu'impose le catalogue KEV.
3. Branchez un canal
Slack et Microsoft Teams en OAuth, e-mail signé DKIM, webhook HTTP signé en HMAC. Un conseil issu de l'usage : envoyez le critique sur Slack et laissez le reste dans le brief quotidien. Si tout arrive en temps réel, l'équipe coupe les notifications au bout d'une semaine, et vous avez perdu le bénéfice.
Et ensuite : automatiser
Un workflow part d'un déclencheur (nouvelle CVE sur votre stack, preuve de concept publiée, entrée au KEV, fin de support qui approche), le filtre par des conditions, puis exécute des actions. Vous pouvez le tester à blanc sur une CVE réelle avant de l'activer.
Côté machine, l'API REST v1 expose les mêmes objets : alertes, base CVE, inventaire, dossiers, statistiques. Le plan Plus ouvre la lecture (GET), le plan Pro la lecture et l'écriture. Le cas d'usage le plus courant est un travail d'intégration continue qui refuse le déploiement tant qu'une CVE critique reste non traitée.
Référence complète de l'API et exemples curl, Python, JavaScript et GitHub Actions.
Ce que cette page ne dit pas
Elle décrit la mise en route, pas l'exploitation quotidienne. Nous n'avons pas encore publié de guide sur la tenue d'un registre de vulnérabilités ni sur la réponse à un audit. Si c'est ce que vous cherchez, dites-le nous : nous écrivons d'abord ce qu'on nous demande.