oscerd commented on code in PR #23503: URL: https://github.com/apache/camel/pull/23503#discussion_r3297254249
########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -510,6 +667,166 @@ they are, the change is announced through the normal upgrade-guide channel. defaults. A report against Camel must show the Camel framework, not the underlying client, is the cause. +=== Known non-findings + +Patterns that automated scanners, AI-assisted analysers and human +reviewers repeatedly report against Camel that are *not* framework +vulnerabilities under this model. Each entry names the recurring claim, +cites the section of this document that discharges it, and where +appropriate states the suppression shape. This list is the +highest-leverage input for an automated triage pass; it can be fed back +to a scanner verbatim as a negative prompt or suppression configuration. +Disposition is `KNOWN-NON-FINDING` (see _Triage dispositions_). + +* *"Component X depends on a JAR with CVE-Z, therefore Camel is + vulnerable."* Out of scope per the transitive-dependency entry in + _Out of scope_, unless the report demonstrates a Camel-exposed code Review Comment: Done in 9038203ef71. Dropped the "unless reachable" carveout in three places (the new §4.11a *Known non-findings* bullet, the new §4.9 *Security properties not provided* bullet, and the existing transitive-dep bullet, so the rule is consistent everywhere it appears). The wording is now: "Camel fixes CVEs in Camel code, not in third-party JARs; the report belongs upstream. Camel may upgrade the dependency to pick up an upstream fix, but the CVE itself is closed against the upstream project." _Claude Code (Opus 4.7) on behalf of Andrea Cosentino_ ########## docs/user-manual/modules/ROOT/pages/security-model.adoc: ########## @@ -510,6 +667,166 @@ they are, the change is announced through the normal upgrade-guide channel. defaults. A report against Camel must show the Camel framework, not the underlying client, is the cause. +=== Known non-findings + +Patterns that automated scanners, AI-assisted analysers and human +reviewers repeatedly report against Camel that are *not* framework +vulnerabilities under this model. Each entry names the recurring claim, +cites the section of this document that discharges it, and where +appropriate states the suppression shape. This list is the +highest-leverage input for an automated triage pass; it can be fed back +to a scanner verbatim as a negative prompt or suppression configuration. +Disposition is `KNOWN-NON-FINDING` (see _Triage dispositions_). + +* *"Component X depends on a JAR with CVE-Z, therefore Camel is + vulnerable."* Out of scope per the transitive-dependency entry in + _Out of scope_, unless the report demonstrates a Camel-exposed code + path that reaches the vulnerable code. Default disposition is to + forward upstream. +* *"`simple(...)`, `xpath(...)`, `groovy(...)`, `jexl(...)` or + `mvel(...)` evaluates an untrusted expression."* The expression text + is route-author code, not untrusted input. The framework is in scope + only when *it* passes an `Exchange` body, header or property to an + evaluator without the route author placing an expression there - the + first invariant under _Core router-engine invariants_. Otherwise this + is the route-author entry in _Out of scope_. +* *"`.bean(...)`, `.process(...)`, `Runtime.exec(...)` or a `Class` + reference allows RCE."* These are route-author primitives by design. + Route code is trusted code; see the route-author entry in _Out of + scope_ and the route-author row in _Roles_. +* *"A `Camel*` / `org.apache.camel.*` header controls dispatch, therefore + the consumer is vulnerable."* Bean-based dispatch via internal headers + is the public contract for letting a route control component behaviour; + see the second bullet under _Known limitations_. A finding is in scope + only when a *consumer* promotes an untrusted-origin value into that + namespace without an effective `HeaderFilterStrategy` - the + Camel-header / bean-dispatch class under _In-scope vulnerability + classes_. +* *"Application-level header X (`To`, `Subject`, HTTP `X-...`, JMS + property, AMQP / MQTT / CoAP / Kafka header) is not stripped, therefore + the consumer is vulnerable."* Application-level headers are part of + each component's documented header contract and are intentionally + passed through; the framework filters only the internal `Camel*` + namespace. See the third bullet under _Known limitations_ and the + application-headers point under _Security properties not provided_. + The route author sanitises at the trust boundary. +* *"`DefaultHeaderFilterStrategy` can be bypassed by changing the case + (`caMEL`, `CAMEL`)."* The default strategy is case-insensitive out of + the box (`Camel`, `CAMEL` and `caMEL` are filtered identically); see + the third bullet under _Known limitations_. A finding here would have + to demonstrate a *custom* strategy that does not extend + `DefaultHeaderFilterStrategy` and re-implements the matching without + case-insensitivity - and the fix lives in that custom strategy. +* *"The developer console, the backlog debugger, JMX, Jolokia or Review Comment: Done in 9038203ef71. Added `Tracer` and `BacklogTracer` to the developer-console bullet so it now reads: "The developer console, the backlog debugger, the `Tracer` / `BacklogTracer`, JMX, Jolokia or `camel-management` exposes operations...". Consistent with the error-handling row in `=== Core router-engine invariants` which already names `BacklogTracer` as part of the management-connection out-of-scope set. _Claude Code (Opus 4.7) 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]
