proof-of-commitment
Protocolo criptográfico de prueba de compromiso para MCP. Realiza compromisos verificables antes de publicar o actuar, evitando cambios narrativos posteriores.
Documentación
Prueba de Compromiso
Las estrellas mienten. Las señales de comportamiento no.
Un servidor MCP y herramienta web que puntúa paquetes npm, paquetes PyPI, crates de Rust, módulos de Go y repositorios de GitHub según su compromiso conductual — señales que son más difíciles de falsificar que las estrellas, los README o los contadores de descargas.
$ npx proof-of-commitment axios zod chalk lodash minimatch
Scoring 5 npm packages... done in 3.0s
Package Risk Score Publishers Downloads Age Provenance
chalk 🔴 CRITICAL 72 1 432.9M/wk 14.6y —
minimatch 🔴 CRITICAL 78 1 634.1M/wk 14.9y —
lodash 🔴 CRITICAL 80 1 158.9M/wk 14.1y —
zod 🔴 CRITICAL 83 1 161.2M/wk 6.3y 🔐 verified
axios 🔴 CRITICAL 88 1 115.7M/wk 11.8y 🔐 verified
⚠ COMPROMISED — axios token theft (2026-03-30)
⚠ 5 CRITICAL packages found.
CRITICAL = sole npm publisher + >10M weekly downloads (publish-access concentration risk)
npm audit no marca ninguno de estos. No son vulnerabilidades — son concentración de superficie de ataque. Un token npm robado, un mantenedor suplantado, y un solo push alcanza a todo el ecosistema (axios, 30 de marzo de 2026 — ocurrió).
El problema de la cadena de suministro
26 de los 91 paquetes npm con más de 10M de descargas semanales tienen un único publicador npm. Juntos suman más de 3 mil millones de descargas por semana. npm audit no lo revela. Las estrellas tampoco.
Cuatro paquetes en un proyecto Node.js típico son CRÍTICOS ahora mismo:
- chalk — 432M descargas/semana, 1 publicador npm
- zod — 185M descargas/semana, 1 publicador npm (30+ contribuidores en GitHub)
- lodash — 156M descargas/semana, 1 publicador npm
- axios — 113M descargas/semana, 1 publicador npm (atacado el 30 de marzo de 2026)
Tampoco aparecerán en tu package.json — pero estos están en casi todos los proyectos:
- minimatch — 625M descargas/semana, 1 publicador npm
- glob — 366M descargas/semana, 1 publicador npm
- cross-spawn — 215M descargas/semana, 1 publicador npm
Las señales de comportamiento revelan esto. Las estrellas y los README no.
Instalación rápida (MCP)
No requiere inicio de sesión. Añádelo a cualquier herramienta de IA compatible con MCP y empieza a consultar el riesgo de la cadena de suministro.
Claude Desktop
Abre ~/Library/Application Support/Claude/claude_desktop_config.json en macOS (referencia del archivo de configuración) o %APPDATA%\Claude\claude_desktop_config.json en Windows, y luego añade:
{
"mcpServers": {
"commit": {
"type": "streamable-http",
"url": "https://poc-backend.amdal-dev.workers.dev/mcp"
}
}
}
Reinicia Claude Desktop. Aparece un icono de herramienta en la entrada de chat — pídele que audite tu package.json.
Cursor
Abre ~/.cursor/mcp.json (documentación de MCP para Cursor) y añade:
{
"mcpServers": {
"commit": {
"type": "streamable-http",
"url": "https://poc-backend.amdal-dev.workers.dev/mcp"
}
}
}
Smithery (una vez indexado)
npx -y @smithery/cli install proof-of-commitment --client claude
Pruébalo ahora
Terminal (sin instalación):
# New in v1.8.0: zero-arg auto-detect — cd into any project, run once:
npx proof-of-commitment
# Picks the highest-coverage manifest in cwd (package-lock.json > yarn.lock >
# pnpm-lock.yaml > pnpm-workspace.yaml > package.json; requirements.txt;
# Cargo.toml; go.sum > go.mod). When multiple ecosystems are present, the
# file with the most recent mtime wins.
# Explicit package list still works:
npx proof-of-commitment axios zod chalk
# Or point at a specific file:
npx proof-of-commitment --file package.json
npx proof-of-commitment --file package-lock.json # npm (transitive)
npx proof-of-commitment --file yarn.lock # yarn
npx proof-of-commitment --file pnpm-lock.yaml # pnpm
npx proof-of-commitment --file pnpm-workspace.yaml # pnpm monorepo
npx proof-of-commitment --pypi litellm langchain requests
npx proof-of-commitment --cargo serde tokio reqwest
npx proof-of-commitment --golang github.com/gin-gonic/gin golang.org/x/net
npx proof-of-commitment --file go.mod
npx proof-of-commitment --file go.sum # full transitive Go set
# JSON output for downstream tools:
npx proof-of-commitment --file package-lock.json --json | jq '.criticalCount'
Integración con CI (v1.8.0+)
--fail-on=<level> convierte la CLI en una puerta de CI de una sola línea. No se requiere GitHub Action.
# .github/workflows/supply-chain.yml
name: Supply Chain
on: [pull_request]
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npx -y proof-of-commitment --fail-on=critical
Niveles:
--fail-on | Salida 1 cuando… |
|---|---|
critical | cualquier paquete está marcado CRÍTICO (concentración de acceso de publicación) |
risky | cualquier paquete es CRÍTICO o ALTO (puntuación < 40) |
none | nunca — solo informe |
Valores predeterminados: critical en CI (cuando CI=true está configurado, lo cual hace todo runner de CI importante) y para salida --json. El modo interactivo (TTY, no CI) mantiene el valor predeterminado de v1.7 de salida 0 — ejecutarlo localmente no romperá tus hábitos de shell.
La piiiico/commit-action@v1 dedicada sigue siendo la opción correcta cuando quieres comentarios en PR y resúmenes de pasos; --fail-on es para pipelines mínimos que solo necesitan una respuesta de sí/no.
Salida SARIF para GitHub Code Scanning (v1.26.0+)
--sarif genera SARIF 2.1.0 — el formato estándar para resultados de análisis estático. Súbelo a GitHub Code Scanning y los hallazgos de Commit aparecen en la pestaña de Seguridad junto a CodeQL y Snyk.
# .github/workflows/supply-chain.yml
name: Supply Chain
on: [pull_request]
jobs:
audit:
runs-on: ubuntu-latest
permissions:
security-events: write
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npx -y proof-of-commitment --file package-lock.json --sarif --fail-on=none > results.sarif
- uses: github/codeql-action/upload-sarif@v3
if: always()
with:
sarif_file: results.sarif
category: commit-supply-chain
Los paquetes CRÍTICOS y ALTOS se muestran como alertas en la pestaña de Seguridad del repositorio. Los paquetes comprometidos (en el registro de incidentes de Commit) reciben una alerta separada. --fail-on sigue controlando el código de salida de forma independiente — usa --fail-on=critical para también bloquear el PR.
Demo web (sin instalación): getcommit.dev/audit — pega tus paquetes, ve las puntuaciones de riesgo en segundos.
Hooks de IDE (Cursor + Claude Code + Windsurf)
poc hook instala una puerta de cadena de suministro para Cursor (beforeShellExecution), Claude Code (PreToolUse) y Windsurf (pre_run_command) en un solo comando. El mismo script de hook intercepta instalaciones de paquetes desde cualquier agente, detecta automáticamente qué cliente lo llamó y bloquea paquetes CRÍTICOS antes de que se ejecuten.
# Install for the current project (writes .cursor/hooks.json + .claude/settings.json + .windsurf/hooks.json):
poc hook
# Or protect every project for your user:
poc hook --global
# Narrow to one client:
poc hook --cursor # only .cursor/hooks.json
poc hook --claude-code # only .claude/settings.json
poc hook --windsurf # only .windsurf/hooks.json
# Remove (cleans all three):
poc hook --uninstall
El hook escribe .cursor/hooks.json, .claude/settings.json y .windsurf/hooks.json (proyecto) o los equivalentes bajo ~/ (con --global). Cuando Cursor, Claude Code o Windsurf ejecuta npm install axios, pip install litellm, cargo add serde o go get github.com/gin-gonic/gin, el hook llama a la API de Commit y bloquea, advierte o permite — en menos de 500ms.
Qué se intercepta:
| Gestor de paquetes | Comando de ejemplo |
|---|---|
| npm / npx | npm install <pkg>, npm add <pkg> |
| pnpm | pnpm add <pkg> |
| yarn | yarn add <pkg> |
| pip / pip3 / uv | pip install <pkg> |
| cargo | cargo add <pkg>, cargo install <pkg> |
| go | go get <module>, go install <module> |
Por qué importa: Los ataques a la cadena de suministro ahora ocurren en minutos. El gusano Shai-Hulud (mayo de 2026) comprometió 637 paquetes en 39 minutos y apuntó específicamente a asistentes de codificación con IA — plantando hooks de persistencia en .claude/settings.json y .vscode/tasks.json. Cuando tu asistente de IA instala una dependencia, omite la revisión humana que solía ser la última línea de defensa. poc hook vuelve a poner una puerta — la misma puerta, ya sea Cursor, Claude Code o Windsurf quien la maneje.
Comportamiento predeterminado: Los paquetes CRÍTICOS (único publicador npm + >10M descargas/semana — el perfil exacto del ataque LiteLLM/axios) se bloquean. Los paquetes ALTOS activan un aviso de "preguntar al usuario" (Cursor/Claude Code) o se bloquean con un mensaje (Windsurf). Configura COMMIT_HOOK_SEVERITY_BLOCK=HIGH para bloquear ambos.
Con una clave API: poc login sk_commit_… antes de ejecutar poc hook — la clave se incrusta en la configuración del hook y elimina el límite de tasa.
Recibe notificaciones antes del próximo ataque
La CLI te dice qué es riesgoso hoy. Una clave API gratuita desbloquea monitoreo — recálculo de puntuaciones en los paquetes de los que dependes, con alertas cuando uno se degrada (caída de publicadores, estancamiento de lanzamientos, caída de puntuación ≥10 puntos).
- Open (gratis): Vigila 3 paquetes · resumen semanal cada lunes
- Developer ($15/mes): Vigila 15 paquetes · escaneos diarios · alertas por correo instantáneas
Obtén una clave API gratuita → (sin tarjeta, 30 segundos · 200 auditorías/día incluidas)
npm install -g proof-of-commitment # then:
poc watch axios --email you@company.com # free key + monitoring in one step
poc watch chalk # add more packages (3 free)
poc init # add CI gate to this repo
GitHub Action
Añade auditoría de cadena de suministro a cualquier pipeline de CI en 30 segundos — detecta automáticamente paquetes desde package.json o requirements.txt, publica resultados como comentario en el PR, escribe en el Resumen de Pasos de GitHub y opcionalmente falla en paquetes CRÍTICOS.
Usa la acción dedicada en piiiico/commit-action:
# .github/workflows/supply-chain.yml
name: Supply Chain Audit
on:
pull_request:
paths: ['package.json', 'package-lock.json', 'bun.lock']
jobs:
audit:
runs-on: ubuntu-latest
permissions:
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: piiiico/commit-action@v1
with:
fail-on-critical: true # blocks merges on CRITICAL packages
comment-on-pr: true # posts results as a PR comment
Cuando comment-on-pr: true (predeterminado), la acción publica automáticamente la tabla de auditoría como comentario en la solicitud de extracción — y actualiza el mismo comentario al re-ejecutarse, para que no haya spam de comentarios. Los revisores ven la tabla de riesgo sin salir del PR.
Entradas:
| Entrada | Predeterminado | Descripción |
|---|---|---|
packages | (automático) | Nombres de paquetes separados por comas (auto-detectados desde package.json/requirements.txt si no se configuran) |
packages-file | (automático) | Ruta a package.json o requirements.txt (predeterminado: auto-detección en la raíz del workspace) |
fail-on-critical | true | Falla el workflow si se encuentran paquetes CRÍTICOS |
max-packages | 20 | Máximo de paquetes a auditar al auto-detectar |
include-dev-dependencies | false | Incluye devDependencies desde package.json |
comment-on-pr | true | Publica resultados de auditoría como comentario en el PR (requiere permiso pull-requests: write) |
api-key | (ninguna) | Clave API de Commit Pro — habilita solicitudes por lotes y 10K solicitudes/mes |
api-url | (prod) | Sobrescribe el endpoint de API (útil para auto-alojamiento) |
Salidas: has-critical, critical-count, audit-summary (tabla markdown, también escrita en el Resumen de Pasos).
Gratis vs Pro: Sin clave API, los paquetes se auditan uno a la vez (con demoras para respetar los límites de tasa). Con una clave API Pro, todos los paquetes se auditan en una sola solicitud por lotes — más rápido y con límites mensuales más altos.
Ejemplo de comentario en PR / salida de Resumen de Pasos:
| Package | Risk | Score | Publishers | Downloads/wk | Age |
|---------|-------------|-------|------------|--------------|-------|
| chalk | 🔴 CRITICAL | 75 | 1 | 380M | 12.7y |
| zod | 🔴 CRITICAL | 83 | 1 | 133M | 6.1y |
| axios | 🔴 CRITICAL | 89 | 1 | 93M | 11.6y |
Insignias de README
Añade una insignia de Confianza de Commit a cualquier paquete npm que mantengas o del que dependas:
Ejemplos:
| Paquete | URL de insignia |
|---|---|
| chalk |  |
| react |  |
| express |  |
| @babel/core |  |
Calificaciones: 🟢 OK (75+) · 🟠 ADVERTENCIA (40–74) · 🔴 CRÍTICO (<40 o único publicador npm con 10M+ descargas semanales)
Las insignias se almacenan en caché durante 1 hora. No se necesita clave API.
También admite PyPI, Cargo, módulos de Go y el formato completo específico del ecosistema:
API REST
Sin clave API. Sin instalación.
curl https://poc-backend.amdal-dev.workers.dev/api/audit \
-X POST \
-H "Content-Type: application/json" \
-d '{"packages": ["axios", "zod", "chalk", "lodash", "express"]}'
{
"count": 5,
"results": [
{
"name": "chalk",
"ecosystem": "npm",
"score": 75,
"maintainers": 1,
"weeklyDownloads": 398397580,
"ageYears": 12.7,
"trend": "stable",
"riskFlags": ["CRITICAL"],
"scorecardScore": 3.6, // null if no GitHub repo
"hasDangerousWorkflow": false // null if no Scorecard data
},
...
]
}
12 herramientas MCP
| Herramienta | Descripción |
|---|---|
audit_dependencies | Auditoría de riesgo por lotes para hasta 20 paquetes npm/PyPI/Cargo/Go |
audit_github_repo | Obtiene el package.json/requirements.txt de un repositorio y audita cada dependencia |
audit_dependency_tree | Mapea el árbol completo de dependencias de un paquete npm (incl. dependencias CRÍTICAS transitivas) |
lookup_npm_package | Perfil conductual de un solo paquete npm |
lookup_pypi_package | Perfil conductual de un solo paquete PyPI |
lookup_cargo_crate | Perfil conductual de una sola crate de Rust (crates.io) |
lookup_go_module | Perfil conductual de un solo módulo de Go (proxy.golang.org + GitHub) |
lookup_github_repo | Puntuación de compromiso de repositorio GitHub (longevidad, frecuencia de commits, profundidad de contribuidores) |
lookup_business | Registro de empresas noruego — años de operación, empleados, finanzas |
lookup_business_by_org | Lo mismo, por número de organización |
query_commitment | Datos conductuales de extensiones de navegador (visitantes verificados únicos, tasa de repetición) |
get_api_key | Crea una clave API gratuita en el chat — sin navegador necesario, clave devuelta al instante |
Anónimo: 15 solicitudes/IP/día UTC en ambos /mcp y /api/audit. Clave gratuita (sin tarjeta, registro de 30s en https://getcommit.dev/get-started): 200/día. Niveles superiores en https://getcommit.dev/pricing.
Qué mide la puntuación
Cada paquete se puntúa de 0 a 100 en:
- Longevidad — ¿Cuánto tiempo ha existido el paquete? Los paquetes abandonados se reactivan para ataques.
- Profundidad de publicadores — Un solo publicador npm + millones de descargas semanales = la superficie de ataque que explotó LiteLLM. (Publicador = persona con acceso de publicación npm, distinto de los contribuidores de GitHub).
- Consistencia de lanzamientos — Lanzamientos regulares señalan supervisión activa. Largos vacíos = acumulación de vulnerabilidades.
- Tendencia de descargas — Los paquetes en crecimiento atraen más escrutinio (y ataques). Estable = perfil más bajo.
- OpenSSF Scorecard — Seguridad de procesos (aplicación de revisión de código, protección de ramas, seguridad de CI/CD). Separado de las señales conductuales. Scorecard alto ≠ seguro contra robo de credenciales.
Tanto axios (8.1/10 Scorecard) como chalk (3.6/10 Scorecard) puntúan CRÍTICO en señales conductuales. Miden superficies de ataque diferentes — Scorecard detecta vacíos de proceso, las señales conductuales detectan concentración de publicadores.
Indicadores de riesgo:
CRITICAL— un solo publicador npm + >10M descargas semanales (perfil exacto del ataque LiteLLM/axios)HIGH— paquete <1 año + adopción rápidaWARN— sin lanzamiento en 12+ meses
Puntos de datos reales
# packages you know about:
chalk — score 75, 1 publisher, 432M/week ⚑ CRITICAL
zod — score 83, 1 publisher, 185M/week ⚑ CRITICAL (30+ GitHub contributors)
lodash — score 81, 1 publisher, 156M/week ⚑ CRITICAL
axios — score 88, 1 publisher, 113M/week ⚑ CRITICAL (attacked Mar 30 2026)
express — score 90, 5 publishers, 95M/week
# packages probably not in your package.json, definitely in your lock file:
minimatch — score 78, 1 publisher, 625M/week ⚑ CRITICAL
glob — score 80, 1 publisher, 366M/week ⚑ CRITICAL
cross-spawn — score 72, 1 publisher, 215M/week ⚑ CRITICAL
# post-attack:
litellm — score 74, 1 publisher ⚑ CRITICAL (supply chain attack Mar 2026)
# Rust crates (new in v1.3.0):
serde — score 78, 1 owner, 13M/week ⚑ CRITICAL (dtolnay sole owner)
tokio — score 89, 2 owners, 10M/week
reqwest — score 85, 1 owner, 8M/week ⚑ HIGH
Por qué señales conductuales
El ataque a LiteLLM (marzo de 2026) y el ataque a axios (30 de marzo de 2026) siguieron el mismo patrón: credenciales robadas → paquete malicioso publicado → 97M+ máquinas expuestas. Ambos paquetes puntuaron CRÍTICO según estas métricas antes de los ataques.
Las señales declarativas (estrellas, calidad del README, insignias de CI) no capturan este riesgo. El compromiso conductual sí.
Blog
- El Backdoor de LinkedIn: Por qué npm audit Pasó por Alto un Ataque de 250 Líneas — Un ataque clon de reclutador falso ocultó malware en archivos de prueba y lo ejecutó mediante scripts de ciclo de vida de npm. npm audit: silencioso. Qué habrían señalado las señales conductuales.
- Predicción del Ataque a Axios — Marcamos axios como CRÍTICO (único publicador npm, 113M descargas/semana) antes del robo de token del 30 de marzo de 2026.
Stack
| Capa | Tecnología |
|---|---|
| Backend | Cloudflare Workers + D1 |
| MCP | Model Context Protocol SDK |
| Datos | npm registry, PyPI, crates.io, proxy.golang.org, deps.dev, GitHub API, Brønnøysund (NO) |
| Landing | Astro + Cloudflare Pages |
Hoja de ruta
Planificado, no prometido. El proyecto está en una etapa temprana: las contribuciones son bienvenidas en cualquiera de estos.
| Característica | Estado | Notas |
|---|---|---|
| Soporte de registro Cargo (Rust) | ✅ En vivo | Herramienta MCP, API REST, endpoint de insignia — ecosystem: "cargo" |
| Soporte de módulos Go | ✅ En vivo | proxy.golang.org + deps.dev + puntuación basada principalmente en GitHub — ecosystem: "golang" |
| Visualización del desglose de puntuación | Planificado | Componente de gráfico para las 5 dimensiones en getcommit.dev/audit |
Indicador --json para CLI | ✅ En vivo | npx proof-of-commitment --file package-lock.json --json | jq '.criticalCount' |
| Soporte de monorepo de workspace pnpm | ✅ En vivo | --file pnpm-workspace.yaml o detectado automáticamente desde pnpm-lock.yaml |
| Seguimiento histórico de puntuaciones | Planificado | Gráficos de tendencia: ¿este paquete se estaba volviendo más riesgoso con el tiempo? |
| Paneles a nivel de organización | Planificado | Vista de riesgo agregado en todos los repositorios de una organización de GitHub |
Consulta problemas abiertos para cosas en las que puedes ayudar hoy.
La visión más amplia
La auditoría de la cadena de suministro es la primera herramienta. La primitiva subyacente es un grafo de compromiso: señales de comportamiento que reemplazan la confianza basada en contenido en cualquier dominio.
Cuando el contenido se puede falsificar libremente (reseñas, estrellas, READMEs), el compromiso se convierte en la señal. Un editor que ha publicado 847 versiones durante 12 años es un tipo de compromiso diferente al de uno que publicó una vez en 2023.
La misma lógica se aplica a sitios web, empresas y agentes de IA. Dos redes de tarjetas han nombrado esta brecha de forma independiente: Mastercard Verifiable Intent §9.2 enumera explícitamente la confianza conductual como «no cubierta». Visa TAP identifica agentes sin responder si se debe confiar en ellos.
Proof of Commitment es la capa de confianza a la que apuntan.
Ejecutar localmente
bun install
bun run dev:backend # local server with SQLite
bun run test:e2e # E2E test with mock World ID
Desplegar:
bun run deploy # deploys to Cloudflare Workers
Publicación
La publicación se activa automáticamente cuando se envía una etiqueta v*, o manualmente mediante GitHub Actions workflow_dispatch.
Prueba de humo del embudo
Antes de que se ejecute npm publish, el flujo de trabajo de CI ejecuta scripts/funnel-smoke.sh: una verificación previa a la publicación con simulacro local que ejercita cuatro rutas clave del embudo:
| Ruta | Qué prueba | Clase de error detectada |
|---|---|---|
| A | Auditoría CLI con COMMIT_API_KEY configurado → 200 + resultados | v1.20.0: falta el encabezado Authorization → 0 conversiones pagadas |
| B | Auditoría CLI anónima, 429 → mensaje + instant_key_url | Manejo de 429 / presentación de CTA |
| C | cursor-hook (stdin de Cursor) 429 → permission: ask + URL de registro | v1.21.0: allow silencioso en 429 → brecha de seguridad + 0 conversiones |
| D | cursor-hook (stdin de Claude Code PreToolUse) 429 → hookSpecificOutput.permissionDecision: ask + atribución claude-code-hook-429 | v1.22.0: respuesta con forma incorrecta cuando Claude Code dirige → permiso silencioso / conversión mal atribuida |
Cualquier fallo en una ruta bloquea la publicación. La compuerta ejecuta un servidor simulado local en Python, por lo que es determinista en CI y no depende del estado de límite de tasa de producción.
Secreto de CI opcional: Configura COMMIT_TEST_API_KEY en los secretos del repositorio de GitHub para usar una clave de API real para la Ruta A. Se recurre a una clave simulada que el servidor local acepta incondicionalmente.
Ejecutar localmente:
bash scripts/funnel-smoke.sh