security-recipes.ai

Search CVEs. Remediate vulnerabilities with AI agents. Sourced facts stay sourced, remediation stays bounded, and every plan carries verification, rollback, and stop conditions — the live site's contract, and this repo's.

security-recipes.ai is an Eleventy site for sourced CVE intelligence and evidence-gated vulnerability remediation that AI agents can consume without inheriting deployment or production authority.

The project is intentionally narrow:

• a complete rolling Medium/High/Critical CVE database,
• evidence-qualified canonical CVE remediation records,
• practical security remediation recipes,
• prompt and rules-file examples,
• agent setup guides,
• MCP integration patterns,
• an optional read-only MCP server for recipe search and approved upstream MCP context,
• a reusable GitHub Action that turns this guidance into toggleable CI health checks.

It is not a scanner, ticketing system, SOAR platform, deployment tool, or custom security toolkit. Existing security tools should produce the findings; this site helps agents use the right remediation context and stop at the right time.

Start with the live CVE Database for an exact vulnerability or the AI Vulnerability Remediation Playbooks for the evidence-to-patch workflow. Agent-specific guides cover Codex, Claude Code, Cursor, GitHub Copilot, Devin, Shiba Studio, Hermes Desktop, and OpenClaw. The Visual Guide shows the complete path from source qualification and search discovery to a bounded plan, proof, rollback, and human review. For the distinct problem of securing an agent system's identities, tools, connectors, context, memory, runtime, and recovery controls, use AI Agent Security.

Current product and workflow

Qualified search discovery

The complete catalog remains searchable, while public canonical CVE pages stay limited to reviewed or evidence-qualified records. Those pages ship unique search metadata, server-rendered core facts and affected-version evidence, one remediation authority (stable reviewed guidance first, otherwise complete source-linked AI enrichment), a short approval-gated AI implementation prompt, canonical URLs, breadcrumbs, and Article/TechArticle structured data. The CVE database describes the catalog as a Dataset; the remediation pillar exposes its visible seven-step workflow as a HowTo. Year-partitioned CVE sitemaps contain only indexable canonical routes, and the build fails when sitemap parity, canonical ownership, crawl reachability, metadata limits, or same-origin links drift.

Indexability is also withheld from mass-templated recipe children. The 72 development code-hygiene recipes and 39 generated compliance-framework recipes remain browsable from their canonical hubs with noindex,follow while they share a common method. A bounded rendered-body similarity gate prevents a child from re-entering sitemaps until its evidence, examples, and tests are materially distinct. The hubs remain indexable and carry the shared discovery context.

After an SEO-bearing release, the public revision must match the merge commit before sitemap submission or URL inspection. The Caddy deployment guide documents the DNS-verified Search Console handoff, priority live-URL checks, sitemap submission, indexing requests, and query monitoring. Submission is a discovery hint; it does not guarantee indexing or a particular ranking.

The remediation pillar also records a public repository example for CVE-2026-13149 in brace-expansion. It ties the dependency-only change to the reviewed pull request, tests, advisory evidence, and recovery path while explicitly separating the same PR's unrelated Fail2Ban work.

CVE search to canonical record	CVE evidence to bounded agent plan
Proof and human review	Read-only MCP context

What this project is for

AI coding agents can help close security findings when their work is bounded: one finding, one recipe, one reviewed output.

security-recipes.ai helps teams answer:

• Which recipe matches this finding?
• Which prompt should the agent use?
• Where do I put the instructions for Copilot, Claude, Cursor, Codex, or Devin?
• Which MCP servers should the agent read for advisory, scanner, repository, or runbook context?
• What should the PR or triage note include before a reviewer trusts it?

What ships

• Eleventy documentation site (fast static builds, no Go toolchain).
• CVE-first observatory home page and data-first CVE database.
• Recipe hubs for dependency, SAST, sensitive-data, base-image, CVE, and default-hardening remediation.
• CVE intelligence intake policy, prompt, fixtures, and evaluator for routing advisory signals before an agent patches.
• A complete rolling ten-year Medium/High/Critical CVE catalog composed from integrity-verified NVD JSON 2.0 feeds, CISA KEV metadata, and every applicable vetted remediation archetype. Only reviewed stable Markdown pages override that conservative baseline.
• An integrity-hashed search allowlist that publishes canonical CVE pages only for reviewed stable Markdown or AI enrichment that passes the deterministic recipe-ready evidence contract. The full database remains searchable even when a record is not eligible for search indexing.
• A versioned seven-phase agentic change contract for every catalog CVE: discover, assess, mitigate, remediate, verify, rollback, and triage. Each action declares likely file targets, mutation and approval boundaries, required evidence, outputs, and failure behavior without guessing a patch or fixed version.
• A structured compliance library spanning 39 security, privacy, assurance, resilience, and software-supply-chain frameworks without reproducing licensed control text. Its framework hub is the search surface; templated child assessments remain noindex,follow until differentiated.
• A 72-recipe code-hygiene library covering cross-language and ecosystem- specific audit, remediation, verification, and stop-condition workflows. Its development children remain noindex,follow while their bodies share a generated template.
• Recipes with existing prompt collections preserved.
• Agent setup guides for GitHub Copilot, Claude, Cursor, Codex, and Devin.
• MCP integration guidance for public and organization-approved security data sources.
• Optional read-only FastMCP server in mcp_server.py for recipe search, retrieval, and opt-in upstream MCP context.
• Docker and Docker Compose configuration for local or droplet hosting.
• Helper scripts for site maintenance, validation, imports, and deployment.

Repository map

Path	Purpose
content/	Recipes, documentation, remediation guides, and agent setup pages.
eleventy.config.js	Site build configuration (permalinks, feeds, tag pages).
_includes/	Page layouts: docs chrome and the standalone home page.
lib/	Build modules: shortcode ports, JSON feed builders, SEO head.
assets/	Site CSS and JavaScript for the recipe browser, navigation, and helper tools.
static/	Images, logos, schemas, and static assets.
static/api/cve-catalog/	Complete sharded CVE catalog, year-partitioned machine index, compressed browser-search index, provenance manifest, and archetypes.
data/cve/	Human-reviewed remediation archetypes, deterministic AI-enrichment cache, and generated-recipe ownership ledger.
data/compliance-frameworks/	Structured compliance-framework catalog and source registry.
data/code-hygiene/	Structured code-hygiene catalog, source registry, and routing fixtures.
docs/	Repository documentation and legacy screenshot assets; current README and visual-guide images live in static/images/.
mcp_server.py	Optional read-only MCP server for recipe search and approved upstream MCP context.
mcp-server.toml.example	MCP server configuration template.
Dockerfile	Site image.
Dockerfile.mcp-server	Optional MCP server image.
docker-compose.yml	Production-style local stack.
scripts/	Helper scripts for maintenance and deployment.

Core content areas

• CVE Database: sourced CVE intelligence, affected-version evidence, and canonical remediation records.
• AI Vulnerability Remediation: evidence-gated playbooks from one finding to a reviewed patch or triage note.
• AI Agent Security: threat modeling, production baselines, source boundaries, control routing, evidence, and incident readiness for the AI-agent system itself.
• Quick Start: one finding to one reviewed PR or triage note.
• AI Agent Comparison: verified operating modes, native instructions, expected artifacts, prerequisites, and review gates for Copilot, Claude Code, Cursor, Codex, and Devin.
• Recipes: reusable prompts, instructions, rules, skills, and review checklists.
• MCP Integration: how to connect security context safely.
• Visual Guide: the qualified search-discovery, CVE-to-plan, proof, rollback, review, and read-only MCP flow in five diagrams.
• Docs: site usage, agent consumption patterns, and contribution guidance.

Python remediation tooling

The Python suite is an optional execution companion to the documentation. It can inspect a bounded workspace, select any of the 75 remediation playbooks, create a durable run packet, record integrity-hashed evidence, and verify the packet before agent or reviewer handoff. It remains local and conservative: it does not merge code, deploy changes, or call external systems on its own.

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

The repository also includes domain-specific generators and evaluators for playbooks that need richer evidence packs or runtime policy decisions. The site and JSON registry remain useful without Python; the tools make the same workflow contracts directly executable by CI, orchestrators, and approved coding agents.

Deployment helpers worth knowing:

• scripts/setup_digitalocean_droplet.sh: Ubuntu droplet bootstrap with Docker, host hardening, and optional Caddy-managed HTTPS.
• scripts/configure_nginx_letsencrypt.sh: host nginx reverse proxy setup for teams that want Let's Encrypt on nginx instead of Caddy.
• README.nginx-letsencrypt.md: operator-focused walkthrough for the nginx deployment path.

Recommended operating model:

1. Let existing SCA, SAST, secrets, CI, cloud, and ticketing systems produce findings.
2. Attach a matching security-recipes.ai recipe and prompt.
3. Let the agent read only the files and MCP context needed for the finding.
4. Require tests and human review before merge.
5. Keep broad automation, write access, and deployment outside the first loop.

Guidebook and execution tools

The site is a guidebook for remediation work: recipes, prompts, agent setup, MCP/API integration notes, and review patterns. Runtime automation belongs in the user's approved agent host, CI system, ticketing workflow, or scanner platform rather than a site-hosted chatbot.

Python tools in scripts/, tools/, and mcp_server.py support maintainers and self-hosters with playbook execution packets, evidence verification, domain-specific evaluation and generation, validation, advisory import, recipe search, and optional read-only MCP access.

Optional MCP server

The MCP server is read-only by default. Its baseline role is to let MCP-compatible agents search and retrieve recipes. Self-hosted deployments can also configure it as a context hub for approved upstream MCP servers without putting those credentials into the public site.

Retrieved context never grants mutation authority. Any connector that can change repositories, tickets, secrets, deployments, or production systems must be configured and approved separately by the calling host.

Common tools:

• 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

The MCP server accepts both generated recipe feeds:

• /api/recipes.json is the preferred agent feed with category, severity, CVE/GHSA, ecosystem, and handoff metadata.
• /recipes-index.json remains supported for legacy consumers.
• /recipes-browser.json is the compact interactive-library feed. The /recipes/ page server-renders 18 crawlable recipe cards and an exactly matching hydration seed, then requests the complete feed only when a visitor focuses search, filters, sorts, follows a filtered URL, or loads more.

The complete CVE catalog is also available without MCP:

• /api/cve-catalog/manifest.json declares the exact date/severity policy, source hashes, coverage counts, and shard inventory.
• /api/cve-catalog/runtime-summary.json is the small browser bootstrap with coverage totals and content-derived cache versions for every runtime asset.
• /api/cve-catalog/index.json is a small manifest for the complete publication-year partitions under /api/cve-catalog/indexes/. Offline consumers can fetch only the years they need; neither a browser page load nor an exact MCP lookup parses those partitions.
• /api/cve-catalog/search is the bounded, same-origin broad-search endpoint. It is pinned to the shard-set revision declared by runtime-summary.json, rate-limited at nginx, and returns at most 100 previews. The production MCP image serves it from a read-only SQLite FTS database built and whole-file verified against the same manifest. Focus alone and an incomplete CVE-YYYY-NNNN identifier make no search request.
• /api/cve-catalog/records/{cve} is the bounded, same-origin exact-record endpoint. Every request pins the shard-set revision, and the MCP service verifies and opens only the one deterministic shard containing that CVE. Current browsers use this endpoint instead of learning the shard namespace.
• /api/cve-catalog/browser-index.json.gz remains for one compatibility window when an older runtime summary does not declare the search and record APIs. Current browsers do not download it when the APIs are declared, so visitors no longer pay the complete-corpus transfer or memory cost.
• Canonical CVE pages server-render their overview, affected-version evidence, selected remediation authority, AI implementation and verification handoff, sources, provenance, citation, and schema. They do not embed or hydrate the catalog application. A compact link to the exact gzip JSON Lines shard remains available for machine-readable provenance without adding a browser fetch.
• /api/cve-catalog/search-indexable.json is the compact, integrity-hashed allowlist for canonical CVE pages, related-CVE links, and search discovery. Its policy accepts only reviewed stable Markdown or complete AI enrichment that passes the deterministic recipe-ready evidence contract. Every browser result links to its local /cve/<ID>/ record. Allowlisted records are materialized as indexable static pages; all other records use the bounded runtime renderer with noindex,follow and retain their official CVE.org source in the record.
• /api/cve-catalog/archetypes.json contains the reviewed remediation contracts used to compose a conservative recipe for every catalog record. It also contains the versioned agentic action schema and ecosystem-specific file-target hints shared by the browser and MCP server.
• Each partition maps every in-scope CVE to its integrity-hashed compressed JSONL shard. Shard records contain CVSS, CWE, bounded CPE, reference, and KEV provenance for exact-CVE retrieval.
• To keep records bounded, a shard stores at most 12 vulnerable CPE/version rows together with the source match total and an explicit truncation flag; consumers must follow NVD/vendor evidence when that flag is set.

Canonical CVE pages use one primary-reference set for the visible source list and structured-data citations. Raw generated records admit NVD, CVE.org, scoped CISA KEV records, and source-linked vendor advisories, patches, release notes, or mitigations; broken, third-party-only, exploit-only, and generic vulnerability-database links are not promoted automatically. Stable reviewed Markdown can deliberately cite additional HTTPS evidence in its References section. When remediation spans several supported branches or product families, the displayed action preserves every trusted fixed-release claim instead of collapsing the guidance to one incomplete upgrade.

Development and catalog-owned stable CVE Markdown emit no standalone page in the pure static build and are excluded from Eleventy and generic recipe/search feeds, tag pages, RSS, and the sitemap. The three pre-catalog historical stable recipes remain ordinary rendered content. Production can retain a legacy recipe URL as a redirect to the canonical CVE route through nginx and the MCP-backed landing service. Use the dedicated catalog or recipes_cve_* MCP tools for complete discovery.

The browser's exact-ID path and revision-pinned search API cover every in-scope Medium, High, and Critical record declared by the manifest. The MCP server exposes the same SQLite-backed coverage through recipes_cve_search; a successful recipes_cve_get returns the normalized source record, source identifiers and references, applicable archetypes, composed remediation contract, and a self-contained agentic_change_plan. The plan expands each mitigation and remediation instruction into ordered code/file operations with verification, rollback, evidence, approval, and triage requirements. It also preserves explicit CPE truncation metadata when the source match set exceeds the bounded record.

Daily CVE synchronization and optional AI enrichment

.github/workflows/cve-catalog-sync.yml runs every day at 09:23 UTC and can also be dispatched manually. It verifies and joins the NVD JSON 2.0 annual feeds and CISA KEV catalog, regenerates every catalog index/shard, validates the result, refreshes recipe-derived deterministic evidence in dependency order, runs the catalog tests, and opens or refreshes automation/cve-catalog-sync as a pull request to the default branch. Repository Settings > Actions > General > Workflow permissions must allow GitHub Actions to create pull requests for first-run PR publication.

Set CVE_AUTO_MERGE_ENABLED=true to deliver a safety-approved catalog PR after its exact head revision passes the dedicated validation workflow. When CVE_AUTOMATION_APP_CLIENT_ID and the CVE_AUTOMATION_APP_PRIVATE_KEY secret are configured, the workflow prefers that GitHub App identity so ordinary PR and main-branch Build runs fire naturally. Without App credentials, the workflow remains automatic: after the guarded GITHUB_TOKEN merge it verifies that the returned merge SHA is still current main, then dispatches the real build.yml workflow with that exact SHA. The production deploy gate recognizes only those CVE-qualified Build dispatches, so scheduled monitors and unrelated manual workflows cannot deadlock or satisfy a release.

The source sync does not require a secret. Leftover-gold review, content refresh, AI maintenance, AI issue maintenance, and this repository's security-health action also use Grok. Add one Actions secret named XAI_API_KEY (the official xAI environment variable; do not use GROK_API_KEY):

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

The workflow defaults to xAI's grok-4.6 Responses API model and at most 20 new or source-changed records per run. The scheduled queue is derived from the tracked NVD/CISA catalog: a candidate must have a valid tagged vendor advisory, patch, release-note, or mitigation URL. Source-complete records remain eligible because they still need a sourced remediation synthesis; within each KEV and severity band they rank ahead of records with deterministic source gaps, followed by affected-product/version evidence and recency. This uses the existing daily request budget and does not require an additional manual run. Both the model and limit can be changed with optional Actions variables; the enrichment limit is hard-bounded from 0 to 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

AI output is supplemental and explicitly labeled. It uses strict structured output, only cites URLs actually returned in the Responses API web-search provenance, and is stored reproducibly in data/cve/ai-enrichments.json. A complete enrichment becomes a CVE-specific Markdown draft only when a separate gate finds claim-level affected-product, exposure, remediation, and verification evidence tied to the exact URL of a tagged trusted advisory reference. Every required claim must independently meet that rule, and every generated recipe requires a cited, concrete fixed-version claim.