[
https://issues.apache.org/jira/browse/CAMEL-23979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095212#comment-18095212
]
Andrea Cosentino commented on CAMEL-23979:
------------------------------------------
Good idea, adopted that approach (dropped the initial runtime-fetch design):
* New camel-package-maven-plugin goal {{update-security-advisories}} mirroring
{{update-camel-releases}}: it scans the content/security/CVE-*.md front matter
in camel-website and writes {{camel-security-advisories.json}} into
camel-catalog src/generated. Run via {{-Pupdate-security-advisories}} in
catalog/camel-catalog; currently syncs 76 published advisories (drafts and
non-advisory pages are skipped).
* New {{CamelCatalog.camelSecurityAdvisories()}} API returning the new
{{SecurityAdvisoryModel}} (cve, date, severity, summary, affected, fixed,
mitigation, url, components extracted from the advisory text).
* camel-jbang-mcp consumes the catalog fully offline: a
{{camel_security_advisories}} tool (filter by Camel version / component /
severity, with best-effort parsing of the affected version ranges),
{{camel://security/advisories}} MCP resources, and
{{camel_route_harden_context}} now also embeds the known CVEs affecting the
components used by the route at the given Camel version.
Regarding the TUI CVE audit tab: that uses OSV.dev for dependency-level CVEs,
which stays complementary to the ASF advisories data. A possible follow-up is
to move OsvClient to a shared place and offer a dependency CVE audit tool in
the MCP server too.
PR coming shortly.
_Claude Code on behalf of oscerd_
> 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)
