[jira] [Assigned] (CAMEL-23979) camel-jbang-mcp: expose CVE security advisories as MCP tool and resources

["Andrea Cosentino (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-23979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrea Cosentino reassigned CAMEL-23979:
----------------------------------------

    Assignee: Andrea Cosentino

> camel-jbang-mcp: expose CVE security advisories as MCP tool and resources
> -------------------------------------------------------------------------
>
>                 Key: CAMEL-23979
>                 URL: https://issues.apache.org/jira/browse/CAMEL-23979
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jbang
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>
> The camel-jbang-mcp MCP server already exposes a security surface: the camel_harden tool, the SecurityData registry of security-sensitive components, and the camel://security/* resources. However it has no knowledge of the published Camel CVE security advisories (https://camel.apache.org/security/), so an AI agent using the server cannot answer questions like "is my Camel 4.10.1 project affected by known CVEs?" or flag that a route using platform-http plus bean on Camel 4.10.1 is exposed to CVE-2025-27636.
> The advisories behind that page are maintained in the apache/camel-website repository under content/security/CVE-*.md with structured YAML front matter (cve, severity, summary, description, mitigation, credit, affected, fixed, date), so the data is machine-consumable without HTML scraping.
> h3. Proposal
> # New MCP tool {{camel_security_advisories}}: optional args camelVersion, component, severity; returns matching published advisories (cve, severity, summary, affected, fixed, mitigation, link). Declared with openWorldHint=true since it fetches remote data.
> # New MCP resources {{camel://security/advisories}} (list) and {{camel://security/advisory/\{cve\}}} (detail), following the existing SecurityResources pattern.
> # Integrate advisory matching into the camel_harden tool context: when route analysis identifies components and a camelVersion is provided, include known CVEs affecting those components at that version.
> h3. Design notes
> * Advisory data is fetched at runtime (with a local cache under the user home, e.g. ~/.camel-jbang) rather than embedded at build time, because embedded snapshots go stale: a server released before a CVE is published would never know about it. Runtime downloads are already part of the server's operating model (CatalogService resolves version-specific catalogs via Maven).
> * Offline behavior must be explicit ("advisory data unavailable"), never a silently stale "no CVEs found".
> * Only published advisories from the public website/repository are used.
> * The {{affected}} field is prose (e.g. "Apache Camel 4.10.0 before 4.10.2 ..."); recent advisories follow a consistent pattern so a best-effort affectsGivenVersion flag can be computed, with the prose always returned verbatim for the LLM to reason over.
> * Component filtering starts as best-effort token matching (camel-<name>) against summary/description; a structured components front-matter field could be added to new advisories in camel-website as a follow-up.
> * Initial data source: the camel-website repository raw content (tree listing plus cached per-advisory fetches). As a follow-up, camel-website could publish a machine-readable JSON feed (e.g. /security/index.json via a Hugo output format) and become the canonical endpoint for this and other tooling.
> * Tests use canned advisory fixtures so CI requires no network.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)