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.
Le guide d'utilisation complet
Chaque écran de l'application expliqué pas à pas, avec captures annotées et gros plans : compte, stack, alertes et leur traitement, workflows, rapports, conformité NIS2, administration de l'équipe et Espace partenaire. Ouvrir le guide d'utilisation.
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.
Déclarer « PHP » sans sa version
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, Microsoft Teams et Discord par l'URL de webhook entrant du canal, 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. Elle est incluse dans les offres Team et Enterprise, en lecture, avec une exception : votre intégration continue peut y déposer ses rapports de scan. 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.