davsclaus commented on code in PR #23503: URL: https://github.com/apache/camel/pull/23503#discussion_r3297203218
########## 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: add backlog tracer and tracer as well ########## 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: Why unless a camel code path that reches the vulnarable code? We only fix CVEs in camel code, not in any 3rd party JARs what-so-ever. -- 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]
