security-recipes.ai

Busca CVEs. Remedia vulnerabilidades con agentes de IA. Los hechos con fuentes se mantienen con fuentes, la remediación se mantiene acotada, y cada plan lleva verificación, rollback y condiciones de detención: el contrato del sitio en vivo y el de este repositorio.

security-recipes.ai es un sitio Eleventy para inteligencia de CVE con fuentes y remediación de vulnerabilidades con puerta de evidencia que los agentes de IA pueden consumir sin heredar autoridad de despliegue o producción.

El proyecto es intencionalmente acotado:

• una base de datos CVE completa y continua de severidad Media/Alta/Crítica,

• registros canónicos de remediación CVE calificados por evidencia,

• recetas prácticas de remediación de seguridad,

• ejemplos de prompts y archivos de reglas,

• guías de configuración de agentes,

• patrones de integración MCP,

• un servidor MCP opcional de solo lectura para búsqueda de recetas y contexto MCP ascendente aprobado,

• una GitHub Action reutilizable que convierte esta guía en comprobaciones de salud de CI activables.

No es un escáner, sistema de tickets, plataforma SOAR, herramienta de despliegue o kit de seguridad personalizado. Las herramientas de seguridad existentes deberían producir los hallazgos; este sitio ayuda a los agentes a usar el contexto de remediación correcto y detenerse en el momento adecuado.

Comienza con la Base de datos CVE en vivo para una vulnerabilidad exacta o con los Playbooks de remediación de vulnerabilidades con IA para el flujo de trabajo de evidencia a parche. Las guías específicas por agente cubren Codex, Claude Code, Cursor, GitHub Copilot, Devin, Shiba Studio, Hermes Desktop y OpenClaw. La Guía visual muestra el camino completo desde la calificación de fuentes y el descubrimiento de búsqueda hasta un plan acotado, prueba, rollback y revisión humana. Para el problema distinto de asegurar las identidades, herramientas, conectores, contexto, memoria, runtime y controles de recuperación de un sistema de agentes, usa Seguridad de agentes de IA.

Producto y flujo de trabajo actuales

Descubrimiento de búsqueda calificado

El catálogo completo sigue siendo buscable, mientras que las páginas CVE canónicas públicas se limitan a registros revisados o calificados por evidencia. Esas páginas incluyen metadatos de búsqueda únicos, hechos centrales renderizados en el servidor y evidencia de versiones afectadas, una autoridad de remediación (primero guía revisada estable, de lo contrario enriquecimiento de IA completo con enlaces a fuentes), un prompt de implementación de IA corto con puerta de aprobación, URLs canónicas, migas de pan y datos estructurados Article/TechArticle. La base de datos CVE describe el catálogo como un Dataset; el pilar de remediación expone su flujo de trabajo visible de siete pasos como un HowTo. Los sitemaps CVE particionados por año contienen solo rutas canónicas indexables, y la compilación falla cuando la paridad del sitemap, la propiedad canónica, la alcanzabilidad de rastreo, los límites de metadatos o los enlaces de mismo origen se desvían.

La indexabilidad también se retiene de los hijos de recetas generados en masa. Las 72 recetas de higiene de código de desarrollo y las 39 recetas de marcos de cumplimiento generadas permanecen navegables desde sus centros canónicos con noindex,follow mientras comparten un método común. Una puerta de similitud de cuerpo renderizado acotada evita que un hijo vuelva a entrar en los sitemaps hasta que su evidencia, ejemplos y pruebas sean materialmente distintos. Los centros permanecen indexables y llevan el contexto de descubrimiento compartido.

Después de un lanzamiento con impacto en SEO, la revisión pública debe coincidir con el commit de fusión antes del envío del sitemap o la inspección de URL. La guía de despliegue de Caddy documenta la transferencia de Search Console verificada por DNS, las comprobaciones prioritarias de URL en vivo, el envío del sitemap, las solicitudes de indexación y el monitoreo de consultas. El envío es una pista de descubrimiento; no garantiza la indexación ni un ranking particular.

El pilar de remediación también registra un ejemplo de repositorio público para CVE-2026-13149 en brace-expansion. Vincula el cambio solo de dependencia con la solicitud de extracción revisada, las pruebas, la evidencia de aviso y la ruta de recuperación, separando explícitamente el trabajo no relacionado de Fail2Ban del mismo PR.

Related MCP server: CVE Intelligence MCP Server

Para qué sirve este proyecto

Los agentes de codificación con IA pueden ayudar a cerrar hallazgos de seguridad cuando su trabajo está acotado: un hallazgo, una receta, una salida revisada.

security-recipes.ai ayuda a los equipos a responder:

• ¿Qué receta coincide con este hallazgo?

• ¿Qué prompt debería usar el agente?

• ¿Dónde pongo las instrucciones para Copilot, Claude, Cursor, Codex o Devin?

• ¿Qué servidores MCP debería leer el agente para contexto de avisos, escáner, repositorio o runbook?

• ¿Qué debería incluir la nota de PR o triaje antes de que un revisor la confíe?

Qué incluye

• Sitio de documentación Eleventy (compilaciones estáticas rápidas, sin cadena de herramientas Go).

• Página de inicio de observatorio centrada en CVE y base de datos CVE centrada en datos.

• Centros de recetas para remediación de dependencias, SAST, datos sensibles, imagen base, CVE y endurecimiento predeterminado.

• Política de ingesta de inteligencia CVE, prompt, fixtures y evaluador para enrutar señales de avisos antes de que un agente parchee.

• Un catálogo CVE completo y continuo de diez años de severidad Media/Alta/Crítica compuesto por feeds NVD JSON 2.0 verificados por integridad, metadatos CISA KEV y cada arquetipo de remediación examinado aplicable. Solo las páginas Markdown stable revisadas anulan esa línea base conservadora.

• Una lista de permitidos de búsqueda con hash de integridad que publica páginas CVE canónicas solo para Markdown estable revisado o enriquecimiento de IA que pase el contrato de evidencia determinista listo para recetas. La base de datos completa sigue siendo buscable incluso cuando un registro no es elegible para indexación de búsqueda.

• Un contrato de cambio agéntico versionado de siete fases para cada CVE del catálogo: descubrir, evaluar, mitigar, remediar, verificar, revertir y triar. Cada acción declara objetivos de archivo probables, límites de mutación y aprobación, evidencia requerida, salidas y comportamiento ante fallos sin adivinar un parche o una versión fija.

• Una biblioteca de cumplimiento estructurada que abarca 39 marcos de seguridad, privacidad, aseguramiento, resiliencia y cadena de suministro de software sin reproducir texto de control con licencia. Su centro de marcos es la superficie de búsqueda; las evaluaciones hijas con plantilla permanecen noindex,follow hasta que se diferencien.

• Una biblioteca de higiene de código de 72 recetas que cubre flujos de trabajo de auditoría, remediación, verificación y condiciones de detención específicos de ecosistemas y entre lenguajes. Sus hijos de desarrollo permanecen noindex,follow mientras sus cuerpos comparten una plantilla generada.

• Recetas con colecciones de prompts existentes preservadas.

• Guías de configuración de agentes para GitHub Copilot, Claude, Cursor, Codex y Devin.

• Guía de integración MCP para fuentes de datos de seguridad públicas y aprobadas por la organización.

• Servidor FastMCP opcional de solo lectura en mcp_server.py para búsqueda de recetas, recuperación y contexto MCP ascendente opcional.

• Configuración de Docker y Docker Compose para alojamiento local o en droplet.

• Scripts auxiliares para mantenimiento del sitio, validación, importaciones y despliegue.

Mapa del repositorio

Áreas de contenido principales

• CVE Database: inteligencia CVE con fuentes, evidencia de versiones afectadas y registros canónicos de remediación.

• AI Vulnerability Remediation: guías de ejecución (playbooks) con control de evidencia, desde un hallazgo hasta un parche revisado o una nota de triaje.

• AI Agent Security: modelado de amenazas, líneas base de producción, límites de fuentes, enrutamiento de controles, evidencia y preparación para incidentes del propio sistema de agentes de IA.

• Quick Start: de un hallazgo a una PR revisada o una nota de triaje.

• AI Agent Comparison: modos de funcionamiento verificados, instrucciones nativas, artefactos esperados, requisitos previos y puertas de revisión para Copilot, Claude Code, Cursor, Codex y Devin.

• Recipes: indicaciones (prompts) reutilizables, instrucciones, reglas, habilidades y listas de verificación de revisión.

• MCP Integration: cómo conectar el contexto de seguridad de forma segura.

• Visual Guide: el flujo cualificado de descubrimiento por búsqueda, de CVE a plan, prueba, reversión, revisión y MCP de solo lectura en cinco diagramas.

• Docs: uso del sitio, patrones de consumo de agentes y guía de contribución.

Herramientas de remediación en Python

La suite de Python es un compañero de ejecución opcional para la documentación. Puede inspeccionar un espacio de trabajo acotado, seleccionar cualquiera de los 75 playbooks de remediación, crear un paquete de ejecución duradero, registrar evidencia con hash de integridad y verificar el paquete antes de la entrega al agente o al revisor. Sigue siendo local y conservadora: no fusiona código, no despliega cambios ni llama a sistemas externos por sí sola.

python scripts/security_recipes_remediation_suite.py playbook list
python scripts/security_recipes_remediation_suite.py playbook inspect \
  --playbook vulnerable-dependencies --workspace .
python scripts/security_recipes_remediation_suite.py playbook start \
  --playbook vulnerable-dependencies --workspace . \
  --finding finding.json --run-dir .security-recipes/runs/dependency-fix
python scripts/security_recipes_remediation_suite.py playbook verify \
  --run-dir .security-recipes/runs/dependency-fix

El repositorio también incluye generadores y evaluadores específicos de dominio para playbooks que necesitan paquetes de evidencia más completos o decisiones de política en tiempo de ejecución. El sitio y el registro JSON siguen siendo útiles sin Python; las herramientas hacen que los mismos contratos de flujo de trabajo sean directamente ejecutables por CI, orquestadores y agentes de codificación aprobados.

Ayudantes de despliegue que conviene conocer:

• scripts/setup_digitalocean_droplet.sh: arranque de droplet Ubuntu con Docker, endurecimiento del host y HTTPS opcional gestionado por Caddy.

• scripts/configure_nginx_letsencrypt.sh: configuración del proxy inverso nginx del host para equipos que prefieren Let's Encrypt en nginx en lugar de Caddy.

• README.nginx-letsencrypt.md: guía paso a paso centrada en el operador para la ruta de despliegue con nginx.

Modelo operativo recomendado:

1. Deje que los sistemas existentes de SCA, SAST, secretos, CI, nube y ticketing generen hallazgos.

2. Adjunte una receta de security-recipes.ai y una indicación (prompt) coincidentes.

3. Deje que el agente lea únicamente los archivos y el contexto MCP necesarios para el hallazgo.

4. Exija pruebas y revisión humana antes de la fusión.

5. Mantenga la automatización amplia, el acceso de escritura y el despliegue fuera del primer bucle.

Guía y herramientas de ejecución

El sitio es una guía para el trabajo de remediación: recetas, indicaciones (prompts), configuración de agentes, notas de integración MCP/API y patrones de revisión. La automatización en tiempo de ejecución pertenece al host de agentes aprobado por el usuario, al sistema de CI, al flujo de trabajo de ticketing o a la plataforma de escáner, y no a un chatbot alojado en el sitio.

Las herramientas de Python en scripts/, tools/ y mcp_server.py ayudan a los mantenedores y a quienes autoalojan el servicio con paquetes de ejecución de playbooks, verificación de evidencia, evaluación y generación específicas de dominio, validación, importación de avisos, búsqueda de recetas y acceso MCP opcional de solo lectura.

Servidor MCP opcional

El servidor MCP es de solo lectura por defecto. Su función básica es permitir que los agentes compatibles con MCP busquen y recuperen recetas. Los despliegues autoalojados también pueden configurarlo como un centro de contexto para servidores MCP ascendentes aprobados, sin exponer esas credenciales en el sitio público.

El contexto recuperado nunca otorga autoridad de mutación. Cualquier conector que pueda modificar repositorios, tickets, secretos, despliegues o sistemas de producción debe configurarse y aprobarse por separado en el host que lo invoca.

Herramientas comunes:

• recipes_search

• recipes_list

• recipes_get

• recipes_cve_catalog_info

• recipes_cve_search

• recipes_cve_get

• recipes_match_finding

• recipes_playbooks_list

• recipes_playbook_get

• recipes_playbook_plan

• recipes_mcp_upstream_servers

• recipes_mcp_upstream_tools

• recipes_mcp_upstream_call

• recipes_mcp_upstream_context

El servidor MCP acepta ambos feeds de recetas generados:

• /api/recipes.json es el feed preferido para agentes, con metadatos de categoría, severidad, CVE/GHSA, ecosistema y entrega.

• /recipes-index.json sigue siendo compatible para consumidores heredados.

• /recipes-browser.json es el feed compacto de biblioteca interactiva. La página /recipes/ renderiza en el servidor 18 tarjetas de recetas rastreables y una semilla de hidratación exactamente coincidente, y solicita el feed completo solo cuando un visitante enfoca la búsqueda, filtra, ordena, sigue una URL filtrada o carga más contenido.

El catálogo CVE completo también está disponible sin MCP:

• /api/cve-catalog/manifest.json declara la política exacta de fecha/severidad, los hashes de las fuentes, los recuentos de cobertura y el inventario de fragmentos.

• /api/cve-catalog/runtime-summary.json es el pequeño arranque del navegador con totales de cobertura y versiones de caché derivadas del contenido para cada recurso en tiempo de ejecución.

• /api/cve-catalog/index.json es un manifiesto pequeño para las particiones completas por año de publicación en /api/cve-catalog/indexes/. Los consumidores sin conexión pueden obtener solo los años que necesitan; ni la carga de una página del navegador ni una consulta MCP exacta analizan esas particiones.

• /api/cve-catalog/search es el endpoint acotado de búsqueda amplia de mismo origen. Está fijado a la revisión del conjunto de fragmentos declarada por runtime-summary.json, con límite de velocidad en nginx, y devuelve como máximo 100 vistas previas. La imagen MCP de producción lo sirve desde una base de datos SQLite FTS de solo lectura, construida y verificada archivo por archivo contra el mismo manifiesto. El simple enfoque y un identificador CVE-YYYY-NNNN incompleto no generan ninguna solicitud de búsqueda.

• /api/cve-catalog/records/{cve} es el endpoint acotado de mismo origen para registros exactos. Cada solicitud fija la revisión del conjunto de fragmentos, y el servicio MCP verifica y abre únicamente el fragmento determinista que contiene ese CVE. Los navegadores actuales usan este endpoint en lugar de conocer el espacio de nombres de fragmentos.

• /api/cve-catalog/browser-index.json.gz permanece durante una ventana de compatibilidad cuando un resumen de tiempo de ejecución más antiguo no declara las API de búsqueda y registro. Los navegadores actuales no lo descargan cuando las API están declaradas, por lo que los visitantes ya no asumen el coste de transferencia o memoria del corpus completo.

• Las páginas CVE canónicas renderizan en el servidor su resumen, la evidencia de versiones afectadas, la autoridad de remediación seleccionada, la entrega de implementación y verificación con IA, las fuentes, la procedencia, la cita y el esquema. No incrustan ni hidratan la aplicación del catálogo. Un enlace compacto al fragmento JSON Lines gzip exacto sigue disponible para la procedencia legible por máquina sin añadir una descarga al navegador.

• /api/cve-catalog/search-indexable.json es la lista de permitidos compacta y con hash de integridad para páginas CVE canónicas, enlaces de CVE relacionados y descubrimiento por búsqueda. Su política solo acepta Markdown estable revisado o enriquecimiento completo con IA que supere el contrato determinista de evidencia lista para receta. Cada resultado del navegador enlaza a su registro local /cve/<ID>/. Los registros de la lista de permitidos se materializan como páginas estáticas indexables; todos los demás registros usan el renderizador acotado en tiempo de ejecución con noindex,follow y conservan su fuente oficial de CVE.org en el registro.

• /api/cve-catalog/archetypes.json contiene los contratos de remediación revisados que se usan para componer una receta conservadora para cada registro del catálogo. También contiene el esquema versionado de acciones de agentes y las pistas de archivos objetivo específicas de ecosistema compartidas por el navegador y el servidor MCP.

• Cada partición asigna cada CVE dentro del alcance a su fragmento JSONL comprimido con hash de integridad. Los registros de los fragmentos contienen CVSS, CWE, CPE acotado, referencia y procedencia KEV para la recuperación exacta de CVE.

• Para mantener los registros acotados, un fragmento almacena como máximo 12 filas de CPE/versión vulnerables junto con el total de coincidencias de la fuente y una marca explícita de truncamiento; los consumidores deben seguir la evidencia de NVD/proveedor cuando esa marca esté activada.

Las páginas canónicas de CVE usan un conjunto de referencias primarias para la lista de fuentes visible y las citas de datos estructurados. Los registros generados en bruto admiten NVD, CVE.org, registros CISA KEV con alcance, y avisos de proveedor, parches, notas de versión o mitigaciones vinculados a la fuente; los enlaces rotos, de solo terceros, solo de exploits y de bases de datos de vulnerabilidades genéricas no se promocionan automáticamente. El Markdown estable revisado puede citar deliberadamente evidencia HTTPS adicional en su sección de Referencias. Cuando la remediación abarca varias ramas compatibles o familias de productos, la acción mostrada conserva cada afirmación de versión corregida de confianza en lugar de reducir la guía a una única actualización incompleta.

El Markdown de CVE estable de desarrollo y propiedad del catálogo no genera ninguna página independiente en la compilación estática pura y queda excluido de Eleventy y de los feeds genéricos de recetas/búsqueda, páginas de etiquetas, RSS y el mapa del sitio. Las tres recetas estables históricas previas al catálogo siguen siendo contenido renderizado ordinario. La producción puede conservar una URL de receta heredada como redirección a la ruta canónica de CVE mediante nginx y el servicio de aterrizaje respaldado por MCP. Use el catálogo dedicado o las herramientas MCP recipes_cve_* para un descubrimiento completo.

La ruta de ID exacto del navegador y la API de búsqueda fijada por revisión cubren todos los registros Medium, High y Critical dentro del alcance declarados por el manifiesto. El servidor MCP expone la misma cobertura respaldada por SQLite a través de recipes_cve_search; una llamada exitosa a recipes_cve_get devuelve el registro fuente normalizado, los identificadores y referencias de la fuente, los arquetipos aplicables, el contrato de remediación compuesto y un agentic_change_plan autocontenido. El plan expande cada instrucción de mitigación y remediación en operaciones ordenadas de código/archivo con requisitos de verificación, reversión, evidencia, aprobación y triaje. También conserva los metadatos explícitos de truncamiento de CPE cuando el conjunto de coincidencias de la fuente supera el registro acotado.

Sincronización diaria de CVE y enriquecimiento opcional con IA

.github/workflows/cve-catalog-sync.yml se ejecuta todos los días a las 09:23 UTC y también puede ejecutarse manualmente. Verifica y combina los feeds anuales NVD JSON 2.0 y el catálogo CISA KEV, regenera cada índice/fragmento del catálogo, valida el resultado, actualiza la evidencia determinista derivada de recetas en orden de dependencias, ejecuta las pruebas del catálogo y abre o actualiza automation/cve-catalog-sync como solicitud de extracción a la rama predeterminada. Los Settings > Actions > General > Workflow permissions del repositorio deben permitir que GitHub Actions cree solicitudes de extracción para la publicación del PR en la primera ejecución.

Establezca CVE_AUTO_MERGE_ENABLED=true para entregar un PR de catálogo aprobado por seguridad después de que su revisión exacta pase el flujo de validación dedicado. Cuando se configuran CVE_AUTOMATION_APP_CLIENT_ID y el secreto CVE_AUTOMATION_APP_PRIVATE_KEY, el flujo prefiere esa identidad de GitHub App para que las ejecuciones ordinarias de Build de PR y rama principal se disparen de forma natural. Sin credenciales de App, el flujo sigue siendo automático: después de la fusión protegida con GITHUB_TOKEN, verifica que el SHA de fusión devuelto sigue siendo el main actual y luego despacha el flujo real build.yml con ese SHA exacto. La puerta de despliegue de producción solo reconoce esos despachos de Build cualificados para CVE, por lo que los monitores programados y los flujos manuales no relacionados no pueden bloquear ni satisfacer una versión.

La sincronización de fuentes no requiere un secreto. La revisión de sobras de oro, la actualización de contenido, el mantenimiento de IA, el mantenimiento de incidencias de IA y la acción de salud de seguridad de este repositorio también usan Grok. Añada un secreto de Actions llamado XAI_API_KEY (la variable de entorno oficial de xAI; no use GROK_API_KEY):

gh secret set XAI_API_KEY --repo stevologic/security-recipes.ai

El flujo usa por defecto el modelo de API Responses grok-4.6 de xAI y como máximo 20 registros nuevos o con cambios de fuente por ejecución. La cola programada se deriva del catálogo NVD/CISA rastreado: un candidato debe tener un aviso de proveedor, parche, nota de versión o URL de mitigación etiquetado y válido. Los registros completos de fuente siguen siendo elegibles porque aún necesitan una síntesis de remediación con fuente; dentro de cada banda KEV y de gravedad se clasifican por delante de los registros con brechas de fuente deterministas, seguidos de la evidencia de producto/versión afectados y la actualidad. Esto usa el presupuesto diario de solicitudes existente y no requiere una ejecución manual adicional. Tanto el modelo como el límite se pueden cambiar con variables opcionales de Actions; el límite de enriquecimiento está acotado estrictamente de 0 a 50:

gh variable set XAI_MODEL --body "grok-4.6" --repo stevologic/security-recipes.ai
gh variable set XAI_ENRICHMENT_LIMIT --body "20" --repo stevologic/security-recipes.ai

La salida de IA es complementaria y está etiquetada explícitamente. Usa salida estructurada estricta, solo cita URL realmente devueltas en la procedencia de búsqueda web de la API Responses y se almacena de forma reproducible en data/cve/ai-enrichments.json. Un enriquecimiento completo se convierte en un borrador de Markdown específico de CVE solo cuando una puerta separada encuentra evidencia a nivel de afirmación de producto afectado, exposición, remediación y verificación vinculada a la URL exacta de una referencia de aviso de confianza etiquetada. Cada afirmación requerida debe cumplir esa regla de forma independiente, y cada receta generada requiere una afirmación de versión corregida concreta y citada.

El enriquecimiento en caché se reevalúa en lugar de volverse permanente: las entradas listas para receta se convierten en candidatas de actualización después de 30 días, las entradas KEV después de 60 días y otras entradas completas/no específicas o con evidencia insuficiente después de 180 días. Un CVE priorizado manualmente fuerza una actualización dentro del límite de solicitudes existente. El último resultado válido en caché permanece adjunto si esa actualización falla; una huella de fuente no válida permanece en modo de fallo cerrado. El informe de sincronización y el resumen de salud de automatización exponen los recuentos de actualización pendiente y priorización manual.

Los borradores elegibles se escriben como archivos maturity: development llamados content/recipes/cve/ai-enrichment-cve-*.md. Quedan fuera del descubrimiento genérico de recetas y nunca anulan una receta estable revisada. Un revisor humano puede establecer ai_enrichment_review_status: human-reviewed-development-draft para retener un enriquecimiento listo para evidencia de la autoridad pública de remediación, o ai_enrichment_review_status: approved-for-ai-authority para aprobar ese uso. Los borradores sin anotación propiedad del generador conservan la puerta de evidencia automatizada, mientras que el Markdown estable siempre gana. El libro de contabilidad de propiedad en data/cve/ai-generated-recipes.json registra el hash de cada archivo generado; la automatización solo puede actualizar o eliminar un borrador sin modificar que coincida con el hash. Una edición humana, o cualquier receta humana de desarrollo/estable existente para el mismo CVE, hace que ese Markdown sea de propiedad humana y bloquea el reemplazo automatizado. La generación de IA nunca cambia los hechos CVSS/KEV de la fuente, los datos de versiones afectadas, la selección de arquetipos ni el Markdown estable revisado. Una clave faltante, una negativa de API, un tiempo de espera o un límite de velocidad no bloquean la actualización de NVD/CISA; las llamadas se detienen después de tres fallos consecutivos o un presupuesto de 15 minutos, y los enriquecimientos válidos en caché permanecen adjuntos. Una ejecución manual puede priorizar CVEs nombrados, pero esos IDs consumen espacios dentro del límite existente de esa ejecución y nunca omiten la puerta de evidencia lista para receta:

gh workflow run cve-catalog-sync.yml --ref main \
  -f ai_enrichment_limit=20 \
  -f priority_cve_ids="CVE-2026-58644,CVE-2026-56164"

Un despacho manual es una ejecución de flujo adicional y, por lo tanto, puede hacer solicitudes adicionales; no es necesario para la cola determinista diaria. Una ejecución manual en una rama no predeterminada sube su caché de enriquecimiento, libro de contabilidad de propiedad y borradores generados como un artefacto de flujo de corta duración para revisión.

.github/workflows/leftover-review.yml se ejecuta todos los días a las 13:17 UTC y verifica en vivo las sobras de oro de CVE restantes contra GitHub Advisories y NVD. Los críticos y altos de sobras de oro se drenan primero. Después de que esos se cierran, cada ejecución revisa hasta 100 páginas de sobras de oro medias y bajas, registra los IDs completados en data/cve/leftover-review-state.json y abre un PR de auto-fusión etiquetado. El trabajo de revisión de sobras usa el CLI de Grok Build con XAI_API_KEY y no hace nada cuando ese secreto falta o la cola de sobras de oro está vacía.

Las rutas de ejecución están deliberadamente acotadas para tráfico a escala de catálogo:

• el hub arranca desde el resumen de ejecución compacto, las búsquedas exactas llaman a la API de registros de mismo origen fijada por revisión, y la búsqueda de título/producto/proveedor/filtro llama a la API de búsqueda solo después de una intención de búsqueda explícita;

• la búsqueda amplia devuelve como máximo 100 vistas previas desde SQLite de solo lectura inmutable, tiene un límite HTTP de tres segundos y nunca decodifica el catálogo completo en un proceso de visitante ni en el hilo principal del navegador;

• el servicio de registros exactos verifica y abre un fragmento por solicitud; la recuperación exacta de MCP usa la misma ruta de solo fragmentos, mientras que la búsqueda de texto no exacta usa la base de datos SQLite fijada por manifiesto detrás de un ejecutor dedicado, cola de admisión acotada, plazos de consulta y límite de velocidad de nginx;

• las claves de caché de navegador inmutables provienen del contrato de registro/búsqueda declarado, el hash de arquetipo y la revisión del conjunto de fragmentos en lugar de una marca de tiempo ascendente.

El límite de compilación implementado, el modelo de entrega de fragmentos exactos, la política de SEO con puerta de evidencia, el tiempo de ejecución de búsqueda SQLite y la migración restante de publicación de artefactos están documentados en Arquitectura de escala de CVE.

La imagen de producción compila el artefacto SQLite una vez en su capa de imagen en caché, registra su sidecar SHA-256 independiente y valida el esquema, la revisión del catálogo, el recuento de registros, el resumen del manifiesto, el resumen del archivo y las publicaciones FTS representativas al inicio. RECIPES_MCP_EAGER_CVE_SEARCH ahora se aplica solo al respaldo local heredado cuando no hay una ruta SQLite configurada. Para tráfico de búsqueda sostenido, ejecute múltiples instancias MCP emparejadas; las lecturas de fragmentos exactos permanecen aisladas del ejecutor de búsqueda de texto acotado y su cola.

Ejecute npm run icons después de cambiar la marca del sitio. Regenera el icono de toque de Apple opaco y los activos de aplicación instalada 192/512/maskable verificados por la puerta de rendimiento de producción.

Las compilaciones de producción precomprimen los feeds JSON/XML grandes para gzip_static de nginx, validan los límites de descubrimiento estable/borrador y aplican presupuestos de carga útil/recuento de archivos con npm run check:performance.

Ejecútelo con Docker:

docker build -f Dockerfile.mcp-server -t security-recipes-mcp .
docker run --rm -p 8123:80 security-recipes-mcp

Conecte un cliente MCP a:

http://localhost:8123/mcp

Ejecútelo localmente con Python:

python -m venv .venv
source .venv/bin/activate
pip install -r requirements-mcp-server.txt
python mcp_server.py

Activación de Windows PowerShell:

.\.venv\Scripts\Activate.ps1
python mcp_server.py

Ejecutar el sitio localmente

Requisitos previos:

• Node.js >= 20

• Python >= 3.10 con requirements-mcp-server.txt instalado para el paso de prerenderizado de CVE de npm run build de producción

• Git

python -m pip install -r requirements-mcp-server.txt
npm install
npm run serve

Abra:

http://localhost:8080

npm run serve observa los cambios y recompila de forma incremental. Una compilación de producción única es npm run build (la salida se coloca en public/). La compilación realiza una verificación previa de Python/dependencias antes de eliminar una salida existente y luego usa el mismo renderizador de CVE que el tiempo de ejecución de MCP. Eleventy deliberadamente no copia por paso static/api/cve-catalog/: después de la materialización de la página, un paso posterior a la compilación acotado rechaza enlaces, archivos huérfanos, rutas inseguras y discrepancias de bytes/hash del manifiesto antes de instalar ese subárbol del catálogo. Los activos estáticos fuera del catálogo, incluidos los archivos de puntos raíz, conservan el comportamiento normal de paso.

Para una compilación de catálogo aislada, establezca SECURITY_RECIPES_CVE_CATALOG_ROOT en su directorio de publicación absoluto. Los datos de Eleventy, la materialización de páginas cualificadas y la copia validada del catálogo usan esa misma raíz. npm run serve no vuelve a ejecutar el materializador ni la copia del catálogo, así que ejecute npm run build una vez primero cuando necesite páginas canónicas /cve/<ID>/ y el árbol de API del catálogo en el servidor de desarrollo; las recompilaciones incrementales posteriores conservan esas salidas posteriores a la compilación.

Docker Compose

Cree un archivo de entorno:

cp .env.example .env

Inicie la pila:

docker compose up -d --build

Use el plugin Docker Compose v2 (docker compose). El paquete Python heredado docker-compose v1 no es compatible con esta pila; puede fallar con KeyError: 'id' al seguir los registros o KeyError: 'ContainerConfig' al recrear contenedores en versiones más nuevas de Docker Engine.

En hosts Ubuntu/Debian, instale Compose v2 y un shim de compatibilidad con:

sudo bash scripts/install_docker_compose_v2.sh

Rutas predeterminadas:

site: http://127.0.0.1:8080/
agent recipe feed: /api/recipes.json
MCP endpoint: /mcp

La pila de Compose mantiene el sitio público y su renderizador dinámico de CVE/MCP en pares azul/verde coincidentes:

• security-recipes / mcp-server-blue: sitio azul y renderizador.

• security-recipes-green / mcp-server-green: sitio verde y renderizador.

• mcp-server: singleton transitorio conservado para el primer despliegue por pares y para flujos de trabajo Compose manuales compatibles con versiones anteriores. Lee el feed del sitio compilado localmente en http://security-recipes/api/recipes.json, de modo que un fork o droplet sirve sus propias recetas en lugar de depender del índice público de producción.

deploy.sh inicia y verifica la revisión del contenedor MCP del slot retirado antes que su contenedor de sitio, valida directamente un CVE canónico y solo entonces admite el par en Caddy. El arranque manual con Compose conserva el singleton predeterminado para que el primer despliegue siga siendo compatible con el script instalado anteriormente.

Para un proxy inverso nginx o Caddy con Let's Encrypt, mantén Docker vinculado a loopback y deja que el proxy sea el propietario de los puertos públicos 80 y 443:

SECURITY_RECIPES_HTTP_PORT=127.0.0.1:8080

Luego haz proxy hacia:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Si quieres una configuración llave en mano de nginx + Let's Encrypt en el host, ejecuta:

sudo bash scripts/configure_nginx_letsencrypt.sh \
  --domain security-recipes.ai \
  --email admin@security-recipes.ai

La guía completa del operador está en README.nginx-letsencrypt.md.

Droplet de DigitalOcean

Para un droplet Ubuntu nuevo, usa el script auxiliar:

sudo bash scripts/setup_digitalocean_droplet.sh \
  --domain security-recipes.ai \
  --email admin@security-recipes.ai

El script instala Docker/Compose, configura un usuario de aplicación bloqueado, habilita un endurecimiento básico del host, inicia el stack Compose y puede colocar Caddy delante para HTTPS. También habilita una jaula Fail2Ban compatible con Caddy: cinco respuestas HTTP 404 finales para rutas de sondeo de exploits de alta confianza (por ejemplo, sondeos de .env, Git, WordPress, phpMyAdmin o PHPUnit) desde un mismo cliente en cinco segundos bloquean esa dirección en los puertos TCP y HTTP/3 del sitio durante una hora, tras lo cual el acceso se restaura automáticamente. Las páginas inexistentes ordinarias, los fallos con forma de CVE y los fallos de paginación del archivo no consumen el presupuesto de bloqueo.

Apunta tanto el registro DNS del apex como el de www al Droplet antes de la configuración. El Caddy gestionado obtiene certificados para ambos nombres y redirige permanentemente www al host canónico del apex; redirigir solo en HTTP dejaría a los rastreadores HTTPS sin poder completar el handshake TLS.

Los Droplets existentes necesitan esta activación única e idempotente después de desplegar el commit que contiene la jaula:

sudo bash scripts/configure_caddy_404_ban.sh
sudo fail2ban-client status security-recipes-caddy-404

Si el Droplet sigue ejecutando el Caddy incluido con el antiguo volumen de registros con nombre, primero establece SECURITY_RECIPES_TRAFFIC_LOGS_SOURCE=/var/log/caddy en .env y luego recrea solo Caddy una vez durante una ventana de mantenimiento:

docker compose --profile caddy up -d \
  --no-deps --force-recreate --pull never caddy
sudo bash scripts/configure_caddy_404_ban.sh

El filtro usa el client_ip estructurado de Caddy, no cabeceras de reenvío falseables ni valores de User-Agent. Si el origen se coloca más tarde detrás de una CDN o un balanceador de carga, mueve la acción de bloqueo al WAF/API de ese proveedor; un firewall de origen no puede bloquear directamente a un cliente final cuyos paquetes llegan desde un proxy de confianza.

La jaula no confía en las cadenas de User-Agent de Googlebot. Antes de contar a un cliente público, realiza la comprobación DNS inversa y luego directa de Google: el nombre de host PTR debe estar bajo googlebot.com, y resolver ese nombre de host debe devolver la misma IP. Los resultados se cachean por IP durante una hora; los errores de búsqueda y el plazo de cinco segundos del resolvedor fallan en modo cerrado, por lo que un cliente no verificado sigue sujeto al presupuesto de 404 para rutas de escáner.

Para un despliegue Caddy totalmente gestionado por Compose, Fail2Ban puede ejecutarse en su lugar dentro del stack. Establece DEPLOY_COMPOSE_FAIL2BAN=true en .env y mantén la fuente de registros de Caddy en el volumen caddy_logs predeterminado (o un bind al host). En su siguiente ejecución, deploy.sh extrae, inicia, comprueba el estado y posteriormente actualiza el contenedor Fail2Ban. También inicializa el archivo de registro de acceso de Caddy antes de iniciar la jaula porque Fail2Ban requiere que el archivo configurado exista. Para iniciarlo manualmente sin esperar a un despliegue, usa:

docker compose up -d caddy fail2ban
docker compose exec fail2ban fail2ban-client status security-recipes-caddy-404

El contenedor comparte el namespace de red del host y solo tiene las capacidades NET_ADMIN/NET_RAW necesarias para aplicar las reglas nftables de la jaula al tráfico web del host y al reenviado por Docker. No habilites la jaula Compose mientras la jaula security-recipes-caddy-404 del host esté activa; elige un único propietario para las reglas del firewall. Esto mitiga el escaneo repetido de 404 a nivel de aplicación, pero no sustituye a la protección volumétrica contra DDoS ni a la limitación de velocidad de solicitudes aguas arriba. Cuando la opción es false, deploy.sh no requiere el paquete fail2ban del host; las instalaciones gestionadas por el host siguen siendo responsabilidad de la configuración del droplet y de los flujos de trabajo de scripts/configure_caddy_404_ban.sh.

Si prefieres nginx en lugar de Caddy en el droplet, arranca el host sin el proxy y luego ejecuta el auxiliar de nginx:

sudo bash scripts/setup_digitalocean_droplet.sh --no-caddy
sudo bash scripts/configure_nginx_letsencrypt.sh \
  --domain security-recipes.ai \
  --email admin@security-recipes.ai

Para un droplet solo local o con proxy previo:

sudo bash scripts/setup_digitalocean_droplet.sh --no-caddy --no-firewall --no-upgrade
docker compose up -d --build

Si una ejecución anterior de docker-compose v1 falló con KeyError: 'ContainerConfig', actualiza Compose y elimina los contenedores obsoletos del proyecto antes de recrear el stack:

sudo bash scripts/repair_docker_compose_containerconfig.sh
hash -r
command -v docker-compose
docker-compose version

Los despliegues de producción extraen las imágenes de sitio y MCP direccionadas por commit publicadas por el flujo de trabajo Build de GitHub Actions requerido en main y las sirven en https://security-recipes.ai/. El mismo temporizador también despliega las imágenes de development en https://dev.security-recipes.ai/. El Droplet no ejecuta Node, Eleventy, pip ni compilaciones de imágenes Docker durante un despliegue, lo que mantiene el despliegue dentro de un límite de 1 CPU / 2 GB de memoria.

Actualización única del despliegue MCP por pares

Antes del primer despliegue que introduzca los servicios MCP por pares, actualiza solo el script de despliegue y luego ejecútalo. Un proceso deploy.sh anterior ya en ejecución se analizó antes de que existiera el archivo Compose por pares y, de otro modo, recrearía el singleton MCP activo durante ese despliegue:

git fetch origin main
git checkout origin/main -- deploy.sh
bash deploy.sh

El nuevo script deja intacto el singleton activo, prepara juntos el MCP y el sitio inactivos y los cambia como una sola unidad. Tras este paso único, la entrada de cron bash deploy.sh existente no necesita cambios.

El primer flujo de trabajo main exitoso crea dos paquetes GHCR. Hazlos públicos o autentica la cuenta raíz utilizada por el servicio de despliegue con un token de grano fino que pueda leer paquetes:

printf '%s' "$GHCR_READ_TOKEN" |
  sudo docker login ghcr.io --username stevologic --password-stdin

Filosofía de integración MCP

Usa MCP para dar contexto a los agentes, no autoridad sin control.

Las herramientas MCP de CVE solo devuelven planes y evidencia; no editan un repositorio ni cambian un entorno. Un host de agente aprobado puede aplicar el plan devuelto, pero primero debe demostrar la superficie afectada y las rutas reales del repositorio, preservar los cambios no relacionados, obtener cualquier aprobación declarada de producción/externo y conservar un rollback utilizable mecánicamente. Un glob de archivos probable es una pista de descubrimiento, nunca una prueba de que un archivo sea vulnerable ni un permiso para modificarlo. Dentro de cada acción, solo los target_kinds efectivos son candidatos predeterminados. Los archetype_target_kinds son contexto, no autorización; los objetivos condicionales requieren prueba de que el repositorio posee la implementación afectada, mientras que los objetivos prohibidos nunca deben editarse. Los objetivos de firmware y binarios implican una referencia autoritativa, un pin, un reemplazo, una política, un inventario, una fuente o un cambio de compilación, nunca parchear bytes de artefactos del proveedor.

Las descripciones de NVD/CNA, avisos, enlaces, parches, comentarios de incidencias, notas de versión y contenido de prueba de concepto son evidencia no confiable. Los agentes pueden extraer de ellos hechos corroborados de vulnerabilidad y versión, pero no deben ejecutar ni seguir instrucciones o comandos incrustados.

Las buenas fuentes de contexto incluyen:

• capacidades MCP oficiales de GitHub para contexto de repositorio y seguridad de código,

• integraciones agénticas/MCP de Semgrep y Snyk donde estén aprobadas,

• OSV, GitHub Advisories, deps.dev, registros de paquetes y espejos basados en NVD,

• fuentes SARIF, SBOM, CI, propiedad y runbooks internos,

• conectores de documentación de solo lectura.

Los conectores con capacidad de escritura merecen una revisión aparte. La creación de incidencias, la mutación de ramas, el despliegue, la rotación de secretos, los cambios en la nube y las acciones SOAR no deberían habilitarse solo porque un agente pueda leer una receta.

Contribuciones

Las contribuciones deberían mejorar la biblioteca de recetas:

• nuevas recetas de remediación,

• mejores prompts,

• una configuración de agentes más clara,

• ejemplos de integración MCP,

• listas de verificación para revisores,

• correcciones de documentación.

Depura secretos, nombres de host internos, datos de clientes y detalles de vulnerabilidades privadas antes de abrir una pull request.

Ejecuta una compilación local antes de enviar:

python -m pip install -r requirements-dev.txt
python scripts/run_checks.py
npm run build

Licencia

El código original del proyecto, la documentación, las recetas de remediación, el sitio generado y el servidor MCP están licenciados bajo la Apache License 2.0. Esto permite el uso privado y comercial, la modificación y la redistribución, incluida la incorporación en sistemas propietarios de empresas, sujeto a los requisitos de aviso y marcado de cambios de la licencia.

Los datos de vulnerabilidad de fuentes y el software de terceros incluido conservan sus propios términos y requisitos de atribución. Consulta NOTICE y THIRD_PARTY_NOTICES.md.