docs: expand security model with severity tiers and scope rules#23229
Merged
oscerd merged 2 commits intoMay 15, 2026
Conversation
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 <ancosen@gmail.com>
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
davsclaus
approved these changes
May 14, 2026
Croway
approved these changes
May 14, 2026
Contributor
|
yes ManagedBacklogDebugger is a development feature that is not enabled for production. End users can however choose to turn it on or in standby mode, but then that is on purpose. |
Contributor
|
🧪 CI tested the following changed modules:
|
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) <noreply@anthropic.com>
Croway
approved these changes
May 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Documentation-only improvements to the Camel security model, driven by a
security-model review. No code, no API, no behaviour change.
1. Management-surface scope clarification (
security-model.adoc)tell which side of the trust boundary the JMX / Jolokia management API sits
on. Names the MBean operations the bullet covers (
ManagedCamelContext.sendBody/
requestBody,ManagedBacklogDebugger.evaluateExpressionAtBreakpoint,addConditionalBreakpoint,BacklogTracer.setTraceFilter) and restates thatthe trust boundary is the JMX / Jolokia / management-HTTP surface itself
(JVM JMX auth, the Jolokia restrictor policy, network exposure of the
management port) — not the individual MBean method.
2. Security properties and violation severity (
security-model.adoc, new subsection)"In-scope vulnerability classes": a table mapping each protective property the
trust boundary commits to → the violation symptom a reporter/scanner observes
→ an indicative CVSS severity tier. Directly serves the "automated triage
tooling" audience the document already names. Tiers are explicitly marked
indicative; the PMC retains definitive per-report CVSS scoring.
3. Deprecated and removed components scope (
security-model.adoc, new subsection)privately, but the primary remediation is the documented migration; hardening
and defence-in-depth go to the supported replacement). Removed components
are out of scope. Deprecation is defined by mechanically-verifiable markers
(
(deprecated)pom/title suffix,@Deprecated, catalogdeprecatedflag,upgrade-guide entry). Carve-out: a non-deprecated component that merely
depends on a deprecated third-party library stays under the existing
third-party-dependency item.
4. AGENTS.md → SECURITY.md bridge (
AGENTS.md)## Security Modelsection now points toSECURITY.mdas the report-intake entry point (scope → threat model,disclosure → ASF process) and instructs agents not to disclose suspected
vulnerabilities publicly.
Reviewer note
The first commit (management-surface clarification) was approved by @davsclaus
and @Croway. The follow-up commit materially expands the changeset
(items 2–4 above), and those approvals predate it — re-requesting review so the
broader scope is consciously re-examined. The severity bands in item 2 and the
"deprecated → limited scope / primary remediation is migration" policy in
item 3 are PMC judgement calls and the parts that most warrant scrutiny.
Happy to split items 2–4 into a separate PR if preferred.
Test plan
severity table render without breaking list/table structure.
xref:or AsciiDoc cross-references are introduced.AGENTS.mdstill renders as valid Markdown.Claude Code (Opus 4.7) on behalf of Andrea Cosentino