CAMEL-23496: docs - add a project-level security model document

[oscerd]

Summary

Adds a project-level security/threat-model document for Apache Camel, modelled on the equivalent
work in Apache Airflow (airflow/AGENTS.md#security-model,
security_model.rst).
It gives security reporters, committers reviewing PRs, deployment operators and automated triage
tooling an authoritative scope statement.

Jira: https://issues.apache.org/jira/browse/CAMEL-23496

What's in the document

• User roles and trust assumptions. Committers, route authors and deployment operators are
  trusted; external message senders (HTTP, JMS, file, SMTP, CoAP, Kafka, …) are the primary
  attacker model. The fundamental trust boundary sits between the route plus its configuration
  (trusted) and the data flowing through the route (untrusted).
• In-scope vulnerability classes with concrete CVE anchors so each rule has accepted
  precedent: unsafe deserialisation, XXE, expression/template injection, path traversal, SSRF
  via parser resolution, Camel-header / bean-dispatch abuse, auth bypass in AAA components,
  information disclosure, insecure defaults, injection into back-end queries built by Camel.
• Out-of-scope with rationale: route-author code (.bean, .process, simple/groovy on
  untrusted input is a route-author bug), explicit opt-ins like allowJavaSerializedObject=true
  or trustAllCertificates=true, DoS through unthrottled routes, exposure of
  camel-management / dev console / Jolokia / JMX on a public network, third-party transitive
  CVEs not reachable through Camel, and automated scanner reports with no PoC.
• Known limitations documenting heritage-permissive defaults, intentional bean-dispatch via
  internal headers, and aggregation-repository trust assumptions.
• Deployment hardening checklist (stay on the default prod profile, vaults, JSSE Utility,
  Camel-internal header stripping at the trust boundary, no Java serialisation on untrusted
  consumers, management surfaces off the public network, minimal dependency surface).
• Committer review checklist for security-sensitive PRs: case-insensitive
  HeaderFilterStrategy mandatory on consumers, ObjectInputFilter mandatory in persistent
  state, @UriParam(security = "...") for risky knobs, no default relaxations without an
  upgrade-guide entry.

Files changed

• docs/user-manual/modules/ROOT/pages/security-model.adoc (new) — canonical document.
• docs/user-manual/modules/ROOT/pages/security.adoc — adds a NOTE block at the top of the
  existing security feature catalog pointing to the new model.
• AGENTS.md — adds a top-level "Security Model" section between the rules of engagement and
  the structure overview, summarising the trust model and review checklists inline for agents
  reading the file.
• SECURITY.md — adds a pointer paragraph after the vulnerability-reporting line.

Why now

• Two CVE clusters keep recurring across new components because the project lacks a documented
  rule for what counts as a vulnerable default:
  • Header / bean-dispatch injection — CVE-2025-27636 / 29891 / 30177, then follow-ons in
    camel-coap (CVE-2026-33453), camel-mail (CVE-2026-33454), and camel-jms /
    camel-sjms / camel-google-pubsub (CVE-2026-40453).
  • Unsafe ObjectInputStream in aggregation repositories — CVE-2024-22369 (camel-sql)
    triggered CVE-2024-23114 (camel-cassandraql), CVE-2026-25747 (camel-leveldb),
    CVE-2026-27172 (camel-consul) and CVE-2026-40858 (camel-infinispan).
• Triage cost: every report describing a route author deliberately enabling
  allowJavaSerializedObject=true, trustAllCertificates=true, or Bean dispatch on
  attacker-controlled input requires re-explaining the trust boundary per-report.
• Anchor for automated scanning: external security tooling and AI-assisted vulnerability triage
  need an authoritative document to decide whether a finding is in scope.

Out of scope for this PR

• No code defaults are changed. Hardening individual components, adding HeaderFilterStrategy
  to a still-vulnerable consumer, or installing ObjectInputFilter on a specific aggregation
  repository remain individual CVE / improvement tickets.
• No CVSS-style severity rubric. The document covers whether something is in scope, not how
  severe it is.

Review path

• The Camel PMC should concur on scope before this is treated as authoritative. I'd appreciate
  review on both the trust assumptions and the in-scope / out-of-scope category definitions.
• Suggest also circulating on dev@camel.apache.org once the PR direction looks reasonable, so
  PMC members who aren't reviewing GitHub PRs get a chance to weigh in.

Changelog

• 9729b72 — apply @davsclaus's L301 suggestion ("framework" → "Camel framework") via GitHub
  UI commit-suggestion.
• fdd8594 — address @davsclaus's five remaining inline comments:
  • Stay on the default prod profile in production (it's the default; dev/test are the
    opt-in to development-only behaviour). Verified against
    MainConfigurationProperties.setProfile Javadoc.
  • Drop the obsolete org.apache.camel.* header prefix from the Java example and the
    committer checklist (Camel v1 leftover, no longer emitted by core consumers).
  • Spell out that DefaultHeaderFilterStrategy is case-insensitive out of the box (Camel,
    CAMEL, caMEL filtered identically) and that custom strategies must extend the default
    or implement the same behaviour.
  • Add a hardening bullet on minimal dependencies.
  • Strengthen the reporting section: no public disclosure on mailing lists, social media or
    any other channel; report through the ASF Security team.

Test plan

• AsciiDoc cross-references (xref:security.adoc, xref:camel-configuration-utilities.adoc)
  resolve to existing pages in the user manual.
• Markdown links in AGENTS.md and SECURITY.md use relative repo paths so they resolve
  both on GitHub and in local checkouts.
• No code defaults touched (documentation-only change).
• Factual claims verified against the codebase (MainConfigurationProperties default
  profile, DefaultHeaderFilterStrategy case-insensitivity, absence of org.apache.camel.*
  header emission in core consumers).
• PMC sign-off on scope.

---

Claude Code on behalf of Andrea Cosentino

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[squakez]

Great write up! Thanks for putting it together!

[github-actions]

🧪 CI tested the following changed modules:

• docs

---

⚙️ View full build and test results

[davsclaus]

Very good