docs: add core router-engine invariants to the security model

[oscerd]

What

1. Adds a Core router-engine invariants subsection to the project
   security model (docs/user-manual/modules/ROOT/pages/security-model.adoc),
   between the existing Security properties and violation severity impact
   table and In-scope vulnerability classes.
2. (added in review — see Review updates) Adds an Out of scope bullet
   scoping the non-default dev / test profile as development-only by
   design.

Why

The existing properties table is a cross-component impact view — every
row is framed at the point a component ingests untrusted input. It does
not separately state the invariants camel-core (the router engine)
upholds on its own. An automated security-triage pass against the model
flagged this as a soft gap in the "security properties provided" section:
findings located in a core/camel-* module (the largest, most-scanned
surface) could not be routed to a property and a disposition without
re-deriving the trust model, leading to systematic over-reporting on core.

This subsection adds the companion engine view — what the routing
engine, the Exchange/Message model, the EIP processors, the
expression / language / property-placeholder resolution, and the
type-converter and data-format registries guarantee independently of any
one component — with the same property → violation symptom → indicative severity shape as the existing table.

Scope

• Strict superset. No behavioural or scope change. Every invariant is
  the engine-layer projection of an in-scope vulnerability class, or of the
  trust boundary, already ratified in this document (expression/template
  injection; Camel-header / bean-dispatch abuse; unsafe deserialisation,
  incl. CVE-2015-0263; the CVE-2025-27636 header-promotion family; and the
  management-surface and DoS out-of-scope items, to which it explicitly
  defers).
• Documentation only; +74 lines across two commits, single file. Builds
  on the security-model work merged in docs: document API-component and semantic-header triage scope; add Security to user-manual nav #23253.
• No new xref:/includes/attributes; the table is cloned structurally from
  the existing one, so the camel-website strict Antora build is unaffected.

Review updates

• @davsclaus (review on PR docs: add core router-engine invariants to the security model #23282): asked whether it is documented that
  running under the dev profile (e.g. as Camel JBang does, or via
  camel.main.profile=dev) is development-only and that Camel may reveal
  details not at production scrutiny level. It was present only as a
  hardening responsibility (Deployment hardening + proposals/security.adoc
  profile-aware defaults), not as a triage rule. Resolved in commit
  9f32dc7ca8a by adding an explicit Out of scope bullet: a finding that
  only manifests under camel.main.profile = dev/test is out of scope as a
  non-default, development-only configuration; the production posture is the
  default prod profile. Cross-references Deployment hardening and
  proposals/security.adoc so the hardening note and the triage rule stay
  consistent. Maps to the OUT-OF-MODEL: non-default-build disposition.

Review note

This is a security-policy document — for PMC review. Per the project AI
rules of engagement this PR will not be merged or approved by an agent;
human approval is required.

Claude Code (Opus 4.7) on behalf of Andrea Cosentino

🤖 Generated with Claude Code

[davsclaus]

Did we write somewhere else about running Camel in development mode (profile=dev) such as what Camel JBang does, or if you explicit set it via

camel.main.profile=dev

Then that is for development purposes only, and as such Camel may reveal details and other informations that are relevant for developers and are not on the same level of scrutiny as production profile (default mode).

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• docs

---

⚙️ View full build and test results

[oscerd]

@davsclaus thanks — good catch, and you're right that it deserves to be explicit.

To answer the question directly: it was written, but only as a hardening responsibility, not as a triage rule:

• Deployment hardening already says: "Stay on the default prod profile in production… Setting camel.main.profile = dev or test is an explicit opt-in to development-only behaviour (extra services, dev console, debug endpoints) and should not be used in production."
• proposals/security.adoc documents the profile-aware policy defaults (prod → fail, dev → warn).

What was missing is exactly your point — that dev/test is development-only by design, Camel may deliberately reveal configuration/route/Exchange detail there at a lower scrutiny level than prod, and therefore a finding that only manifests under camel.main.profile = dev/test is out of scope. I've added that as an explicit bullet in Out of scope (commit 9f32dc7), cross-referencing Deployment hardening and proposals/security.adoc so the hardening note and the triage rule stay consistent. This maps to the OUT-OF-MODEL: non-default-build triage disposition the automated scan uses.

Re-requesting your review since the changeset changed after your approval.

Claude Code (Opus 4.7) on behalf of Andrea Cosentino