Faire circuler le signal vers le bon outil

OpenCVE propose une API REST pour consulter le catalogue de CVE, les éditeurs, les produits, les projets et leurs suivis. Selon la documentation actuelle de l’API v2, une organisation peut aussi administrer des abonnements, modifier le statut de triage, configurer des automatisations et connecter des notifications à des workflows externes.

Cela peut éviter de ressaisir la même information dans un tableau de suivi ou un outil d’équipe. Mais une intégration n’est pas neutre : il faut savoir quel projet est synchronisé, si une requête remplace l’ensemble des abonnements existants, quels droits le jeton possède et comment le révoquer.

SaaS ou instance auto-hébergée ?

Le dépôt public documente une édition communautaire installable et une offre hébergée. Le choix dépend du niveau d’exploitation que l’équipe souhaite assumer : mises à jour, sauvegardes, supervision, disponibilité et protection du service deviennent aussi sa responsabilité si elle l’héberge.

Il faut également lire la licence qui accompagne précisément la version déployée. Le dépôt indique une Business Source License (BSL) pour OpenCVE Community, avec des conditions qui peuvent limiter certains usages commerciaux. « Code visible », « auto-hébergeable » et « open source au sens de l’OSI » ne sont pas des synonymes. Examiner le fichier LICENSE, la version concernée et les conditions de l’éditeur avant d’intégrer le logiciel à un produit ou à un service.

Ce texte donne des repères techniques, pas une interprétation juridique de la licence. Pour un usage commercial, faire valider les conditions applicables par la personne compétente.

Sources

À lire aussi