Sécurité ClawHub
Où signaler une faille du registre lui-même, pourquoi un défaut du service hébergé n’est pas divulgué par défaut, et quand un correctif de logiciel installé chez les utilisateurs est publié
Le signalement de sécurité échoue plus souvent sur l’aiguillage que sur l’effort. Un rapport déposé au mauvais endroit atteint quelqu’un qui ne peut pas corriger le défaut, et le correctif attend. ClawHub trace une ligne claire dans tout cela, en envoyant les problèmes du registre lui-même vers ses propres avis de sécurité et les problèmes d’un skill ou d’un plugin tiers vers celles et ceux qui les ont écrits. Déterminer de quel côté de cette ligne vous êtes prend un instant et fait gagner des jours.
Ce qui relève d’un avis
- Les problèmes de sécurité de ClawHub peuvent être signalés par les avis de sécurité GitHub du dépôt ClawHub, et un bon rapport couvre le site, l’API ou l’outil en ligne de commande ClawHub, la publication, les téléchargements, les installations ou l’intégrité des artefacts du registre, l’authentification, l’autorisation ou les jetons d’API, ou encore l’analyse, la modération et le traitement des signalements.
- Les failles situées dans le code source d’un skill ou d’un plugin tiers ne relèvent pas des avis ClawHub et doivent être signalées directement à l’éditeur ou au dépôt source lié depuis la fiche ClawHub.
- Parce que ClawHub est une application hébergée dans le nuage, les failles de son service ne sont pas divulguées publiquement par défaut, et elles le sont lorsqu’il existe des preuves d’un impact réel sur les utilisateurs ou lorsque ceux-ci doivent agir.
- Les failles des logiciels installés chez les utilisateurs sont divulguées publiquement, y compris les paquets de l’outil en ligne de commande ClawHub, les binaires, les bibliothèques et les autres artefacts de version que les utilisateurs doivent mettre à jour localement.
Parce que ClawHub est une application hébergée dans le nuage, les failles du service ClawHub ne sont pas divulguées publiquement par défaut.
Quand la divulgation a lieu
La règle de divulgation devient facile à suivre dès que l’on voit sur quoi elle repose. Un service hébergé peut être réparé de façon centralisée, donc un défaut de service corrigé ne laisse rien à faire à l’utilisateur et l’absence de divulgation publique reste la règle. La divulgation est déclenchée à la place par des preuves d’impact réel sur les utilisateurs ou par la nécessité pour eux d’agir. Les exemples donnés pour l’impact réel sont concrets, à savoir une exploitation confirmée, l’exposition de données ou de secrets d’utilisateurs, un contenu malveillant qui atteint les utilisateurs à cause d’une défaillance de la plateforme, et tout problème obligeant les utilisateurs à renouveler des identifiants, à mettre à jour un logiciel local ou à prendre une autre mesure de protection. Chacun de ces cas demande une réaction de l’utilisateur, et c’est exactement pour cela qu’il change la réponse. Les logiciels installés par les utilisateurs sont l’image inverse, puisque personne ne peut les mettre à jour à leur place. C’est pourquoi les failles des logiciels installés chez les utilisateurs sont divulguées publiquement, y compris les paquets d’outil en ligne de commande, les binaires, les bibliothèques et les autres artefacts de version. Lisez la règle comme un test de la nécessité d’agir, et non comme une mesure de la gravité du défaut.
Où se trouvent les autres réponses
- Les étiquettes d’audit à l’installation, les niveaux de risque, les constats et leur interprétation sont traités sur la page des audits de sécurité ClawHub plutôt que par la procédure d’avis.
- Les signalements de la place de marché, les mises en attente de modération, les fiches masquées, les bannissements et la situation d’un compte sont traités sur la page de modération et de sécurité des comptes.
- Une fiche renvoie vers l’éditeur et le dépôt source, et c’est la voie à emprunter pour un défaut situé dans le code du paquet lui-même plutôt que dans le registre.
Le volet sécurité de ClawHub s’arrête au registre, et couvre le site, l’API et l’outil en ligne de commande, la publication, les téléchargements, les installations et l’intégrité des artefacts, l’authentification, l’autorisation et les jetons d’API, ainsi que l’analyse, la modération et le traitement des signalements. Tout ce qui se passe après l’arrivée d’un paquet sur votre propre machine est un autre sujet, traité dans Le bac à sable des agents et Les approbations d’outils.
Pourquoi la politique sépare ainsi
Cette séparation est une décision d’aiguillage plutôt qu’une clause de non-responsabilité. ClawHub peut corriger son propre site, son API, son outil en ligne de commande, son chemin de publication, ses téléchargements, ses installations, ses jetons et ses outils de modération, donc ces rapports lui reviennent et passent par ses avis de sécurité. Il ne peut pas corriger le code d’un skill ou d’un plugin tiers, donc ces rapports reviennent à l’éditeur ou au dépôt source lié depuis la fiche, là où la personne capable de corriger le code les verra. La divulgation par défaut suit la même logique, car une application hébergée dans le nuage est réparée une fois pour tout le monde, alors qu’un artefact déjà installé localement reste vulnérable tant que son propriétaire ne l’a pas mis à jour. La publication est donc réservée aux preuves d’impact réel sur les utilisateurs ou aux cas où ceux-ci doivent agir, par exemple renouveler des identifiants ou mettre à jour un logiciel local. Cela maintient l’utilité des divulgations publiques, puisque chaque élément divulgué en est un sur lequel un lecteur peut avoir à intervenir. Le versant publication de la même question se poursuit dans Les portées de publication et les propriétaires et La provenance des versions.
Sur Diali
Diali héberge OpenClaw, et chaque client fait tourner son propre assistant, avec un état conservé sur un volume persistant ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). La configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque publication, et les canaux se connectent depuis ce même tableau de bord. Voyez OpenClaw hébergé sur Diali pour l’exécution hébergée et La sécurité Diali pour la façon dont nous traitons notre versant.
- Défaut du registre : avis ClawHub. Défaut d’un paquet : son éditeur.
- Un correctif hébergé sans action requise n’est pas divulgué.
- Tout ce que vous devez mettre à jour localement est divulgué.
Arrêtez de lire, construisez le vôtre
Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.
