Tratamiento de datos y privacidad

Esta página responde a una pregunta: ¿qué puede enviar BMAD+ fuera de mi máquina, a quién y con el visto bueno de quién? La respuesta corta: no tiene telemetría ni autoactualización silenciosa; once flujos del paquete npm pueden llegar a la red o lanzar un programa que lo haga, y cada uno está ligado a una base de consentimiento que tú controlas. La lista no es marketing escrito a mano: se genera a partir de una declaración del registro, y antes de cada versión el job de integración continua recorre el código entregado y falla si falta en la declaración una llamada de red, un oyente o un arranque de proceso, o si uno declarado ya no existe. El texto de referencia es la sección Data handling de SECURITY.md en el repositorio de BMAD+; esta página la refleja y explica cómo leerla.

Las cuatro bases de consentimiento#

Los once flujos que pueden salir de la máquina#

Hacer menos, a propósito#

Lo que se queda en la máquina#

• npx-launcher (cli): inicia la CLI en el mismo ejecutable de Node.js, en cada ejecución de npx bmad-plus.
• python-health (cli): ejecuta el Python propio del entorno de un pack, aislado (-I), para confirmar que sus módulos se importan. Cuándo: bmad-plus doctor en un proyecto con un pack Python aprovisionado.
• review-git (cli): lee el repositorio local con git (rev-parse, merge-base, diff, ls-files, show) para construir un ámbito de revisión.
• nexus-git (cli): lee la raíz del repositorio y el commit HEAD con git rev-parse para los planes y ejecuciones de Nexus.
• uat-serve (cli): sirve una página de receta y guarda sus veredictos, escuchando solo en 127.0.0.1 y rechazando cualquier otra cabecera Host.
• uat-release-gate (core): ejecuta la CLI bmad-plus propia del proyecto con el Node.js actual para calificar las ejecuciones de aceptación registradas, cuando el proyecto ejecuta el script de puerta de versión.
• osint-install (osint): copia el agente y las habilidades OSINT en un proyecto y luego ejecuta el script de diagnóstico local del pack con el Python del sistema, cuando ejecutas el script de instalación del paquete.

Servicios del mantenedor, fuera del paquete#

El repositorio contiene también dos servicios que el mantenedor despliega en sus propios servidores: el servidor MCP Audit 360° (herramientas de git, GitHub, Gamma, CI, RAG y memoria para los agentes del mantenedor, tras un token de portador y un panel protegido con contraseña) y el monitor de origen (vigila el repositorio BMAD-METHOD y avisa al mantenedor). No están en el paquete npm y los usuarios no los instalan. Sus propios flujos se declaran de la misma manera y los comprueba la misma puerta; SECURITY.md los lista completos.

Hechos sobre la cadena de suministro y la publicación#

• Siete dependencias de ejecución (@clack/prompts, commander, design-skill, fs-extra, js-yaml, picocolors, semver). design-skill aporta los archivos de habilidades que BMAD+ copia al instalar y un comando de enlace que BMAD+ nunca ejecuta.
• Las dependencias de producción se auditan antes de cada versión; los hallazgos altos y críticos bloquean la publicación. Los requisitos de Python mantenidos se auditan en CI y bloquean la publicación ante hallazgos conocidos.
• Los secretos que usa la automatización del proyecto viven en GitHub Actions Secrets, nunca en el código; el directorio local de secretos está en gitignore; el pipeline limpia los directorios privados antes de la distribución pública.
• Los paquetes npm se construyen a partir de copias de distribución depuradas, sin commit padre ni historial de código fuente. Cada versión conserva su SBOM CycloneDX de producción, su archivo y su manifiesto de integridad como artefactos del workflow, y la integridad del registro debe coincidir con el archivo comprobado antes de desplegar el sitio.
• La publicación usa autenticación OIDC de npm. La procedencia de npm no está activada, porque el repositorio privado de construcción y el de distribución difieren; un inventario o un hash no es una atestación de procedencia, y el proyecto lo dice.
• Las escrituras y borrados rechazan enlaces simbólicos y uniones. Las credenciales nunca se ponen en URL (la clave de Google va en una cabecera). La página de aceptación no carga nada de otro origen.

Informar de una vulnerabilidad#

Usa el reporte privado de vulnerabilidades de GitHub: en el repositorio, pestaña Security, «Report a vulnerability» (informar de una vulnerabilidad ↗). El reporte queda privado entre tú y el mantenedor. Si no puedes usarlo, escribe a l.rochetta@gmail.com con el asunto [SECURITY] BMAD+ - Brief description. Incluye una descripción, los pasos para reproducir, una evaluación del impacto, las versiones afectadas y, opcionalmente, una corrección sugerida. No abras una incidencia pública, no explotes más allá de una prueba de concepto y no divulgues antes de que se publique una corrección. Los reportes válidos se acreditan en el changelog, salvo que prefieran el anonimato.