Trust page: highlight Camel's secure-out-of-the-box runtime enforcement

[davsclaus]

Apache Camel doesn't just fix CVEs reactively — it actively prevents insecure configurations from reaching production. This story is not told anywhere on the website today and deserves a section on the trust page.

What Camel provides:

1. Security-annotated catalog metadata — every component option in the Camel catalog is tagged with whether it is security-related, and whether enabling it would be insecure. This metadata is machine-readable and available to tooling and the runtime.

2. Startup security validation — Camel inspects the configuration at startup and reports any options flagged as insecure, giving developers immediate feedback before a single message is processed.

3. Production mode enforcement — in production mode, Camel can refuse to start entirely if insecure options are configured. This is a hard guardrail, not a warning you can ignore.

4. Secure defaults — components default to secure settings (e.g., TLS enabled, authentication required) so the safe path is the easy path.

Most integration frameworks leave security configuration entirely to the user. Camel bakes it into the framework itself — the catalog knows which options are dangerous, the runtime enforces safe defaults, and production mode makes insecure configurations a startup failure, not a runtime surprise.

Suggested changes:

• Add a new section to the trust page (/trust/) — something like "Secure out of the box" — after the security advisories section.
• Consider also mentioning this in the security model documentation and on the main security page.
• Audit remaining gaps: most components follow this pattern but a few may still have options that should be annotated or defaults that should be tightened.

Related: #1678 (SBOM on trust page), #1679 (SBOM blog post)

[davsclaus]

Partial progress — addressed the documentation side:

apache/camel (main):

• Created new docs/user-manual/modules/ROOT/pages/security-policy.adoc — user-facing documentation for the security policy enforcement framework (camel.security.* properties). Covers the four categories (secret, insecure:ssl, insecure:serialization, insecure:dev), the three policy levels (allow/warn/fail), profile-aware defaults, safe secret patterns, and example configurations for production, development, and custom setups.
• Added nav entry under "Security" → "Security Policy Enforcement"
• Added cross-reference from security.adoc pointing to the new page

The trust page section and remaining items (audit of unannotated component options) are still open.

[davsclaus]

Note: the security-annotated catalog metadata (item 1 in this ticket) is also exposed through the Camel MCP server — AI coding assistants using the MCP harness tool can query which component options are security-sensitive and what their safe defaults are. This is another angle worth mentioning on the trust page: not only does the runtime enforce secure defaults, but the same metadata is available to AI tooling so insecure configurations can be caught at development time too.