This is an automated email from the ASF dual-hosted git repository.
oscerd pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 5bbb510497b1 docs: expand security model with severity tiers and scope
rules (#23229)
5bbb510497b1 is described below
commit 5bbb510497b15e14f7718e30f08e9f02c38dcba9
Author: Andrea Cosentino <[email protected]>
AuthorDate: Fri May 15 11:35:27 2026 +0200
docs: expand security model with severity tiers and scope rules (#23229)
* docs: clarify management-surface scope in security model
Expand the "management surface" out-of-scope bullet in
security-model.adoc to name the MBean operations the bullet covers
(ManagedCamelContext.sendBody / requestBody,
ManagedBacklogDebugger.evaluateExpressionAtBreakpoint and
addConditionalBreakpoint, BacklogTracer.setTraceFilter) and to state
explicitly that the trust boundary is the JMX / Jolokia / management
HTTP surface itself - JVM JMX authentication, the Jolokia restrictor
policy and the network exposure of the management port - rather than
any individual MBean method.
These operations are intentionally as expressive as a route author's
DSL so that operator workflows (Camel JBang, Hawtio, JConsole,
monitoring agents) keep working. The clarification helps future readers
of the security model identify which side of the trust boundary the
management API sits on without having to derive the reasoning from the
trust-model section.
_Claude Code (Opus 4.7) on behalf of Andrea Cosentino_
Signed-off-by: Andrea Cosentino <[email protected]>
* docs: add severity tiers and lifecycle scope to security model
Add a "Security properties and violation severity" subsection mapping each
protective property to its violation symptom and an indicative severity
tier (an impact view complementing the mechanism-oriented in-scope classes),
and a "Deprecated and removed components" subsection placing deprecated
components in limited scope and removed ones out of scope.
Bridge AGENTS.md to SECURITY.md so the vulnerability-reporting convention is
complete and agents are instructed not to disclose suspected issues
publicly.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
---------
Signed-off-by: Andrea Cosentino <[email protected]>
Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
---
AGENTS.md | 6 ++
.../modules/ROOT/pages/security-model.adoc | 101 ++++++++++++++++++++-
2 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/AGENTS.md b/AGENTS.md
index 680757689250..6810f77e3674 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -177,6 +177,12 @@ document is
[`docs/user-manual/modules/ROOT/pages/security-model.adoc`](docs/use
Use it as the reference when triaging security reports, deciding whether a
finding warrants a
CVE, or reviewing a security-sensitive PR.
+For the vulnerability **reporting** convention, [`SECURITY.md`](SECURITY.md)
at the repository
+root is the entry point GitHub and security tooling expect. It points to the
threat model above
+for scope and to the ASF process for private disclosure. An agent that
discovers or is handed a
+suspected vulnerability MUST NOT open a public issue, PR, or mailing-list post
about it — follow
+the private process in `SECURITY.md` and stop.
+
### Trust assumptions
- **Camel committers and component authors** are trusted to ship secure
defaults.
diff --git a/docs/user-manual/modules/ROOT/pages/security-model.adoc
b/docs/user-manual/modules/ROOT/pages/security-model.adoc
index 8a6abeaf1d66..bd26f25008ed 100644
--- a/docs/user-manual/modules/ROOT/pages/security-model.adoc
+++ b/docs/user-manual/modules/ROOT/pages/security-model.adoc
@@ -93,6 +93,66 @@ A report is in scope when it demonstrates that the
framework, in a default or
reasonably-expected configuration, lets untrusted input cross a trust boundary
that the model says it should not cross.
+=== Security properties and violation severity
+
+The trust-boundary statement above commits the framework to a small set of
+concrete properties. Each one maps to a specific impact an attacker achieves
+if the framework fails to uphold it, and to an indicative severity tier. The
+classes in _In-scope vulnerability classes_ below are the *mechanisms* by which
+these properties are broken; the table here is the *impact* view that triage
+tooling and reporters can use to gauge how serious a candidate finding is and
+which protective property it breaks.
+
+[cols="3,3,1",options="header"]
+|===
+| Property the framework upholds for untrusted input (default or
reasonably-expected configuration)
+| What a violation looks like (symptom a reporter or scanner observes)
+| Indicative severity
+
+| Untrusted data is never turned into executed code or OS commands
+| A crafted message, header or attachment causes a deserialisation gadget
chain, a bean / method / command dispatch, or an expression/template evaluation
the route author never requested
+| Critical (CVSS 9.0-10.0)
+
+| Untrusted data cannot redirect the route to a different endpoint, bean,
method or command
+| An internal header injected from the wire (`CamelBeanMethodName`,
`CamelExecCommandExecutable`, `CamelHttpUri`, `CamelJmsDestinationName`, ...)
changes where the exchange is dispatched
+| Critical (CVSS 9.0-9.8)
+
+| Untrusted data is never deserialised into arbitrary Java types
+| A consumer, type converter or persisted-state repository instantiates
attacker-chosen classes through `ObjectInputStream` / XStream / Hessian /
polymorphic Jackson without an effective filter
+| Critical when gadget-reachable (9.0-9.8); High otherwise (7.0-8.6)
+
+| Untrusted parsing does not resolve external or remote resources
+| An XML / XSLT / XSD / XPath parse of attacker input reads a local file,
performs SSRF, or fetches a remote DTD or stylesheet by default
+| High (CVSS 7.5-8.6); Critical if it yields RCE or credential theft
+
+| Untrusted file names or URI components cannot escape the configured root
+| A file / mail / FTP consumer or producer reads or writes a path outside the
configured directory via `../` or an absolute path supplied in a header
+| High (CVSS 7.5-8.8)
+
+| Components that advertise authentication or authorization actually enforce it
+| A request is served without a valid token, with an unvalidated issuer /
audience / signature, or on a sub-path the auth handler was assumed to cover
+| Critical (CVSS 9.0-9.8)
+
+| Secrets and internal Exchange state are not disclosed
+| Credentials, message bodies or configuration values reach a log, an event, a
world-readable file, or an HTTP response visible to a lower-privileged party
+| Medium to High (CVSS 5.3-8.2), depending on what leaks
+
+| Untrusted input is not spliced into a back-end query language Camel builds
+| Camel constructs a Cypher / XSLT-extension / similar query and the attacker
alters its structure rather than only its data
+| High to Critical (CVSS 8.1-9.8)
+
+| All of the above hold with zero security configuration
+| Any of the above is reachable simply by adding the component to a route and
sending a message, with no risky option explicitly set
+| Severity of the underlying class; always in scope
+|===
+
+The tiers above are *indicative*, reflecting how the Camel PMC has historically
+scored these classes. The PMC assigns the definitive CVSS vector per report
+based on attack vector, the configuration required to reach the code path, and
+the concrete impact demonstrated. A finding that needs an unusual non-default
+configuration, or whose impact is limited, may score lower than the tier
+suggests; one that chains into full host compromise may score higher.
+
=== In-scope vulnerability classes
The classes below are grounded in advisories the Apache Camel PMC has accepted
@@ -263,7 +323,19 @@ be closed as `not a vulnerability`.
parser in a way that bypasses the library's own limits.
* *A deployer placing `camel-management`, the developer console,
`camel-jolokia`, JMX or another management surface on a public network.*
- These are management surfaces; they assume a trusted network.
+ These are management surfaces; they assume a trusted network. The
+ operations they expose - including `ManagedCamelContext.sendBody` /
+ `requestBody`, `ManagedBacklogDebugger.evaluateExpressionAtBreakpoint`,
+ `addConditionalBreakpoint` and `BacklogTracer.setTraceFilter` - are
+ intentionally as expressive as a route author's DSL, because they exist
+ to support operator workflows (Camel JBang, Hawtio, JConsole, monitoring
+ agents). The trust boundary is the management surface itself - JVM JMX
+ authentication (`-Dcom.sun.management.jmxremote.authenticate`), the
+ Jolokia restrictor policy, and the network exposure of the management
+ port - not the individual MBean method. A report that demonstrates
+ "MBean operation X executes code or sends to endpoint Y when invoked
+ from a JMX or Jolokia connection" describes the documented contract,
+ not a framework vulnerability.
* *Vulnerabilities in third-party transitive dependencies that are not
reachable through any Camel-exposed code path.* See
https://github.com/apache/camel/blob/main/SECURITY.md[`SECURITY.md`] and the
@@ -274,6 +346,33 @@ be closed as `not a vulnerability`.
CVEs" is not, by itself, a finding. The report must show that the code path
is reachable from an untrusted source and that the trust boundary is crossed.
+=== Deprecated and removed components
+
+A component's position in its lifecycle changes how a report against it is
+handled. Whether a component is deprecated is mechanically verifiable: it
+carries the `(deprecated)` suffix in its `pom.xml` name and documentation
+title, an `@Deprecated` annotation, a `deprecated` flag in the Camel catalog,
+and an upgrade-guide entry pointing at the replacement or migration.
+
+* *Deprecated components are in limited scope.* A deprecated component is on a
+ removal path and has a documented replacement or migration. A report against
+ one is still triaged on the private security list, but the *primary
+ remediation is the documented migration*, not necessarily a code change in
+ the deprecated component. Depending on the severity and on how widely the
+ component is still used, the PMC may fix in place, publish an advisory whose
+ remediation is "migrate to the supported replacement", or accelerate removal.
+ Hardening and defence-in-depth work goes to the supported replacement, not
+ the deprecated component.
+* *Removed components are out of scope.* A component that no longer ships in
any
+ supported release cannot receive a fix. A finding must be demonstrated
+ against a component present in a supported release; if the only affected code
+ is one that has been removed, the resolution is to upgrade to a release where
+ it is gone or replaced.
+* This lifecycle rule does not change the in-scope classes for a
+ *non-deprecated* component that merely depends on a deprecated or end-of-life
+ *third-party* library - that case is governed by the third-party-dependency
+ item under _Out of scope_ above.
+
=== Known limitations
These are framework characteristics that look like vulnerabilities at first
