VulnBeacon
Demander un accès

Identifiez les risques de vos logiciels. Priorisez les correctifs. Maîtrisez vos mises en production.

VulnBeacon est une plateforme de sécurité de la chaîne logicielle et de veille sur les vulnérabilités, pour les équipes de sécurité produit et d’ingénierie responsables des logiciels que leur organisation construit et reçoit de ses fournisseurs. Elle relie l’inventaire que vos outils produisent déjà aux décisions de sécurité que votre équipe doit prendre. Commencez avec un SBOM, un fichier de verrouillage pris en charge ou la sortie d’un scanner.

Demander un accès Explorer les capacités

Utilisez l’espace de travail web, connectez votre chaîne d’intégration, ou interrogez votre assistant IA.

  1. Vous

    Crée la nomenclature logicielle (SBOM) du projet sur lequel je travaille et vérifie-la avec VulnBeacon. Puis-je le mettre en production ?

  2. Assistant

    Ce SBOM respecte la politique de mise en production configurée pour Checkout service. À faire ensuite : passez Django 5.2.13 en 5.2.17, ce qui lève 15 constats.

    • Mettre à jourDjango 5.2.13 → 5.2.17lève 15
    • Mettre à joururllib3 2.2.1 → 2.8.0lève 9
    • Mettre à joursqlparse 0.5.3 → 0.6.0lève 6
  3. Comment l’assistant a répondu4 appels, 6,0 s

    1. cyclonedx-py requirements requirements.txt --of JSON -o sbom.cdx.json

      Nomenclature sbom.cdx.json générée avec cyclonedx-py à partir de requirements.txt : 26 composants.

      2,1 s

    2. upload_sbom product_id: 1, sbom: sbom.cdx.json, branch: main

      Téléversé comme génération 1 : 26 composants, l’analyse en file.

      144 ms

    3. product_gate product_id: 1

      Franchie : évaluée, aucune règle enfreinte.

      280 ms

    4. product_remediation product_id: 1

      8 composants à traiter. Django 5.2.13 vers 5.2.17 lève 15 constats.

      131 ms

Barrière franchie

Enregistrée sur un projet d’exemple, un service de commande Django de 26 composants : l’assistant a créé sa nomenclature, l’a téléversée et a lu le verdict. Chaque ligne est la réponse du produit.

Ce que vous pouvez en faire

Vous utilisez déjà un scanner ? Il produit l’inventaire. VulnBeacon le relie à une veille à jour, identifie les produits touchés, priorise le travail, suit la remédiation et produit les preuves qui fondent votre décision de mise en production.

Découvrir un exemple d’évaluation de produit : un produit fictif de son inventaire à son rapport, avec les fichiers à ouvrir.

Un incident, du début à la fin

  1. Une vulnérabilité est annoncée
  2. Trouver les produits touchés
  3. Choisir le correctif
  4. Suivre le travail
  5. Revérifier la mise en production
  6. Partager les preuves

Quand une nouveauté tombe, sachez ce qu’elle touche

Une vulnérabilité fait l’actualité, ou un paquet se révèle malveillant. Posez une seule question à tout ce que vous livrez, et obtenez la réponse depuis vos propres inventaires.

Un incident, sur tous les produits

Donnez à VulnBeacon une CVE ou l’un de ses alias, un nom de paquet ou un purl. Il répond quels produits l’embarquent, quel composant à quelle version, si la fiche figure au catalogue KEV et si un correctif existe. La page d’une fiche liste aussi vos produits touchés, et l’API comme l’assistant donnent la même réponse.

Vos logiciels ne changent pas. Leurs risques connus, si.

Quand la base change, les inventaires déjà envoyés sont de nouveau confrontés, puis encore chaque nuit. Un nouveau constat apparaît sans nouvelle construction, son échéance comptée depuis le jour où il a été vu pour la première fois.

  1. Vous

    CVE-2026-67320 fait l’actualité. Lesquels de nos produits l’embarquent ?

  2. Assistant

    3 de vos 11 produits embarquent CVE-2026-67320 : Patient Portal (axios 1.16.0, corrigé en 1.18.0), Atlas Storefront (axios 1.16.0, corrigé en 1.18.0) et Platform Worker Image (axios 0.32.0, corrigé en 0.33.0). Une version corrigée existe pour 3 d’entre eux.

    • Patient Portalélevéeaxios 1.16.0correctif disponible
    • Atlas Storefrontélevéeaxios 1.16.0correctif disponible
    • Platform Worker Imageélevéeaxios 0.32.0correctif disponible
  3. Comment l’assistant a répondu1 appel, 97 ms

    1. incident_impact cve_id: CVE-2026-67320

      3 produit(s) touché(s) sur 11, 3 avec un correctif disponible.

      97 ms

Enregistrée sur des produits d’exemple : une seule question, posée à tous, et la réponse vient de leurs inventaires.

Où se concentre le risque de vos produits

La page Produits classe tout ce que vous livrez, du pire au meilleur : la note, les constats ouverts, ce qui est exploité ou malveillant, la barrière de publication et ce qui a bougé cette semaine. Elle s’imprime en rapport pour celles et ceux qui n’étaient pas dans la salle.

La page Produits : tous les produits classés du pire au meilleur, avec au-dessus la répartition des gravités et des notes, et pour chaque produit sa note, ses constats ouverts, son indicateur KEV ou malveillant, le résultat de sa barrière de publication et ce qui a bougé cette semaine.
Produits : chaque produit du pire au meilleur, avec ce qui est bloqué et ce qui a bougé cette semaine.

Votre liste de veille

Nommez les produits et les paquets qui vous importent. Une nouvelle fiche qui les cite, une version corrigée, une inscription au catalogue KEV : chacune vous parvient à la cadence que vous choisissez, dans l’application, par e-mail ou par vos intégrations. La base elle-même est mise à jour selon le calendrier fixé par votre administrateur.

La liste de veille : les noms suivis, les fiches qui les citent, celles inscrites au catalogue KEV, et ce qui a changé pour eux, du plus récent au plus ancien.
La liste de veille : les noms que vous suivez, et ce qui a changé pour eux.
L’écran Alertes : nouveaux constats, changements de fiches et événements de politique, chacun avec son produit, sa gravité et son heure.
Les alertes : ce qui a changé pour vos produits, au même endroit.

Un seul envoi, toute la décision de mise en production

Envoyez un SBOM CycloneDX ou SPDX, un fichier de verrouillage pris en charge, un CSV de composants ou ce que Syft, Trivy ou Grype ont produit, ou laissez la chaîne d’intégration le faire. Tout ce qui suit est calculé à partir de ce seul fichier et de la base, et chaque chiffre s’ouvre sur les faits qui le fondent. Quand un document déclare des actifs cryptographiques, des services ou des modèles d’IA, ils sont inspectés aussi. Les produits visibles sur ces écrans sont des produits de démonstration sur notre propre instance ; la base et ses chiffres sont réels.

Une note, avec ses raisons

Chaque produit reçoit une lettre de A à F. Elle pèse la nature des constats, pas leur nombre : un constat déjà exploité activement et un paquet malveillant dans l’inventaire la font baisser plus que tout. La lettre s’ouvre sur la liste de ce qui l’a fait bouger, et chaque constat porte son échéance SLA et sa version corrigée.

L’étape Constats d’un produit bloqué à la barrière de publication : la bande d’ancienneté des échéances, puis chaque constat avec sa gravité, sa fiche, son EPSS, son composant, sa version corrigée et son statut, les paquets malveillants en tête.
Les constats d’un produit bloqué, les paquets malveillants en tête.

D’une liste de constats à un travail que vous pouvez suivre

Une longue liste de constats ne dit à personne quoi faire lundi matin. Le plan la transforme en mises à jour, les classe selon ce que chacune lève, et les suit dans vos prochaines constructions.

Un plan de remédiation priorisé

Les constats sont regroupés par la mise à jour qui les ferme, et les mises à jour sont classées selon ce que chacune lève : la première ligne est par où commencer. Quand aucune version corrigée n’existe encore, le plan le dit au lieu de laisser un blanc. Un paquet malveillant est marqué à retirer, puisqu’il n’y a rien vers quoi mettre à jour.

Voir l’effet avant de vous engager

Cochez les mises à jour envisagées : le plan projette la note qu’elles laisseraient et les règles de la barrière de publication qu’elles lèveraient.

Tickets et campagnes

Créez un ticket Jira ou ServiceNow pour une mise à jour, avec ses constats joints, ou regroupez-en plusieurs dans une campagne. Chaque nouvelle génération de SBOM montre quelles mises à jour d’une campagne ont bien abouti, sans que personne ait à demander.

Note projetée pour trois mises à jour sélectionnées : de D à 48,7 aujourd’hui à C à 24,6 ensuite, 30 constats levés.
Cochez les mises à jour prévues : la note qu’elles laisseraient et les constats qu’elles lèvent.
Une campagne de remédiation de trois mises à jour dont une aboutie : la progression indique 1 sur 3, le statut ouvert.
Une campagne sur un produit d’exemple : une mise à jour arrivée dans le dernier SBOM, deux encore à venir.

Demander par où commencer

L’assistant lit le même verdict et le même plan : chacun dans l’équipe peut demander pourquoi une mise en production est bloquée et quoi faire d’abord.

  1. Vous

    Pourquoi la barrière de publication bloque-t-elle Platform Worker Image, et que faut-il corriger d’abord ?

  2. Assistant

    La barrière de publication bloque Platform Worker Image. Règles enfreintes : paquets malveillants (eslint-plugin-restart-vega-soap@1.0.0, py-infopullhydra@1.0.0). Retirez d’abord eslint-plugin-restart-vega-soap@1.0.0 et py-infopullhydra@1.0.0 : aucune mise à jour ne lève un paquet malveillant. Ensuite, passez openssl 3.0.19-1~deb12u2 en 3.0.20-1~deb12u2, ce qui lève 9 constats. Vérifiez de nouveau la mise en production ensuite.

    • Retirereslint-plugin-restart-vega-soap@1.0.0
    • Retirerpy-infopullhydra@1.0.0
    • Mettre à jouropenssl 3.0.19-1~deb12u2 → 3.0.20-1~deb12u2lève 9
  3. Comment l’assistant a répondu3 appels, 1,4 s

    1. list_products

      11 produits.

      131 ms

    2. product_gate product_id: 10

      Bloquée : max_malicious.

      1,2 s

    3. product_remediation product_id: 10

      6 composants à traiter. openssl 3.0.19-1~deb12u2 vers 3.0.20-1~deb12u2 lève 9 constats.

      125 ms

Barrière bloquée

Enregistrée sur le produit d’exemple Platform Worker Image : le verdict de la barrière et les premières lignes du plan.

Les mêmes règles, avant qu’une modification soit fusionnée

Une pull request qui ajoute une dépendance est le moment le moins coûteux pour la refuser. La vérification d’une pull request lit le SBOM candidat face au produit sans modifier celui-ci, et répond en nommant la règle enfreinte.

Ce que la barrière juge à chaque modification

Paquets malveillants
Aucun admis par défaut. Un paquet que les flux ou son registre désignent comme malveillant fait échouer la vérification.
Noms trompeurs
Un nom à une ou deux lettres d’un paquet que tout le monde utilise.
Abandonné ou déprécié
Aucune version depuis deux ans, ou déprécié par ses mainteneurs.
Versions trop récentes
Une version publiée depuis moins de jours que le nombre que vous fixez.
Provenance perdue
Une version sans l’attestation de registre que portaient les précédentes.
Éditeur changé
Une version publiée par un autre compte que la version précédente.
Nouveau script d’installation
Une version qui ajoute un script exécuté à l’installation.
Constats exploités
Des fiches exploitées activement, ou liées à des campagnes de rançongiciel.
Restrictions de licence
Les licences qui restreignent l’usage commercial, la distribution ou la modification, selon votre liste.

Chaque règle est un interrupteur de votre politique, et les mêmes règles décident de la barrière de publication.

  1. Vous

    Notre pull request sur Payments API ajoute eslint-plugin-restart-vega-soap 1.0.0. Passera-t-elle la barrière de publication ?

  2. Assistant

    Non. La pull request bloquerait la barrière de publication de Payments API. Règles enfreintes : paquets malveillants (eslint-plugin-restart-vega-soap@1.0.0). Nouveau dans cette pull request : CVE-2026-4800, MAL-2025-19862, CVE-2025-13465.

  3. Comment l’assistant a répondu1 appel, 5,1 s

    1. check_sbom product_id: 1, sbom: CycloneDX 1.6, 2 composants, branch: add-eslint-plugin-restart-vega-soap

      Bloquée : max_malicious (eslint-plugin-restart-vega-soap@1.0.0). 4 nouveaux constats.

      5,1 s

Barrière bloquée

Enregistrée face au produit d’exemple Payments API : une nomenclature candidate portant la dépendance ajoutée par la pull request, vérifiée sans modifier le produit.

Les tâches prêtes à l’emploi pour GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines et Azure Pipelines lancent la vérification sur chaque pull request et envoient le SBOM de chaque version construite pour être publiée. Un verdict bloqué, ou une analyse qui n’a pas fini à temps, fait échouer la tâche.

Le groupe Confiance dans les paquets de la barrière de publication, dans Politique : sept règles sur les paquets qu’une publication peut embarquer, chacune avec son interrupteur et le niveau qui l’active.
Le groupe Confiance dans les paquets de la barrière de publication, dans Politique : les premières de ses sept règles, chacune un interrupteur.

Soumettez les livraisons de vos fournisseurs à vos propres exigences

Les logiciels que vous achetez finissent dans ce que vous livrez. Demandez un SBOM à chaque fournisseur, et jugez-le comme les vôtres.

Une clé pour chaque livraison

Une clé fournisseur envoie pour un seul produit et ne relit que le résultat de sa propre livraison, jamais un constat. Le fournisseur n’a pas besoin de compte, et la livraison est confrontée comme toute autre génération du produit.

Un tableau de bord par fournisseur

Le tableau de bord de chaque fournisseur fait la moyenne de la complétude, des identifiants, du format, des licences, des données fournisseur, de la ponctualité et des signatures sur les derniers SBOM des produits qu’il livre.

Un profil d’acceptation

Choisissez le profil selon lequel les SBOM d’un fournisseur sont jugés, comme le minimum du Cyber Resilience Act. La réponse est donnée par produit : vous voyez quelle livraison est insuffisante, et pourquoi.

La fiche d’un fournisseur d’exemple : sa note, ses sept dimensions de qualité, son profil d’acceptation, et chaque produit accepté ou refusé avec la raison.
La fiche d’un fournisseur, sur des fournisseurs fictifs et nos produits de démonstration : une livraison acceptée, une refusée, et pourquoi.

Huit référentiels, un seul jeu de faits

L’analyse qui note un produit répond aussi aux contrôles des référentiels qu’il vise.

  • Cyber Resilience Act (UE)
  • NIS2
  • SOC 2
  • ISO/IEC 27001
  • PCI DSS v4.0.1
  • NIST SSDF
  • BSI TR-03183
  • AI Act (UE)

Les quatre réponses d’un contrôle

Satisfait
Les faits satisfont le contrôle.
À surveiller
Un point à regarder avant la revue.
Écart
Les faits ne satisfont pas le contrôle.
En attente d’attestation
Une personne le confirme, avec une note ou un lien.

Le niveau de préparation est la part des contrôles applicables qui sont satisfaits, un contrôle à surveiller comptant pour moitié. C’est un indicateur à examiner, jamais une certification, et le rapport le dit en toutes lettres. Il est mesuré chaque nuit : une régression arrive dans vos alertes avant d’arriver à l’audit.

Le rapport imprimable porte un en-tête courant, une table des matières quand il est long, et une annexe reprenant le texte du référentiel pour chaque contrôle cité.

Des preuves à transmettre

Une VEX documente pourquoi une vulnérabilité affecte ou non votre produit, et elle est rédigée à partir des faits que VulnBeacon détient. Le rapport de divulgation des vulnérabilités, le SARIF, le dossier de preuves et les rapports imprimables sont datés et portent le nom du produit. Pour montrer un rapport à un client, partagez un lien en lecture seule, avec une date d’expiration et, si vous le souhaitez, un mot de passe.

Deux contrôles du Cyber Resilience Act ouverts : chacun avec sa référence, son statut, les preuves qui le fondent et quoi faire.
Un contrôle ouvert sur ses preuves : sa référence, son statut et les faits qui les fondent.
Le rapport de conformité imprimable d’un produit : son niveau de préparation et chaque contrôle avec son statut et ses preuves.
Le rapport imprimable, à transmettre ou à partager.

Veille sur les vulnérabilités : une base, à partir de 86 sources

Derrière chaque note, une seule fiche par vulnérabilité. La liste CVE, la NVD, les avis de GitHub, OSV, le catalogue KEV de la CISA, EPSS, les bulletins des éditeurs, les CERT nationaux et les flux de paquets malveillants y sont fusionnés : vous lisez une fiche au lieu d’en rapprocher cinq.

245 222

paquets malveillants dans la base, dont 1 108 publiés ces 30 derniers jours

Des paquets publiés pour nuire

Les attaquants n’attendent plus une faille : ils publient le paquet eux-mêmes. Un outil qui ne cherche que des identifiants CVE ne les voit jamais.

1 760

fiches au catalogue des vulnérabilités exploitées de la CISA, dont 32 ajoutées ces 30 derniers jours

L’exploitation avant le score

Un score dit à quel point une faille pourrait être grave ; l’exploitation dit qu’elle sert déjà. 32 423 fiches portent la preuve d’une exploitation active ou d’un exploit armé.

  • Cyber Resilience Act (UE)
  • NIS2
  • PCI DSS v4.0.1

demandent la preuve, pas l’intention

Une réglementation qui demande des preuves

Un SBOM, un processus de traitement des vulnérabilités, la trace qu’il a fonctionné, et une réponse motivée pour chaque vulnérabilité qui ne vous concerne pas. Un tableur monté la semaine qui précède l’audit ne tient pas.

Des noms à une lettre du vrai

Les paquets malveillants se cachent derrière un nom à une lettre du vrai, un script d’installation qui télécharge un binaire, une version poussée par un compte que personne ne connaît. La base les tient à côté des vulnérabilités, avec le verdict du registre quand il en a un, de sorte que l’inventaire d’un produit est jugé sur les deux à la fois.

Triées par ce qui se passe, pas par un score

Triées par CVSS seul, les fiches exploitées se perdent parmi des milliers que personne n’attaque. VulnBeacon lit le catalogue KEV, les preuves d’exploitation et la probabilité EPSS dans chaque fiche, et les constats d’un produit sortent exploités en tête.

La preuve que la réglementation demande

Le Cyber Resilience Act européen, NIS2 et PCI DSS v4.0.1 demandent la preuve, pas l’intention. La réponse motivée pour une vulnérabilité qui ne vous concerne pas est précisément ce qu’est une VEX, et VulnBeacon l’écrit à partir des faits qu’il tient.

L’écran Menaces : les fiches inscrites au catalogue KEV, celles qui ont dépassé l’échéance de la CISA, celles exploitées dans la période, et le chemin parcouru par les fiches de la période, de la publication à l’exploitation.
Les menaces dans l’application : ce qui est exploité maintenant, et jusqu’où sont allées les fiches de chaque période.

La base, ce mois-ci

Nouvelles fiches CVEPubliées ces 30 derniers jours 15 679
MAL Paquets malveillantsPubliés ces 30 derniers jours 1 108
KEV Exploitation avéréeFiches ajoutées au catalogue de la CISA ces 30 derniers jours 32
SourcesFusionnées en une fiche par vulnérabilité 86
La base entière, en chiffres
Fiches CVE395 743
Bulletins de sécurité2,7 millions
Paquets malveillants245 222

Chaque fiche indique quand elle a été modifiée pour la dernière fois.

La fiche d’une vulnérabilité critique inscrite au catalogue KEV de la CISA, telle que l’application la montre : exploitée activement, le vecteur CVSS, la probabilité EPSS, le score de risque, la remédiation et les faiblesses.
Une vraie fiche, lue dans l’application : exploitée activement, le vecteur, la probabilité, la remédiation, les faiblesses.

Interroger directement la base

La même base répond à un assistant. Ces deux sessions ont été enregistrées face à elle : les vulnérabilités critiques de la semaine, et les dernières fiches d’exécution de code à distance.

  1. Vous

    Quelles vulnérabilités critiques ont été publiées cette semaine ?

  2. Assistant

    273 fiches critiques ont été publiées depuis le 23 octobre. Les plus récentes : CVE-2026-76024 (Chrome, critique, correctif disponible), CVE-2023-22793 (Management Pack for Microsoft System Center, CVSS 9.3, correctif disponible), CVE-2026-61707 (CoPilot, CVSS 9.0, correctif disponible), CVE-2026-61645 (docat, CVSS 9.1, correctif disponible) et CVE-2026-103093 (ServiceNow AI Platform, CVSS 9.4). Aucune n’est encore au catalogue KEV.

    • CVE-2026-76024critiqueChromecorrectif disponible
    • CVE-2023-22793critiqueCVSS 9.3Management Pack for Microsoft System Centercorrectif disponible
    • CVE-2026-61707critiqueCVSS 9.0CoPilotcorrectif disponible
    • CVE-2026-61645critiqueCVSS 9.1docatcorrectif disponible
    • CVE-2026-103093critiqueCVSS 9.4ServiceNow AI Platform
  3. Comment l’assistant a répondu1 appel, 112 ms

    1. search_corpus severity: critical, since: 2026-10-23, per_page: 5

      273 fiches ; les 5 plus récentes :

      112 ms

Enregistrée face à la base : les fiches critiques des sept derniers jours, de la plus récente, les cinq plus récentes listées.

Un assistant qui répond à partir de vos produits et de la base

VulnBeacon fournit un serveur MCP : un assistant comme Claude, Cursor ou VS Code peut poser ses questions avec vos mots. Il appelle la même API que l’application, avec votre clé, et répond à partir des mêmes faits. C’est un accès parmi d’autres : l’application web et vos tâches d’intégration continue offrent les mêmes capacités. Les sessions de cette page ont été enregistrées ainsi, sur des produits d’exemple.

Ce qu’il peut demander

  • La décision d’un produitLa note et ses raisons, le verdict de la barrière, les constats, un plan priorisé, la tendance, le bulletin à publier, tout le portefeuille. product_risk, product_gate, product_findings, product_remediation, product_trend, product_advisory, portfolio_summary, list_products
  • Un SBOMEnvoyer le SBOM d’une version construite, vérifier le candidat d’une pull request sans toucher au produit, comparer deux générations. upload_sbom, check_sbom, sbom_diff
  • La baseUne vulnérabilité par n’importe lequel de ses identifiants, les paquets qu’elle touche, un paquet par son purl avec son statut malveillant, une recherche sur toute la base, l’impact d’un incident sur vos produits. cve_lookup, cve_packages, package_lookup, search_corpus, incident_impact
  • La conformitéLe niveau de préparation par référentiel et le rapport avec la réponse de chaque contrôle. compliance_summary, compliance_report
  • Votre veilleLes listes de veille, ce qui a changé pour elles, le fil des alertes. list_watchlists, watchlist_changes, alerts_feed
  • Les règles et la cléLa politique en vigueur pour le compte, et ce que la clé utilisée peut faire. effective_policy, key_info

En local ou hébergé

En local, uvx vulnbeacon-mcp lance le serveur sur votre machine pour Claude Code, Claude Desktop, Cursor ou VS Code. En hébergé, les mêmes outils répondent à https://mcp.vulnbeacon.com/mcp, votre clé envoyée avec chaque requête.

La clé décide de ce qu’il peut faire

Une clé de reporting lit tous les produits de votre compte et ne modifie rien. Une clé CI produit peut aussi envoyer un SBOM et lancer la vérification d’une pull request, pour les produits qu’elle nomme. Aucune clé ne modifie une politique ou une décision : elles ne changent que dans l’application.

La section MCP des paramètres : l’adresse du serveur, et un extrait de configuration pour chaque assistant, la clé laissée à coller par vous.
Les paramètres MCP : un extrait par assistant, la clé laissée à coller par vous.

Là où l’équipe travaille déjà

Les alertes vont là où elles seront lues, et la chaîne d’intégration se charge des envois.

  • SlackMessagerie
  • TeamsMessagerie
  • PagerDutyAstreinte
  • JiraTickets
  • ServiceNowITSM
  • SplunkSIEM
  • ElasticSIEM
  • SentinelSIEM
  • GitHubCode source
  • GitLabCode source
  • Alertes par e-mailIntégré

Les règles de routage décident quel type d’alerte, quelle gravité et si une inscription au catalogue KEV parvient à chaque intégration. Un ticket arrive dans Jira ou ServiceNow avec le constat joint. Une intégration qui échoue sans cesse se met en pause et vous le dit, et seuls les hôtes autorisés sont contactés.

Paramètres, Intégrations : le catalogue des fournisseurs de services, chacun avec sa marque et son usage.
Paramètres, Intégrations : chaque service avec ses règles de routage.

Comment ça marche, et ce que deviennent vos données

Votre scanner continue de lister ce que contient la construction. VulnBeacon ajoute la suite : ce que cette liste signifie maintenant, qui doit agir, et ce que vous pouvez en montrer.

À côté des outils que vous utilisez déjà

Syft, Trivy, Grype et vos outils de SBOM produisent l’inventaire, en CycloneDX, en SPDX, sous forme de fichier de verrouillage pris en charge ou de sortie du scanner. VulnBeacon le confronte à une base tenue à jour à partir de 86 sources, et le confronte de nouveau quand la base change, sans nouvelle analyse. Votre scanner vous dit ce qu’il a trouvé aujourd’hui. VulnBeacon suit chaque produit à partir de là : lesquels une nouvelle faille atteint, quoi corriger d’abord, si le correctif est arrivé, et si la mise en production respecte votre politique.

Trois accès, les mêmes réponses

L’espace de travail web contient tout, sans rien à installer. Votre chaîne d’intégration envoie chaque SBOM et vérifie chaque pull request avec une clé qui nomme ses produits. Un assistant IA reste facultatif : il lit par la même API avec la clé que vous choisissez, et une organisation qui n’en a pas approuvé dispose quand même de tout le produit.

Où cela fonctionne

Chaque offre est votre propre instance, exploitée par nous. Enterprise peut aussi fonctionner sur vos propres machines.

L’étape Inventaire d’un produit : chaque composant avec sa version, son écosystème, sa licence et ses signaux de santé, et le score de qualité du SBOM au-dessus.
Ce que devient la liste d’un scanner : chaque composant avec sa licence, sa santé et sa qualité.

Ce que vous envoyez, et où cela va

Ce que vous envoyez
Des SBOM et des manifestes de dépendances, pas du code source. Ils peuvent tout de même révéler des détails d’un projet : retirez toute information personnelle ou tout secret dont l’analyse n’a pas besoin.
Hébergement
Des centres de données dans l’Union européenne. Cela ne garde pas tous les flux à l’intérieur : les services ci-dessous peuvent impliquer un traitement hors de l’Espace économique européen.
En transit
Chaque connexion passe par un prestataire de protection du réseau, qui traite ce que porte chaque requête pendant son transit, documents compris.
Recherches de paquets
Pour juger la santé des dépendances et exécuter la vérification des pull requests, des identifiants de paquets partent vers des services publics d’information sur les paquets et, pour npm et PyPI, vers leurs registres. Des identifiants seulement, jamais un SBOM entier. Le nom d’un paquet privé peut tout de même révéler quelque chose : dites-nous s’il faut restreindre ces recherches.
Intégrations
Une intégration reçoit ce que vous lui envoyez, et rien n’atteint une intégration que vous n’avez pas configurée.
Assistants
Si vous en connectez un, son fournisseur traite vos invites, les informations récupérées et les réponses selon ses propres conditions. Nous n’utilisons pas vos informations pour entraîner des modèles d’IA.
Sur vos propres machines
Tout ceci décrit l’instance que nous exploitons. Une instance Enterprise sur vos propres machines est hébergée sous votre contrôle, sur votre réseau. Les recherches de paquets continuent de sortir, sauf si vous nous demandez de les restreindre.

La politique de confidentialité nomme chaque prestataire et donne tout le détail, et les conditions d’utilisation ce que vous pouvez envoyer.

Offres

Chaque offre fonctionne comme votre propre instance, exploitée par nous. Enterprise peut aussi fonctionner sur vos propres machines.

8
20
500

Ce que comprend chaque offre
Team 900 € HT par mois, facturé à l’année 10 produits Pour une équipe qui livre quelques produits. Demander Team Business 2 400 € HT par mois, facturé à l’année 50 produits Pour une organisation qui suit un portefeuille. Demander Business Enterprise à partir de 5 000 € HT par mois, facturé à l’année 200 produits Pour un grand portefeuille, ou une instance sur vos propres machines. Demander Enterprise
Où elle tourne Votre propre instance, opérée par nous Votre propre instance, opérée par nous Votre propre instance, opérée par nous ou sur vos machines
Prix annuel HT 10 800 € 28 800 € à partir de 60 000 €
Support Non inclus Non inclus Inclus
Générations de SBOM conservées, par produit 10 25 50
Envois et vérifications de pull request par mois 10 000 50 000 200 000
Composants dans un SBOM 5 000 10 000 10 000
Composants sur tous les produits 20 000 100 000 400 000
Intégrations d’alerte 10 20 50
Clés de reporting 5 10 25
Requêtes API par minute, par clé 300 300 600
Requêtes API par mois, par clé 100 000 100 000 500 000

Comment lire les limites

Un produit
Ce que vous suivez comme un tout : une application, un service ou une image. Une nouvelle version est une nouvelle génération de SBOM du même produit, pas un autre produit.
Atteindre une limite
Ce que vous avez déjà ne change pas. Un envoi ou une vérification au-delà du quota du mois attend le mois suivant, un nouveau produit au-delà de la limite est refusé, et un SBOM au-delà d’une limite de composants est refusé avec les deux chiffres. Un produit supprimé qui était utilisé garde sa place 30 jours.
Utilisateurs, mise en route, évaluation
Dites-nous ce qu’il vous faut dans votre demande, et une personne vous répond.

Dans chaque offre

  • Une note avec ses raisons, et un plan de remédiation priorisé
  • La barrière de publication et la vérification de pull request, selon vos règles
  • VEX, exports et dossier de preuves
  • La préparation à chaque référentiel couvert
  • Une seule base de vulnérabilités et de paquets malveillants, alimentée par 86 sources
  • L’assistant par MCP, hébergé ou sur votre machine
  • Alertes et tickets dans les outils que vous utilisez déjà
  • Des clés fournisseur, pour les SBOM que vos fournisseurs livrent

Commencer par un produit

Commencez par un produit : apportez son inventaire et voyez son exposition, ses correctifs priorisés, son résultat face à votre politique de mise en production et ses preuves. Découvrez un exemple d’évaluation de produit d’abord, si vous voulez quelque chose à lire ou à partager. Votre compte est créé une fois votre demande lue. Dites-nous votre nom, votre organisation et ce que vous livrez. Une fois votre compte créé, la première note arrive environ une minute après votre premier envoi.

Demander un accès Se connecter