oscerd opened a new pull request, #23181: URL: https://github.com/apache/camel/pull/23181
## 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](https://github.com/apache/airflow/blob/main/AGENTS.md#security-model), [security_model.rst](https://github.com/apache/airflow/blob/main/airflow-core/docs/security/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** (security policy framework, vaults, JSSE Utility, Camel-internal header stripping at the trust boundary, no Java serialisation on untrusted consumers, management surfaces off the public network). - **Committer review checklist** for security-sensitive PRs: `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 [email protected] once the PR direction looks reasonable, so PMC members who aren't reviewing GitHub PRs get a chance to weigh in. ## Test plan - [x] AsciiDoc cross-references (`xref:security.adoc`, `xref:camel-configuration-utilities.adoc`) resolve to existing pages in the user manual. - [x] Markdown links in `AGENTS.md` and `SECURITY.md` use relative repo paths so they resolve both on GitHub and in local checkouts. - [x] No code defaults touched (documentation-only change). - [ ] PMC sign-off on scope. --- _Claude Code on behalf of Andrea Cosentino_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
