Andrea Cosentino created CAMEL-23979:
----------------------------------------
Summary: 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
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)
