[
https://issues.apache.org/jira/browse/CAMEL-24295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18117996#comment-18117996
]
Andrea Cosentino commented on CAMEL-24295:
------------------------------------------
Investigation findings before implementing this — the premise needs revisiting.
h3. 1. The production profile cannot surface {{nested}}
{{BaseMainSupport.enforceSecurityPolicies}} builds its candidate map
exclusively from {{autoConfiguredProperties}}, so only {{camel.*}}
configuration properties are ever tested against the policy. {{nested}} is a
route-inline model attribute on {{SimpleExpression}} (an {{@XmlAttribute}} set
in the DSL), not a {{camel.*}} property. Adding {{security="insecure:dev"}}
therefore would *not* make {{camel.main.profile=prod}} report anything — the
value never reaches the detector. The mechanism named in the description does
not apply to this option.
h3. 2. The other consumer would false-positive
The remaining consumer of the marker is camel-jbang's
{{SecurityScanTools.scanInsecureOptions}}, which is purely textual: it
lowercases each route source line, strips whitespace and dashes, then for every
key in {{SecurityUtils.SECURITY_OPTIONS}} calls {{extractOptionValue}} — which
does an *unanchored* {{normalized.indexOf(optionKey)}} with no token-boundary
check.
All 39 current keys are distinctive compounds ({{allowqueryfromheader}},
{{trustallcertificates}}, {{devconsoleenabled}}, ...). {{nested}} would be by
far the most generic, and because the match is unanchored it fires wherever an
identifier *ending* in "nested" is followed by {{:}} or {{=}} —
{{isNested=true}}, {{unnested: true}}, or any unrelated YAML/JSON field named
{{...nested}} in the scanned source. The map is keyed by bare option name with
no component or language scoping, so the rule is global.
h3. Recommendation
Hold this until the scanner is context-aware (anchor matches on a token
boundary, or scope option keys by component/language). Marking {{nested}} today
buys no prod-profile coverage and adds a noisy scanner rule.
Worth adding that {{nested}} is also genuinely lower risk than the
header-driven options already in the map: it re-evaluates a result the route
itself produced, and route authors are fully trusted under the documented
threat model. An untrusted-input path exists only if the route feeds message
content into Simple, which the security model already places outside the
framework's trust boundary.
The change itself is trivial (a one-line {{@Metadata}} edit plus catalog
regeneration), so happy to implement it anyway if you would rather have the
marker in place ahead of the scanner work — or to fix the anchoring in
{{extractOptionValue}} first and then add it.
_Claude Code on behalf of Andrea Cosentino_
> camel-core: mark the Simple nested option with security metadata
> ----------------------------------------------------------------
>
> Key: CAMEL-24295
> URL: https://issues.apache.org/jira/browse/CAMEL-24295
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Minor
>
> The Simple language nested option (SimpleExpression, default false)
> re-evaluates a nested Simple expression contained in the result. It is off by
> default. Unlike other opt-in options with security relevance it carries no
> security metadata marker, so the production-profile policy has no visibility
> of it. Suggested: add security="insecure:dev" (and a security label) on the
> nested @Metadata so camel.main.profile=prod can surface routes that enable
> it. Metadata-only change (regenerates catalog).
> _Filed by Claude Code on behalf of Andrea Cosentino._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
