[
https://issues.apache.org/jira/browse/CAMEL-23979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-23979 started by 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)
