ci(codeql): extract the render backends, not the engine alone

[DemchaAV]

Why

The Java extractor sees whatever the build compiles, so the -pl list in the scanning workflow is the analysis scope. It named one module. The render backends, the templates and the testing harness were not partially analysed — they were absent from the scan, and nothing in a green result says which code was looked at.

That is where the untrusted input lands: PDFBox and POI parsing, the SVG and image paths, font loading, the ZIP/OPC writers. The engine module, which was scanned, handles the least of it.

The workflow's own comment admitted the gap and deferred it. The reason for deferring was a standing pile of untriaged alerts; measured now, that pile is 53 open — 50 note, 3 warning, 0 error, and zero carrying any security severity. It is a style backlog, not a triage burden that should hold back scanning the parsers.

Honest expectation, since the point is coverage rather than a haul: the unscanned modules contain no deserialization, no Class.forName, no Runtime.exec and no XML parsers; the ZIP work is ByteArrayInputStream → ByteArrayOutputStream with no extract-to-disk. Few or no new high-severity findings are likely. The gain is that the binary-parsing and file-writing boundary stops being invisible.

What

Every deployed module that carries code is named outright — core, render-pdf, render-docx, render-pptx, templates, testing, fonts, emoji. Naming fonts and emoji rather than letting them arrive through -am matters: reaching the extractor as somebody's dependency ends the day that dependency is dropped, and nothing would have said so.

CodeQlScopeGuardTest holds the list against two inventories that fail differently:

• against ci.yml's verify gate — catches the scan falling behind the build;
• against the publish workflows' deploy steps — catches what the first cannot. A module added to the publish train and forgotten in both CI and the scan is missing from both sides of the first comparison, which leaves the two lists in perfect agreement.

The guard reads a module's coordinates from its own pom with the inherited <parent> block removed, collects -pl selectors token by token so a wrapped command cannot silently shrink the expectation, and treats a command with no -pl as the whole reactor rather than throwing — a guard that failed on the stricter setup would push toward the looser one.

Tests

The exact command the workflow runs, executed locally: BUILD SUCCESS, eight modules.

Extraction is confirmed rather than assumed: on this branch the CodeQL tracer compiles 632 main + 170 test sources across eight modules, against 404 + 83 on develop. Build 57s → 130s, analysis 58s → 71s; the job is 3m53s against a 30-minute timeout.

Guard job as CI invokes it: 37 tests, BUILD SUCCESS.

Negative check	Result
drop render-pptx from the scan list	fails, names the module
drop a deployed module (fonts) from the scan list	fails, names the module
add a module to the publish train only	fails, names the module
add a code-bearing module to the verify gate only	fails, names the module
drop -am	passes — the named modules build without it, so nothing to pin
wrap the verify gate's -pl list across a continuation	still compares the full set
replace the scan's -pl with a whole-reactor build	passes, as more coverage should