Parcourir la documentation
Traitement des données et vie privée
Ni télémétrie ni mise à jour silencieuse. Les onze flux du paquet npm pouvant envoyer des données hors de votre machine : quoi, à qui, quand, sur quelle base de consentement, et ce qui reste local.
Sur cette page
Cette page répond à une question : que peut envoyer BMAD+ hors de ma machine, à qui, et avec l’accord de qui ? La réponse courte : il n’a ni télémétrie ni mise à jour silencieuse ; onze flux du paquet npm peuvent atteindre le réseau ou lancer un programme qui le fait, et chacun est rattaché à une base de consentement que vous contrôlez. La liste n’est pas du marketing écrit à la main : elle est générée à partir d’une déclaration du registre, et avant chaque version le job d’intégration continue parcourt le code livré et échoue si un appel réseau, un écouteur ou un lancement de processus manque dans la déclaration, ou si un flux déclaré n’existe plus. Le texte de référence est la section Data handling de SECURITY.md dans le dépôt BMAD+ ; cette page la reprend et explique comment la lire.
Remarque Ce que veut dire « par un programme lancé »
Dans les tableaux, « directement » signifie qu’un script BMAD+ fait lui-même la requête. « Par un programme lancé » signifie que BMAD+ démarre un outil (npm, uv ou pip, git, Codex CLI, Chromium, ou une commande que vous avez déclarée) et que cet outil fait l’envoi. Le téléchargement de BMAD+ lui-même avec npx est fait par npm et n’est pas l’un des flux ci-dessous.
Les quatre bases de consentement
| Base | Sens |
|---|---|
| opt-out | Cela se produit par défaut selon la politique du projet, et vous pouvez le désactiver. |
| opt-in | Cela ne se produit jamais sauf si vous le demandez par une option, une confirmation ou une politique explicite. |
| invocation | Cela ne se produit que lorsque vous (ou votre assistant, à votre demande) lancez la commande qui le fait, sur une entrée que vous avez fournie. |
| credential | Cela ne se produit qu’une fois la clé (ou l’URL) que le fournisseur exige définie ; sans l’identifiant, rien n’est envoyé. |
Les onze flux qui peuvent quitter la machine
| Flux | Comment ça sort | Quoi | À qui | Quand | Consentement |
|---|---|---|---|---|---|
update-check (cli) | Par un programme lancé | Le nom du paquet et le canal (npm view bmad-plus@latest) avec les métadonnées de requête de npm : adresse IP, user agent (versions de npm, Node.js et du système) et en-têtes de session npm. | registry.npmjs.org (la politique n’accepte aucun autre registre) | bmad-plus update-check, que les adaptateurs générés demandent à l’agent de lancer une fois par session ; la réponse est mise en cache dans .bmad/update-check.json. | opt-out : bmad-plus update-policy --mode off arrête toute recherche. |
update-apply (cli) | Par un programme lancé | La version exacte demandée, avec les métadonnées de requête de npm, pour télécharger le paquet de cette version. | registry.npmjs.org | bmad-plus update --latest --yes, ou --auto quand la politique du projet l’autorise. | opt-in : chaque exécution exige --yes, ou le mode de politique auto avec une plage explicite. |
python-provision (cli) | Par un programme lancé | Les noms et versions du requirements.txt du pack, avec les métadonnées de requête de l’installateur ; uv peut aussi télécharger une version de Python. | pypi.org et files.pythonhosted.org, ou l’index configuré pour pip ou uv sur la machine ; github.com (versions python-build-standalone) quand uv télécharge Python. | bmad-plus install --provision-python pour un pack Python sélectionné. | opt-in : seulement avec --provision-python ; sans cela aucun environnement n’est créé. |
nexus-worker (cli) | Par un programme lancé | Avec codex-exec, l’instruction de la tâche et ses fichiers d’entrée (1 Mio au plus) vont à Codex CLI, qui les envoie au fournisseur de modèle de votre propre connexion Codex. Avec command, tout ce que cette commande envoie. | Le fournisseur de modèle configuré dans votre Codex CLI ; quiconque une commande déclarée contacte. | bmad-plus nexus launch sur un plan avec un contrat d’exécution explicite. | invocation : rien ne démarre sans un plan que vous avez écrit et un lancement explicite ; le shell, l’environnement et les drapeaux Codex arbitraires sont refusés. |
nexus-verifier (cli) | Par un programme lancé | Tout ce que la commande déclarée envoie ; elle s’exécute avec un environnement minimal à liste blanche. | Le service que contacte la commande déclarée. | bmad-plus nexus verify sur une tâche d’un plan que vous avez écrit. | invocation : la commande et son hash sont fixés dans le plan ; un exécutable modifié est refusé. |
uat-page-results (core) | Directement | Le résultat : nom du testeur, verdicts des étapes et notes. | L’origine qui sert la page : bmad-plus uat serve sur 127.0.0.1, ou le stockage d’artefacts de claude.ai quand la page est publiée comme artefact. | Chaque verdict enregistré, quand la page est servie ; une page ouverte depuis un fichier garde les résultats dans le navigateur. | invocation : le testeur choisit comment la page est ouverte ; une page ouverte depuis un fichier n’envoie rien. |
osint-providers (osint) | Directement | La requête d’investigation (noms, pseudonymes, mots-clés et URL concernant le sujet) et la clé d’API de ce fournisseur, en HTTPS vérifié : l’assistant partagé refuse tout autre schéma et toute redirection hors de l’hôte du fournisseur. | api.apify.com, api.exa.ai, r.jina.ai, s.jina.ai, deepsearch.jina.ai, api.parallel.ai, api.perplexity.ai, api.tavily.com, l’URL MCP Bright Data que vous configurez. | Quand l’agent Shadow, ou volley.py qui se déploie vers les autres, exécute un script de fournisseur pendant une investigation. | credential : un fournisseur n’est contacté qu’une fois sa clé (ou l’URL MCP Bright Data) définie ; la porte de base légale de la phase moins 1 précède le profilage d’une personne nommée. |
seo-site-fetch (seo) | Directement | Des requêtes HTTP pour les pages du site audité, robots.txt et le sitemap, avec le user agent choisi par l’audit, depuis votre adresse IP. | Le site que vous demandez d’auditer (adresses publiques uniquement). | seo_fetch.py et seo_crawl.py, lancés par les agents SEO pendant un audit. | invocation : seules l’URL que vous donnez et ses liens internes sont récupérés ; les adresses privées, de bouclage et de lien local sont refusées. |
seo-google-apis (seo) | Directement | L’URL ou l’origine auditée, et votre GOOGLE_API_KEY dans l’en-tête x-goog-api-key, jamais dans l’URL de la requête ; les redirections ne sont pas suivies. | www.googleapis.com, chromeuxreport.googleapis.com, searchconsole.googleapis.com | seo_apis.py, lancé pendant la phase de performance d’un audit. | credential : seulement quand GOOGLE_API_KEY est défini ; sans elle le script renvoie une erreur et n’envoie rien. |
seo-screenshot (seo) | Par un programme lancé | Les requêtes de Chromium pour la page auditée et les ressources que son propre hôte sert, avec un user agent de navigateur, depuis votre adresse IP. Les ressources tierces sont bloquées, pas récupérées. | Le site que vous demandez d’auditer (adresses publiques uniquement). | seo_screenshot.py, quand un audit demande des captures. | invocation : seule l’URL que vous donnez, avec le Playwright et le Chromium que vous avez installés ; les adresses non publiques, les autres hôtes et les redirections hors de l’hôte sont refusés. |
assurance-checks (cli) | Par un programme lancé | Tout ce qu’une commande de contrôle déclarée envoie ; la CLI elle-même n’envoie rien. | Le service que contacte une commande de contrôle déclarée. | bmad-plus assurance run sur un dossier que vous avez écrit. | invocation : seules les commandes listées dans votre propre fichier de dossier s’exécutent, et seulement sur un assurance run explicite ; la clé de signature n’est jamais transmise à un contrôle. |
En faire moins, volontairement
| Vous voulez | Faites ceci |
|---|---|
| Aucune recherche auprès du registre | npx bmad-plus update-policy --mode off. Les instructions générées constatent alors que la vérification est désactivée et poursuivent la tâche. |
| Vérifier sans requête | update-check --offline : il ne lance aucune requête au registre et répond « inconnu ». |
| Aucun environnement Python | Ne passez pas --provision-python. Le pack SEO fonctionne alors en mode consignes seules. |
| Aucune donnée vers un fournisseur de modèle via Nexus | N’écrivez pas de plan avec codex-exec et ne lancez pas nexus launch. Le flux géré par l’hôte n’envoie rien lui-même. |
| Aucun appel OSINT | Ne définissez aucune clé de fournisseur. Un fournisseur n’est contacté que lorsque sa clé est définie. |
| Aucun trafic SEO | Ne lancez pas d’audit SEO, et laissez GOOGLE_API_KEY non défini pour éviter les API Google. |
| Une page de recette qui ne prévient personne | Ouvrez la page construite depuis un fichier au lieu de la publier comme artefact : elle garde les résultats dans le navigateur et n’envoie rien. |
Ce qui reste sur la machine
npx-launcher(cli) : démarre la CLI dans le même exécutable Node.js, à chaque lancement denpx bmad-plus.python-health(cli) : exécute le Python propre à l’environnement d’un pack, isolé (-I), pour confirmer que ses modules s’importent. Quand :bmad-plus doctorsur un projet avec un pack Python provisionné.review-git(cli) : lit le dépôt local avec git (rev-parse, merge-base, diff, ls-files, show) pour construire un périmètre de revue.nexus-git(cli) : lit la racine du dépôt et le commit HEAD avecgit rev-parsepour les plans et exécutions Nexus.uat-serve(cli) : sert une page de recette et enregistre ses verdicts, en écoutant sur 127.0.0.1 uniquement et en refusant tout autre en-tête Host.uat-release-gate(core) : exécute la CLI bmad-plus propre au projet avec le Node.js courant pour noter les résultats de recette enregistrés, quand le projet lance le script de porte de version.osint-install(osint) : copie l’agent et les compétences OSINT dans un projet, puis exécute le script de diagnostic local du pack avec le Python du système, quand vous lancez le script d’installation du paquet.
Services du mainteneur, hors du paquet
Le dépôt contient aussi deux services que le mainteneur déploie sur ses propres serveurs : le serveur MCP Audit 360° (outils git, GitHub, Gamma, CI, RAG et mémoire pour les agents du mainteneur, derrière un token porteur et un tableau de bord protégé par mot de passe) et le moniteur amont (il surveille le dépôt BMAD-METHOD et prévient le mainteneur). Ils ne sont pas dans le paquet npm et les utilisateurs ne les installent pas. Leurs propres flux sont déclarés de la même façon et contrôlés par la même porte ; SECURITY.md les liste en entier.
Faits sur la chaîne d’approvisionnement et la publication
- Sept dépendances d’exécution (
@clack/prompts,commander,design-skill,fs-extra,js-yaml,picocolors,semver).design-skillapporte les fichiers de compétences que BMAD+ copie à l’installation et une commande de liaison que BMAD+ n’exécute jamais. - Les dépendances de production sont auditées avant chaque version ; les constats de gravité haute et critique bloquent la publication. Les exigences Python maintenues sont auditées en CI et bloquent la publication en cas de constat connu.
- Les secrets utilisés par l’automatisation du projet vivent dans les GitHub Actions Secrets, jamais dans le code ; le dossier local de secrets est ignoré par Git ; le pipeline nettoie les dossiers privés avant la distribution publique.
- Les paquets npm sont construits à partir de copies de distribution nettoyées, sans commit parent ni historique des sources. Chaque version conserve son SBOM CycloneDX de production, son archive et son manifeste d’intégrité comme artefacts de workflow, et l’intégrité du registre doit correspondre à l’archive contrôlée avant le déploiement du site.
- La publication utilise l’authentification OIDC de npm. La provenance npm n’est pas activée, parce que le dépôt de construction privé et le dépôt de distribution diffèrent ; un inventaire ou un hash n’est pas une attestation de provenance, et le projet le dit.
- Les écritures et suppressions refusent les liens symboliques et les jonctions. Les identifiants ne sont jamais mis dans des URL (la clé Google va dans un en-tête). La page de recette ne charge rien d’une autre origine.
Signaler une vulnérabilité
Utilisez le signalement privé de vulnérabilités de GitHub : sur le dépôt, onglet Security, « Report a vulnerability » (signaler une vulnérabilité ). Le signalement reste privé entre vous et le mainteneur. Si vous ne pouvez pas l’utiliser, écrivez à l.rochetta@gmail.com avec l’objet [SECURITY] BMAD+ - Brief description. Joignez une description, les étapes de reproduction, une évaluation de l’impact, les versions touchées et, facultativement, un correctif proposé. N’ouvrez pas de ticket public, n’exploitez pas au-delà d’une preuve de concept et ne divulguez pas avant la publication d’un correctif. Les signalements valides sont crédités dans le changelog, sauf demande d’anonymat.
| Gravité | Accusé de réception | Objectif de correction |
|---|---|---|
| Critique | 24 heures | 72 heures |
| Haute | 48 heures | 7 jours |
| Moyenne | 7 jours | 30 jours |
Voir aussi
- Confiance et propriété Confiance, propriété et licences
- Référence : update-check update-check
- Référence : update-policy update-policy
- Nexus et le backend de processus Nexus : autopilot, travail parallèle et exécutions durables
- FAQ Questions fréquentes