oscerd opened a new pull request, #23503:
URL: https://github.com/apache/camel/pull/23503
## What
Adds four subsections to
`docs/user-manual/modules/ROOT/pages/security-model.adoc` that close the *soft
gaps* called out in an external review of the model against the threat-model
rubric used by an automated security-triage pass (`threat-model-producer`
SKILL, §4.7 / §4.9 / §4.11a / §4.13). Each addition lifts content the document
already covers implicitly into the rubric-shaped header an automated scanner
expects.
| New subsection | Inserted under | Rubric § | Re-projects |
| --- | --- | --- | --- |
| `=== Adversary model` | `== Trust model` (after `=== Trust boundaries`) |
§4.7 | `=== Roles` (External message senders), `=== Trust boundaries`, the
route-author / operator / management-surface / third-party-dep entries in `===
Out of scope` |
| `=== Security properties not provided` (+ `==== False-friend properties`)
| `== Vulnerability scope` (after `=== Core router-engine invariants`) | §4.9 |
`=== Out of scope` (DoS, transitive dep, profile, explicit-opt-in), `=== Known
limitations` (header-filter scope, deprecation), the route-author row in `===
Roles` |
| `=== Known non-findings` | `== Vulnerability scope` (after `=== Known
limitations`) | §4.11a | each entry cites the existing in-scope class,
out-of-scope item or known-limitations bullet that discharges it (12 entries) |
| `=== Triage dispositions` | `== Vulnerability scope` (before `==
Deployment hardening`) | §4.13 | closed-set vocab table (`VALID`,
`VALID-HARDENING`, `OUT-OF-MODEL: {trusted-input, adversary-not-in-scope,
unsupported-component, non-default-build}`, `BY-DESIGN: property-disclaimed`,
`KNOWN-NON-FINDING`, `MODEL-GAP`), each row citing the licensing section in
this document |
## Why
The model is consumed by automated triage tooling. A reviewer running the
rubric against the document on 2026-05-24 marked it `PASS-with-soft-gaps`:
substantive Trust model / Vulnerability scope / In-scope catalogue / Out of
scope / Deployment hardening, but missing the rubric-shaped headers for
adversary model, disclaimed properties, known non-findings and triage
dispositions. The implicit content was acknowledged as substantive; the missing
headers were judged to risk over-reporting against scanner output that expects
those exact section names.
The adversary model and disclaimed-properties additions are mostly cosmetic
re-shaping of content already in the document; the known-non-findings and
triage-dispositions additions are additive and high-leverage:
* `=== Known non-findings` doubles as a scanner-suppression list. It can be
fed verbatim back to an AI-assisted reviewer as a negative prompt to stop the
recurring false positives this project has historically received against it
(transitive-dep CVEs without a reachable path, `simple` / `.bean()` /
`Runtime.exec()` reported as RCE, `Camel*` header dispatch reported as a
vulnerability, application-level headers like `To` / `Subject` not stripped,
`caMEL` case-bypass claims, MBean operations on the management surface,
dev/test profile, non-cryptographic hash uses, deprecated components,
documented opt-ins, and findings located in `core/camel-*`).
* `=== Triage dispositions` formalises the closed-set vocab the PMC and
reviewers have been using informally. PR #23282 already used `OUT-OF-MODEL:
non-default-build` ad-hoc in a review reply; this PR turns the vocab into a
referenced table.
## Scope
**Strict superset. No new security commitments.** Every claim in the four
new subsections is a re-projection of an already-ratified in-scope class,
out-of-scope item, known limitation, trust-boundary statement or core
router-engine invariant. The PR consciously avoids:
- Introducing any new property the framework would commit to upholding.
- Narrowing or weakening any existing property.
- Adding any new vulnerability class to in-scope.
- Reclassifying any existing in-scope item as out-of-scope (or vice versa).
The only place where this PR states something the existing document does not
phrase explicitly is the constant-time-comparison disclaimer in `=== Security
properties not provided` — a clarification of *absence* (Camel has never
claimed constant-time comparison) rather than a new commitment, and the
rubric's canonical example for that section.
**Documentation only**. Single file. +317 lines, no deletions. No new
`xref:`, `include::` or attribute references; uses the document's existing
italic section-reference pattern (`_Section name_`) for cross-links so the
camel-website strict Antora build is unaffected.
## Section structure after this change
```
== Audience
== Trust model
=== Roles
=== Trust boundaries
=== Adversary model [NEW §4.7]
== Vulnerability scope
=== Security properties and violation severity
=== Core router-engine invariants
=== Security properties not provided [NEW §4.9]
==== False-friend properties [NEW under §4.9]
=== In-scope vulnerability classes
==== ... (10 existing classes)
=== Out of scope
=== Deprecated and removed components
=== Known limitations
=== Known non-findings [NEW §4.11a]
=== Triage dispositions [NEW §4.13]
== Deployment hardening
== Guidance for component authors and reviewers
== Reporting a vulnerability
== Related documents
```
## Builds on
* #23181 — initial doc
* #23229 — severity tiers + scope rules
* #23253 — API-component / semantic-header triage scope + nav
* #23282 — core router-engine invariants (the §4.8 deepening commitment)
## Review note
This is a security-policy document — for **PMC review**. Per the project AI
rules of engagement (`CLAUDE.md`, *Merge Requirements*) this PR will **not** be
merged or approved by an agent; human approval is required, and the branch will
be deleted from the fork after merge or rejection.
The strict-superset constraint above is the single most important review
property to check: any entry that introduces a *new* security commitment
(rather than restating an existing one in rubric shape) should be flagged and
either reworded or removed.
_Claude Code (Opus 4.7) on behalf of Andrea Cosentino_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
