Partner Checkmarx scan assessment — 2026-10-28

Scope and conclusion

Reviewed ghs_checkmarx_sanitized.xlsx, sheet ghs_checkmarx_sanitized: 118 findings, worksheet rows 2–119, across 13 repository names. Row numbers below are physical Excel rows (row 1 is the header), not scanner result ordinals. Workbook SHA-256: 7aa8ea5a4f4ad630f156db53d3071a1f3ed019c054c54364aa64bbb34228084d.

This is a source-based assessment, not penetration testing or certification of the partner deployment. During the initial assessment, no application code, deployment, database or workbook was changed. Subsequent source fixes are linked in the remediation follow-up below. The workbook supplies source/sink locations and comments, but no scanned commit, dependency lock/artifact, effective middleware chain, public response captures or full taint path. Verdicts apply to the reviewed local revisions below; historical and deployed closure needs the named evidence. Scanner severity and existing Result State are inputs, not independent proof.

The four confirmed rows represent two root causes: DOM XSS in two demo pages (rows 34–35), and OAuth response logging at two sinks (106–107). There are also important conditional issues: legacy CBC, rendezvous channel secrecy, missing public HSTS and session identifier semantics. Do not dismiss conditional findings as false alarms.

Merged remediation follow-up — 2026-10-28

All four confirmed findings now have merged source fixes on both master and 2.x. GitHub merge and issue states were verified on 2026-10-28: all four PRs are merged and all four issues are closed. Each repository’s pair of PRs resolves both of its reported findings.

The light-gateway fixes replace unsafe browser HTML rendering with text nodes; the reviewed follow-up also hardens the third demo and query-value encoding. The http-client fixes remove credential/provider payloads from request, response, status and exception logging, including the introspection sink. Regression coverage and validation results are recorded in the linked PRs.

Merge commits: light-gateway master 122330692c8ff991b6cb9886d9221cd932320895, 2.x 3f299c82d3eca1d8657bc97e5281e99e5a9278cc; http-client master fb95cb472b6ce382679efa344037e2ad2cae9a46, 2.x 35d1364ea01fb9ac0779d0bc3b68b56d312ac356.

The original assessment verdicts, counts and source baseline below are retained as historical evidence. Merged source remediation does not establish that the partner has deployed the repaired artifacts or rerun its scan; those remain deployment/partner closure checks. The separate MRAS logging and base-decryptor concerns are not resolved by these four PRs; the light-4j follow-up below now records the MRAS fix and the retained base-password waiver.

Portal-view remediation follow-up — 2026-10-28

portal-view #939, tracking issue #938, is merged into master at 48a7e027aa4fa778a8a05926301a1056ec92e088. It addresses all six portal-view rows that were not classified as false positives:

Local validation on the reviewed head 7a8a8cd: 1,153 tests in 166 files passed, as did the production build, lint (zero errors, 215 baseline warnings) and controller typecheck. Full-repository TypeScript checking still reports 172 baseline errors, with no new diagnostics after accounting for shifted line numbers. The GitHub portal-control-plane check passed on that head before merge. The repository follow-up records scope, historical evidence and deployment acceptance criteria.

These are merged frontend changes and regression evidence. They do not establish partner deployment, live OAuth/server state validation or backend cross-owner idempotency isolation. The exact partner scan revision and rescan remain outstanding. Other UUID call sites are outside this migration. The initial assessment verdicts/counts below remain historical; row 25’s original uncertainty about purpose is now resolved by repository history, without reclassifying the historical weak OAuth state generator as a false positive.

Gateway A13/A14 remediation follow-up — 2026-10-28

Superseded lifecycle follow-up: the examples described below were subsequently retired by master #265 and 2.x #266. See the retirement record. The browser fixes and residual analysis below remain historical evidence for surviving deployed copies.

Both remaining non-false-positive light-gateway findings after A12 have merged browser-source fixes:

A13 / Excel row 36: the canonical AI page and its embedded Kubernetes ConfigMap copy keep reconnect IDs in page memory, reuse them only for the same selected user/model, and no longer display them. Both storage types receive best-effort cleanup of the legacy sessionId key when accessible; blocked storage cannot be erased until a later load with access. Reconnect resets the assistant bubble, disables sending until OPEN and ignores replaced-socket events. Reload starts a new conversation. These client-side selection checks are not owner authentication.

A14 / Excel row 37: rendezvous channels use native crypto.randomUUID or UUID-v4 bytes from getRandomValues; missing/failing crypto reports an error before socket/callback creation. The same encoded channel is used for both requests, and direct channel/URL logging is removed. Replacing a connection closes the old socket, aborts its callback request and ignores late events or callback results. Callback abort cannot guarantee that the backend stopped processing a request.

Local validation passed on both reviewed heads (3d2bcec / 6b7c869): 7 tests, including 111 browser checks across six runs and a canonical/ConfigMap parity check. Tests cover both AI delivery paths with and without storage, asynchronous close ordering, stream separation, send-state guards, late callbacks, cryptographic channel generation and existing XSS protections. Negative controls reject the previous affected PR versions. Browser regressions and pre-commit passed on both GitHub PR heads. At this update, master’s Java source-build check is still running; no completed master build/distribution result is claimed. Java code was unchanged and local Maven suites were not run for these browser-only changes.

Residual protocol/deployment work: the reconnect session ID still travels in the existing URL query and can enter gateway/proxy access logs. Memory-only storage does not fix that exposure. Redact sensitive values; moving resume credentials off the URL requires a coordinated backend protocol change. Same-origin script compromise can still access page memory. Verify authenticated session ownership, peer admission, expiry/replay enforcement and HTTPS/WSS against the deployed backend, then rerun the partner scan. A13/A14 remain conditional for deployment closure; neither browser tests nor random channel IDs establish those controls. See the merged security guide.

Gateway AI demo retirement — 2026-10-29

The owner chose retirement of the examples backed by archived light-genai-4j, rather than a new backend resume protocol. Tracking: light-gateway #264. GitHub confirms both PRs merged on 2026-10-29:

The source removal covers config/ai-gateway, config/llmchat-gateway and config/llmchat-rendezvous, their demo configuration/fixture stores, the embedded Kubernetes AI page and its public ConfigMap/volume mount, and the browser-only regression suite/workflow whose subjects were removed. These examples contain the A12/A13/A14 entry points (Excel rows 34–37). General gateway/WebSocket Java implementations are unchanged; no fix or protocol migration was published to the archived backend. This is retirement evidence, not a new spreadsheet finding.

The Kubernetes gateway template remains available without bundled public UI. Historical startup.serviceId and sample name/instanceId defaults are deliberately preserved. They can still select old config-server values, so deployments must review their explicit identity and configuration. The retired local credential values.yml path remains ignored. The new retirement guide provides cleanup/migration instructions; the old security-guide URL remains a historical compatibility link.

Local validation rendered and parsed all four remaining Kubernetes resources on each branch with disposable inputs. Volume and ConfigMap/Secret references resolved, identity defaults matched the pre-removal template, the legacy local values path remained ignored, and retired assets/workflow references were absent. Pre-commit and diff checks passed. Java code was unchanged; no new Java or live cluster qualification is claimed for this removal.

Deployment closure: merging or pulling does not remove copied/cached pages, old public ConfigMaps, config-server routes/values, ignored workstation files or existing backend deployments. Retire those copies and confirm the affected public chat/callback endpoints are no longer exposed. For any deliberately retained custom deployment, the original ownership/admission, expiry/replay, URL logging and HTTPS/WSS checks still apply. Attach retirement/artifact evidence or a partner rescan before closing A12/A13/A14; original worksheet verdicts/counts remain historical.

JDBC session A15 remediation follow-up — 2026-10-28

The re-evaluation of A15 / Excel row 38 confirmed that the default allowlist blocks unlisted deserialization hooks, but found a resource-limit gap: a serialized 2 MiB string (2,097,165 bytes) and roughly 4 MiB string array bypassed the intended 1 MiB filter streamBytes check. The same string was accepted through the repository conversion path. This demonstrated a missing byte bound, not deployed RCE or DoS.

Both source-fix PRs are merged:

The reader now pre-validates at most limit + 1 serialized bytes before constructing ObjectInputStream; the converter also bounds writes. The shared default is 1 MiB per attribute, configurable at instance construction using light.session.jdbc.serialization.maxAttributeBytes. Invalid settings fail construction; raising the limit requires a reviewed migration and heap budget. The class allowlist and depth/reference/array filters remain intact.

JDBC loading uses getBinaryStream and hydrates without writes or reserialization. A rejected attribute excludes its entire session, while healthy sessions remain available in getSessions(); findById returns null for that rejected session. Close-only stream errors do not discard successfully decoded data. Saves preflight pending attributes before SQL, propagate failure, attempt explicit rollback and retain pending edits until correction/retry. Flags clear after confirmed commit; a failed commit can still have an uncertain database outcome requiring reconciliation.

Each branch passed the local full suite: 37 tests, zero failures/errors, two existing skips, including public H2 save/load/rollback regressions. All five new public repository tests fail on the prior implementation. Pre-commit passed on both reviewed PR heads (39f2e68 / b2ad19b); no remote Maven test job was listed. See the merged JDBC guide for compatibility, failure semantics and migration instructions.

Remaining boundaries: this is a per-attribute limit, not an attribute-count, per-session aggregate/decoded-heap or listing-wide budget. getSessions() materializes valid results and write preflight buffers pending attributes. JDBC drivers may buffer columns internally; PostgreSQL/Oracle production-driver behavior was not qualified by H2 tests. Review database constraints, allowlist/filter-factory settings, deployed request-error handling and actual artifacts, then rerun the partner scan. Merged source safeguards do not establish deployment closure or complete resource-exhaustion protection. Initial assessment counts remain historical.

Light-4j A17/A18/A20 remediation follow-up — 2026-10-28

Both PRs tracking light-4j #2828 are merged. GitHub merge metadata and containment of the final reviewed heads in the fetched target branches were verified after merge:

A17 / Excel row 43: the decryptor reads the salt from ciphertext; the master password is not the salt. Source inspection of the current light-encryptor producer found fresh random 16-byte salts and 12-byte GCM nonces for each encryption. The reader now validates these lengths, hex fields and a minimum authentication-tag length before requesting a password or running PBKDF2. This qualifies the original scanner interpretation; it does not establish how historical/deployed ciphertext was generated. Inventory the actual producing version and salt reuse before closure.

A18 / Excel row 45: both branches reject three-part zero-IV CBC values before password acquisition. There is no legacy opt-in or warn-first transition on 2.x. Users must re-encrypt those secrets to standard four-part AES-GCM before upgrading; nonstandard four-part lengths also require regeneration with the supported producer. YAML failures report source line/column and the config loader supplies the filename, without echoing the value. Only a three-part rejection advises legacy re-encryption; wrong-password/tampered GCM failures retain general password/format guidance. Standard GCM values retain the PBKDF2-HMAC-SHA256 parameters (65,536 iterations, 256-bit key) and 128-bit authentication tag. The legacy reader is removed in source; partner deployment and migration remain unverified.

A20 / light-4j Excel rows 47–68: scoped hardening removes the base/Auto derived-key cache and Auto master-password array cache, clears owned temporary password/PBE/key/ plaintext buffers, and clears temporary TLS password copies across the reviewed server, client, MRAS, Salesforce, bootstrap, fingerprint and JwtIssuer paths. JwtIssuer also closes the keystore stream. Arrays returned by downstream password providers remain borrowed unless explicitly registered as newly owned; shared configuration arrays are preserved. TokenKeyStoreManager already accepts borrowed char[] inputs and makes no toCharArray copies; an ownership test protects that contract. These changes do not cover A20 rows in other repositories or eliminate immutable configuration/request Strings, provider-internal keys or retained TlsConfig/authentication credentials.

The interactive Manual provider retains at most 32 successfully authenticated derived keys per instance with a five-minute reuse window, avoiding a prompt for every repeat decrypt. Failed authentication does not populate the cache. Expiration is lazy on the next key acquisition; idle keys can remain beyond five minutes. Eviction and explicit close clear cache-owned key bytes. Applications must arrange close at the end of the manual configuration session; use a new instance after a master-password change. Base/Auto deliberately repeat PBKDF2 instead of retaining keys. A local Java 25.0.3 repeated-value probe measured about 10.69 ms/decrypt versus 0.073 ms with the old warm cache; this is a measured cost, not a capacity qualification.

The additional MRAS password-prefix logging concern is fixed in these PRs. TRACE no longer logs fragments, and tests exercise actual key/trust-store loading, success/failure paths, short passwords and canary checks over log messages, arguments, throwable proxies and MDC.

Validation: the expanded focused suite passed on both review heads (ff11492 / 135594f): 35 tests, zero failures/errors, one existing disabled test. Clean affected-module/dependency reactors passed 969 tests on master and 921 on 2.x, with zero failures/errors and 53 skips each. Four client classes were explicitly excluded after the original unrestricted run stalled; these are selected reactor results, not full-suite qualification. Later diagnostic tests passed (two per branch), and all 18 tests affected by the final Sonar cleanup passed on each final head. The broader reactor was not rerun for those diagnostic/test-structure/comment changes. Final-head SonarCloud analyses reported zero issues and passed quality gates on both PRs; pre-commit also passed. This follow-up does not claim completed final-head source-build/native-binding CI or deployed/partner qualification.

Accepted residual concern: the public base-decryptor password default remains by explicit compatibility waiver in #2828. It is unsuitable as a production master secret. Password-provider selection and the Auto JUnit fallback remain unchanged; production should use an approved runtime-secret provider and re-encrypt any values protected with the public default. The measured PBKDF2 cost is also retained and documented, rather than hidden by a persistent base/Auto key cache.

See the merged migration guide for both branches’ format cutoff, credential ownership and manual-cache lifecycle. Verify the configured decryptor, actual ciphertext inventory, deployed artifacts, remaining memory-retention boundaries and partner rescan. A17 and deployment closure remain conditional; A20 remains scoped hardening. Original verdicts/counts below are historical and are not reclassified wholesale by these merges.

Portal, Lambda and HTTP-client A20 remediation follow-up — 2026-10-29

The following five PRs are merged. GitHub merge metadata, merge-commit containment in the fetched target branches, and matching full trees between the final reviewed heads and merge commits were verified on 2026-10-29. The tree comparison also covers merges whose rewritten history does not contain the original review head. The light-4j A17/A18/A20 PRs #2829/#2830 remain recorded in the preceding follow-up.

Light-portal — A20 / Excel rows 73 and 76

MembershipProjectionRepairMain and EntityIdentityBackfillMain now acquire a direct, non-pooled JDBC connection instead of constructing Hikari pools that retain additional password references. Optional protected password files take precedence; nonblank invalid file settings fail without falling back, while absent/blank file settings retain the environment-password fallback. Reads are bounded, use strict UTF-8 with leading-BOM/trailing-newline handling, and support secret-file symlink rotation. Owned file byte/character buffers are cleared. POSIX permission warnings name only the input variable, and sanitized connection errors retain class names and validated SQL metadata without raw driver messages or duplicate logging.

Connection acquisition has a 30-second caller deadline, adjustable with MEMBERSHIP_REPAIR_DB_LOGIN_TIMEOUT_SECONDS or ENTITY_CREATION_DB_LOGIN_TIMEOUT_SECONDS. Credentials remain owned by the worker until the driver finishes; Properties are then cleared and late connections are closed. An uncooperative driver can outlive the caller deadline and retain credentials in the meantime. JDBC password Strings, environment/configuration values and driver copies remain outside erasure guarantees. SQL, transaction/fencing rules, report formats and report/apply defaults are unchanged.

Recorded final-head local validation: 28 focused tests passed, zero failures, errors or skips, covering both CLI entry points with H2, file precedence/encoding/ rotation, owned-buffer/Properties cleanup, timeout/late-connection handling and sanitized diagnostics. Pre-commit passed. These are not PostgreSQL production-driver or live repair/backfill results. Packaged adoption requires rebuilding the hybrid command/query images that include db-provider, rather than only replacing thin service jars. See the merged operator guide.

Light-lambda-native — A20 / row 98; A25 / rows 90–97

The A25 re-evaluation confirmed that the reported credential/password logging paths were already mitigated on both branch baselines; the new TRACE privacy test also passed against the original implementations. The source fix addresses A20 and adds regression protection for A25. Configured username and sanitized path diagnostics remain; this is scoped protection of submitted passwords/headers, not removal of all identity data from logs.

Local Basic authentication avoids immutable decoded credential-pair/password Strings. Request-owned decoded/password bytes, comparison copies and temporary conversion buffers are cleared on returns and exceptions. Explicit encoder/decoder output arrays avoid discarded buffers during charset resizing. Unicode scheme matching, raw/encoded credentials, password colons, historical malformed-UTF-8 replacement behavior, statuses and LDAP dispatch remain compatible. The existing LDAP API still requires an immutable password String; borrowed request headers, configuration credentials, provider copies and JVM state may retain secrets.

Recorded final-head local validation: 34 focused tests passed on each branch, zero failures, errors or skips; pre-commit passed. Tests observe cleanup through real middleware return/exception paths, use mocked LDAP, and check TRACE log messages, arguments, MDC, throwable chains and returned statuses for full encoded credentials and distinct password fragments. Negative controls caught parsing, normalization, cleanup and logging regressions. No live LDAP or native/AWS deployment qualification is established. Rebuild and distribute the native Lambda artifact for adoption. See the merged Basic Auth guide.

HTTP-client — A20 / Excel rows 108–111

The client-keystore, private-key, configured-truststore and default/JDK-truststore handoffs now clear owned char arrays in finally blocks, including provider errors. The cleanup uses JDK APIs directly and adds no new minimum provided-config version or PasswordChars dependency. Configuration/system-property precedence, required/null password behavior, TLS policy, trust-manager composition and SSLContext caching remain unchanged for the qualified JDK providers. Borrowed Strings and provider-internal copies can remain in memory.

Early clearing assumes KeyStore.load and KeyManagerFactory.init consume or copy the caller’s array before returning. Providers that retain that reference for later use would see zeros. PKCS11, FIPS, builder-based and other custom providers need provider-specific ownership/lifecycle qualification; no universal JCA ownership guarantee is claimed.

Recorded final-head local validation: 34 focused tests passed on each branch, zero failures, errors or skips: 13 TLS ownership/isolation tests and 21 existing OAuth logging regressions. Pre-commit passed. Checked-in disposable JKS fixtures remove the keytool subprocess requirement. Full-context tests observe all four copies with default plus configured trust, check both issuer contributions to the composite trust manager, and cover default-store failure. Isolated/same-thread execution, a system-properties lock and an AutoClose state guard protect global state, including an injected cleanup failure. A compilation probe with PasswordChars removed from a copied config jar passes for both repaired loaders and fails for the previous PR heads. See the merged TLS ownership guide.

These are verified source merges and recorded focused JVM results. They do not establish new remote-CI/full-suite/native/distribution qualification, partner artifact adoption or a rescan. Confirm deployed artifacts, rebuild requirements, secret sources and logging/memory controls, and qualify actual JDBC/LDAP/TLS providers. A20 remains scoped hardening and A25 remains mitigated in reviewed source; the original worksheet verdicts/counts and pinned source mappings below are retained as historical evidence.

Light-spa-4j A28 remediation follow-up — 2026-10-29

For A28 / Excel rows 117–119, light-spa-4j #188 tracks the branch re-evaluation and regression protection. GitHub confirms both PRs merged on 2026-10-29:

The original mitigated verdict applies to the reviewed master baseline, not every branch. Re-evaluation found remaining JWT/CSRF diagnostics on 2.x. Its source fix removes those logs, redacts CSRF mismatch arguments, and removes the callback result/code/state and Facebook access-token logs identified during review. Configured status.yml entries are retained: CSRF mismatch ERR10039 defaults to HTTP 400, missing CSRF retains ERR10036, malformed tokens use ERR10000, and expired tokens use ERR10001. Key-resolution failures emit a fixed diagnostic with the exception class, without provider messages or causes. Microsoft-token key failures now return a logged 500 instead of the previous 401, deliberately matching the cookie path. Callback and renewal callers stop after failed cookie issuance. This does not backport master’s broader trust/CSRF redesign.

Recorded final-head local validation: 13 logging probes on master and 23 on 2.x passed. The selected affected reactors reported 151 tests on master and 77 on 2.x, zero failures/errors and one existing skip each. Two legacy Azure tests were explicitly excluded on 2.x because their fixtures name Microsoft endpoints. Tests pin error bodies and inspect messages, arguments, MDC, throwable chains, responses and escaped exceptions at TRACE. The 2.x probes exercise the real verifier’s cache-hit path, and local TLS integration tests exercise actual authorization/exchange callbacks with rejected issued tokens. Logging-only negative controls preserve HTTP behavior and fail both handlers’ successful-session probes on credential canaries. The earlier whole-handler restore experiment was confounded by status changes and is not evidence of 15 independent logging detections.

The duplicated module-local harness remains intentionally documented. See the master regression guide and 2.x remediation guide. These source merges and recorded local results do not establish live identity-provider, production logging, full-suite/remote-CI or partner deployment qualification. The adjacent callback/provider diagnostics were subsequently reviewed separately in issue #191 and PRs #192/#193. Raw transport logging and deployment checks remain separate. Verify adopted artifacts and logging configuration before partner closure. Original worksheet counts and pinned appendix mappings remain historical evidence.

SPA callback/provider privacy follow-up — 2026-10-29

The separate light-spa-4j #191 review addresses callback/provider diagnostics explicitly deferred from A28. It supplements, rather than replaces, issue #188 and PRs #189/#190. GitHub confirms both follow-up PRs merged on 2026-10-29:

The scoped callers no longer log authorization code/state, complete token results, GitHub codes or Portal social-user command payloads. Stateless/Facebook token failures preserve the provider HTTP status but return configured ERR10014 with fixed text instead of the raw provider Status. MSAL retains configured ERR11648 with a fixed safe argument. Success responses, trust policy and cookie handling are unchanged; the redacted error bodies are an intentional behavior change.

Portal diagnostics retain sanitized copies of cause types, bounded stack/cause/ suppressed chains and validated SQLState/vendor metadata, without provider exception messages. Fully qualified names also cover anonymous types. MSAL now uses PortalClient from its existing stateless-auth dependency instead of a shadow copy; deploy matching module artifacts. Both module contexts have privacy tests.

Recorded clean affected-reactor validation passed 159 tests on master and 85 on 2.x, zero failures/errors and one existing skip each. Two legacy Azure methods were explicitly excluded on 2.x because their fixtures contact Microsoft endpoints. The corrected refresh-token canary is asserted in the returned cookie before log checks. Local probes cover callback/Facebook error responses, GitHub’s existing code-processing stub, MSAL exchange failure, constructor failures and anonymous/ nested/cyclic Portal exceptions. Logging-only negative controls catch reintroduced token-result logging, raw MSAL Status logging and raw provider responses without changing HTTP outcomes. Final focused privacy checks and pre-commit also passed.

Root appenders inspect messages, arguments, MDC and throwable chains. Portal failure probes run all loggers/root at TRACE; callback probes run auth at TRACE with root capture at WARN. Raw transport TRACE can still print legacy callback URLs, and Portal’s encoded command/query URL transport remains a separate boundary. These are scoped source/JVM results, not full-repository, live-provider, production-log or partner-rescan qualification. See the merged provider-diagnostics guide. This follow-up adds no rows or category-wide reclassification to the workbook.

HSTS configuration follow-up — 2026-10-28

For A02 / Excel row 3, the original companion PRs, both 2.x backports and the master fixture follow-up are merged:

GitHub checks passed on the reviewed PR heads: source tests and pre-commit for both, plus distribution-readiness for http-sidecar. Local suites reported 244 tests (7 skips) for light-rest-4j and 34 tests (9 skips) for http-sidecar, with no failures or errors. Sidecar loopback tests exercise actual handler pipelines, direct/admin routes and proxied success, redirect, 404 and 500 responses with conflicting backend headers; the existing test keystores are reused.

Backport validation: local clean suites passed with 31 tests (9 skips) for http-sidecar 2.x and 238 tests (7 skips) for light-rest-4j 2.x, with no failures or errors. The matching master fixture correction passed 34 tests (9 skips), also with no failures or errors. The sidecar production configuration matches across branches; only the YAML parsing API differs in the tests. These are local validation results; the GitHub-check statement above refers to the original #141/#452 PR heads.

Deployment restriction: the opt-in overlay is for a dedicated HTTPS ingress instance. It disables plaintext HTTP, including the normal co-located sidecar egress port 9080; do not apply it to that topology. Use a separate ingress instance or enforce HSTS at a trusted TLS edge. Generic HeaderHandler does not distinguish HTTP from HTTPS listeners. Packaged defaults retain plaintext egress and do not enable HSTS. The example uses max-age=31536000 without includeSubDomains or preload.

Source/configuration remediation is merged; A02 remains conditional pending deployment verification. Verify the effective public HTTPS policy on favicon, normal, redirect and error responses, public HTTP handling and direct-origin restrictions, then rerun the partner scan. The original assessment counts below are unchanged.

Archived repository follow-up — 2026-10-28

The repository owner has archived oauth-kafka and light-controller. GitHub archive status was verified on 2026-10-28 at the canonical repository locations below. This lifecycle update applies to 17 worksheet findings; it is separate from the merged fixes for the four confirmed findings above.

The original scan findings and row mappings are retained for audit. Archiving is not a security patch or evidence that a finding is a false positive, and it does not establish that existing deployments have stopped using these components. For partner disposition, record the archived status and confirm whether the affected artifacts remain in use. Retire or migrate any remaining use to a maintained component; if legacy use continues, obtain the scanned source/artifact and assess the findings for that deployment. No replacement component, deployment retirement, vulnerability fix or technical closure has been verified by this archive update.

These entries refer to the spreadsheet findings, not to newly opened or closed GitHub security issues. The original 18 unresolved assessments comprised these 17 archived-repository findings plus the historical ProfileMenu finding in row 25; the portal-view follow-up above now establishes the historical generator’s OAuth-state purpose and records current source remediation.

Evidence baseline

All eleven available code repositories were clean when inspected. The documentation repository was also clean before this work. Source references in the appendix are pinned to these commits; they point to the reported file and line, which can have drifted. Detailed assessments name current symbols/lines.

Method: parsed the XLSX ZIP/XML directly without executing macros or external links; inspected source and relevant producers/consumers; checked UUID validation, Blob construction, cookie ownership, serialization filters, crypto format branching and log sinks. GitNexus query/context assisted the favicon trace. GitNexus explain reported no taint layer; its empty result is not evidence of safety. No code suites, browser exploit, live endpoint tests or partner Checkmarx rerun were performed for this documentation-only assessment. Documentation validation passed: all 118 worksheet rows are mapped exactly once, all assessment anchors resolve, git diff --check is clean, and mdbook build networknt-doc --dest-dir /tmp/networknt-checkmarx-book succeeds.

Detailed dispositions

A01: Favicon stored XSS

False positive — Excel rows 2.

FaviconHandler.handleRequest reads the fixed deployment resource favicon.ico, not a database or request body. Current lines 37–39 set image/x-icon and X-Content-Type-Options: nosniff before streaming bytes. No attacker-controlled resource name or HTML template is present. The claimed database-to-HTML flow is unsupported. A compromised deployment resource is a separate trust-boundary question. The workbook’s claim that every InputStream passes through SanitizerHandler is not a valid explanation: inbound body sanitization does not sanitize a file response or replace output-context controls. Do not apply an HTML encoder to icon bytes. Recheck headers on the partner’s scanned revision because its SHA is absent.

A02: HSTS on the favicon response

Conditional — Excel rows 3.

This handler does not set HSTS itself, but that does not establish the externally visible response lacks it: middleware or a TLS edge can add it. HTTPS-only origin service does not by itself prevent browser HTTP downgrade attempts. Inspect the public HTTPS response, redirect and error paths, and direct-origin access. If HSTS is absent, this is a real browser-facing configuration gap. If it is present at the edge, the missing application-local header is a defense-in-depth policy gap rather than proof of a missing browser control. First-visit protection additionally requires an appropriate preload policy; adding HSTS is not retroactive protection for an initial insecure visit. See RFC 6797. The existing light-4j/header HeaderHandler supports response policies; it must be enabled and registered on the applicable routes. The merged light-rest-4j #452 and http-sidecar #141 provide the consuming configuration and correct sidecar route coverage. Their HSTS example uses header.pathPrefixHeader to apply the policy at response-send time, after proxy backend headers are copied. See the HSTS follow-up above for validation and the dedicated HTTPS ingress restriction. Enable includeSubDomains/preload only after domain-wide compatibility review. Deployment/partner closure remains unverified.

A03: Snapshot dictionary prototype mutation

Conditional — Excel rows 4, 5.

Merged follow-up: portal-view #939 removes the unsafe construction primitive with null-prototype cell dictionaries and worker-transfer regressions. The paragraph below describes the initial source baseline; deployment/partner verification remains outstanding.

snapshotComparison.ts:40–56 really assigns into ordinary {} dictionaries with cells[snapshot.snapshotId]. A synthetic ID __proto__ with an object entry changes that dictionary’s prototype; this does not automatically mutate global Object.prototype. The production API has a significant guard: ConfigSnapshotValuesHandlerSupport:53–54 parses all requested IDs as UUIDs, and ConfigServerQueryPersistenceImpl.loadSnapshotMetadata:812–814 reads snapshot IDs as UUIDs from the database. Those IDs cannot be __proto__. Thus the assignment is a real unsafe primitive, but exploitability via the supported API is not established. Worker messages originate from the application, not an arbitrary cross-origin postMessage endpoint. Close as not exploitable only after confirming the deployed producer has these UUID guarantees and no alternate unvalidated producer. A null-prototype dictionary or Map is a small future hardening option; validate IDs at any alternate entry point.

A04: Test fixtures flagged as production secrets or cookies

False positive — Excel rows 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18.

All twelve cookie results point to Chat.test.tsx, which sets simulated CSRF/owner cookies while mocking authentication and WebSockets. HttpOnly cannot be set through document.cookie; a CSRF token used by JavaScript must be readable. These results do not establish production authentication cookies lack HttpOnly. Check actual server Set-Cookie headers separately. operationalStoreRegistrationContract.test.ts:25 supplies a dummy password specifically to assert that plaintext secret fields are rejected; it is not a production credential. Scope test files separately without suppressing equivalent findings in production code.

A05: Promotion export open redirect

False positive — Excel rows 19, 20.

At PromotionExport.tsx:405–413, href receives URL.createObjectURL for a freshly created JSON Blob and the anchor has a download filename. Query parameters affect export selection but do not become an arbitrary navigation URL. No external-origin redirect is established. Keep the Blob URL construction and revocation; revisiting this verdict is necessary if a future change assigns a query-supplied URL directly.

A06: Controller context cookie flag

False positive — Excel rows 21.

ControllerContext.tsx:135–145 constructs a WebSocket MCP client and reads a CSRF cookie via universal-cookie. It does not issue an authentication cookie or a Set-Cookie response; current line 153 is a client-lifetime guard. JavaScript-readable CSRF is intentional. Verify HttpOnly/Secure/SameSite on server authentication cookies independently.

A07: Cart passcode hardcoding

False positive — Excel rows 22.

CartMenu.tsx:130 is the literal API path /portal/command; line 152 renders data.passCode received from the order response. Neither is a hardcoded credential. This verdict does not certify the separate authorization or lifecycle of order passcodes.

A08: HSTS in browser automation script

False positive — Excel rows 23.

scripts/mcp-schema-browser-workflow.mjs:21–26 is a Node client fetching the loopback Chrome debugging API and parsing response.json(). It is not an application HTTP server generating browser-facing responses. HSTS is not fixed by adding a header to this fetch call. Keep the debugging interface loopback-only; public site HSTS remains covered by A02.

A09: Noncryptographic correlation and idempotency IDs

Hardening — Excel rows 24, 26, 27.

Merged follow-up: portal-view #939 removes weak fallbacks: chat/idempotency IDs use Web Crypto, while JSON-RPC correlation uses a per-page sequence. The paragraph below describes the initial source baseline. Backend owner/operation scoping still requires deployment verification.

codingRequest.ts:11–16 prefers crypto.randomUUID, then getRandomValues, with a Math.random fallback for client message IDs. fetchClient.ts:46 uses the fallback for JSON-RPC request IDs. knowledgeApi.ts:41–45 uses it for idempotency keys. These values correlate requests or deduplicate commands; the reviewed clients do not use them as credentials. Predictability alone does not prove authentication bypass. Use Web Crypto consistently and remove weak fallbacks where practical. Verify server idempotency keys are scoped to authenticated owner/operation and cannot expose another user’s response; collision or cross-owner reuse is a separate risk that these source lines alone do not prove.

A10: Historical ProfileMenu randomness

Unresolved — Excel rows 25.

At the initial assessment, ProfileMenu delegated to signIn and had no Math.random call; the scanned revision was unavailable, leaving the historical purpose unresolved. Follow-up history inspection establishes that commit c14f56b introduced Math.random for OAuth state, d239afd moved it to the shared sign-in helper, and 7f200a3 replaced it with crypto.randomUUID. The merged portal-view #939 now uses the shared secureRandomUUID helper, including its cryptographic byte fallback, and adds real menu/sign-in regressions and a visible retryable failure. The historical purpose is resolved and current source is remediated; this is not a historical false positive. The partner’s exact scan revision, deployed artifact and live OAuth/server validation remain unverified.

A11: Gateway WebSocket destination injection

False positive — Excel rows 28, 29, 30, 31, 32, 33.

All three pages construct the destination from window.location.protocol and window.location.host with a fixed /chat path. userId/model are interpolated after ?; characters in those values can change query parameters but cannot replace the URL’s authority with an attacker host. No attacker-selected WebSocket origin is established. Use URL/URLSearchParams for query encoding and require server-side authorization of user/model selection. The use of a UI-supplied userId is not proof of an authenticated identity and must never substitute for backend authentication.

A12: DOM XSS in Gateway demo pages

Confirmed at assessment; source fixes merged — Excel rows 34, 35.

Subsequent retirement: master #265 and 2.x #266 remove these demo entry points. See the retirement record; the baseline and earlier browser remediation below remain historical evidence.

Resolved through issue #258 and issue #259 by master PR #260 and 2.x PR #261; see the row-specific issue links in the remediation table above.

Both config/llmchat-rendezvous/public/index.html:155 and config/llmchat-gateway/public/index.html:91 interpolate untrusted text directly into div.innerHTML in log(). WebSocket event.data and, in the rendezvous page, backend callback response text reach that sink; user-entered text reaches it too. A message containing an image element with an event-handler attribute is parsed as HTML, rather than displayed as text. Exploitation against other users requires influence over a message or callback they receive; deployment exposure and CSP affect impact. This is a real source-level defect even though these are demo assets. Replace text interpolation with textContent/createTextNode, keeping a separately created strong element for the fixed role. The ai-gateway demo already shows the createTextNode pattern. Test malicious-looking messages as literal text before serving these demos to users.

A13: Browser storage of chat session ID

Conditional — Excel rows 36.

Subsequent retirement: master #265 and 2.x #266 remove these demo entry points. See the retirement record; the baseline and earlier browser remediation below remain historical evidence.

Merged follow-up: master #262 and 2.x #263 remove browser persistence from both the canonical and Kubernetes AI pages. The initial-baseline analysis below is retained; the reconnect URL exposure and backend/deployment checks remain outstanding.

ai-gateway/public/index.html:61–66 stores json.sessionId in sessionStorage and later sends it as a reconnect parameter. A session ID used only as an owner-authorized conversation identifier is not automatically a bearer credential; sessionStorage is tab-scoped but readable by same-origin JavaScript. If possession authorizes reconnection, XSS or script compromise can disclose the capability and the finding is real. Confirm backend ownership checks, expiry and replay behavior before closing; do not claim browser storage is inherently secure or move an actual authentication secret to localStorage.

A14: Rendezvous channel randomness

Conditional — Excel rows 37.

Subsequent retirement: master #265 and 2.x #266 remove these demo entry points. See the retirement record; the baseline and earlier browser remediation below remain historical evidence.

Merged follow-up: master #262 and 2.x #263 replace Math.random with Web Crypto and guard connection/callback lifecycle. The initial-baseline analysis below is retained; authenticated peer admission, ownership and expiry still need deployment verification.

The demo’s generateUUID uses Math.random for channelId and puts it in /chat and /connect. This has a stronger security implication than a JSON-RPC ID: the adjacent light-websocket-4j WebSocketRendezvousHandler.onConnect pairs peers through a shared CHANNELS map keyed by channelId, with backend role inferred from the configured path. That method does not itself prove ownership binding. If deployed admission relies on channel secrecy, weak generation is a real security defect. Generate with Web Crypto and authenticate/authorize both peers with owner binding and expiry. Obtain the actual Gateway chain and backend /connect authorization before asserting hijacking is reachable; no live exploit was attempted.

A15: JDBC session deserialization

Initial assessment: Mitigated in current source — Excel row 38. Reassessment qualified that verdict; source byte-limit fixes are now merged.

At the original pinned revision, database bytes reached ObjectInputStream.readObject through a default class allowlist and graph limits (depth 20, references 10,000, array length 100,000). Tests confirmed unlisted readObject classes were rejected before their hooks ran. However, the filter’s streamBytes check was not a hard 1 MiB bound: concretely encoded strings do not invoke the filter, and larger string payloads were accepted. See Oracle ObjectInputStream filtering.

Merged master #68 and 2.x #69 add an independent serialized-byte bound, bounded JDBC consumption, observable transactional save failures and isolation of invalid sessions during loading. See the A15 follow-up above for exact commits, validation and migration impact. The merged default class/byte controls are substantive mitigation, not proof that arbitrary Java deserialization is safe. Aggregate limits, driver buffering and deployed ownership/ database-write boundaries still require review. Configured allowedClasses and allowedPackages expand the trust boundary. Verify the deployed artifact/settings and partner rescan before closure; the older unfiltered revision can be vulnerable when an attacker can alter serialized attributes and a usable gadget is present.

A16: Labels and test password classified as keys

False positive — Excel rows 39, 40, 41, 42, 44.

SOAP PASSWORD_TYPE and DEFAULT_PASSWORD_TYPE are a configuration-field name and WS-Security type URI; actual credentials are read from configuration. AutoAESSaltDecryptor’s light_4j_config_password is an environment/property lookup name. ManualAESSaltDescryptor’s console string is a prompt. AutoAESSaltDecryptor’s light fallback is gated by a current-thread org.junit stack check; otherwise an absent runtime secret throws. These exact flows do not establish a hardcoded production key. Separately, base AESSaltDecryptor.getPassword itself returns a fixed default; see the additional real concern below and do not confuse it with the environment-variable label.

A17: Predictable PBKDF2 salt

Conditional — Excel rows 43.

AutoAESSaltDecryptor supplies the password, not the salt. AESSaltDecryptor.getSecret takes salt bytes from the CRYPT value’s salt field, and derives a key with PBKDF2WithHmacSHA256. A salt is public and need not be secret or unpredictable after generation; it should be unique and generated appropriately. The reported password-to-generateSecret flow does not establish a fixed salt. The merged light-4j follow-up above records current producer inspection and reader validation. Audit the actual producing revision and ciphertext inventory for reused/static salts before closure. Do not publish decrypted values or production secrets as evidence.

A18: Legacy AES-CBC support

Conditional — Excel rows 45.

At the initial assessment, AESSaltDecryptor supported AES-GCM for four-part values, but decryptLegacyCbc:68–72 retained AES/CBC/PKCS5Padding with an all-zero IV for three-part values. This is a real legacy cryptographic weakness when that format is still used: deterministic CBC leaks equality under the same key and does not authenticate ciphertext. It is not proof that AES itself is broken or that a remotely usable padding oracle exists. Inventory formats without disclosing plaintext, regenerate legacy secrets using the current GCM encryptor, and plan an explicit compatibility cutoff. Keeping a legacy reader does not prove deployed values have migrated. The merged light-4j follow-up above removes that reader on both branches and requires re-encryption before upgrade; deployment migration is still unverified.

A19: Default public truststore password

False positive — Excel rows 46.

Http2Client.loadDefaultTrustStore:1405–1444 uses the conventional cacerts default and permits configuration/system-property overrides. A truststore of public CA certificates is not a private-key credential or remote login password, and the value is not immutable. Its integrity still depends on file permissions and controlled trust-anchor updates. If that store is repurposed to contain private keys, reassess its contents and access policy.

A20: Heap retention of credentials and key material

Hardening — Excel rows 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 73, 76, 98, 108, 109, 110, 111.

These rows predominantly identify real in-process secret retention, not a demonstrated remote exploit. At the initial assessment, server/client TLS loaders, MRAS, Salesforce, Basic authentication, config bootstrap and repair utilities held configured or request credentials as Strings, and AutoAESSaltDecryptor cached password/key material for reuse. The merged light-4j follow-up above removes base/Auto caches and clears owned temporary copies; the manual provider has an explicit bounded cache, and retained configuration/API credentials remain outside complete erasure guarantees. An attacker able to read heap dumps, debugger state or process memory may recover them. Scope heap dumps/diagnostics, restrict process and filesystem access, minimize credential lifetime and rotate credentials after suspected disclosure. Where APIs allow it, use owned char[] buffers and clear temporary copies/PBEKeySpec after use; converting an existing String to char[] does not erase the original and clearing shared config arrays can break runtime behavior. The 2026-10-29 follow-up records the merged Portal (rows 73/76), Lambda (row 98) and HTTP-client (rows 108–111) hardening in addition to light-4j.

At the initial assessment, rows 56–59 pointed to char[] fields in TlsConfig, so the literal claim that those fields were immutable Strings was stale; those configuration arrays remain retained for reuse. Several scan lines had moved in that baseline: MRAS credentials were at 556–575, Salesforce certPassword at 226–250, DefaultConfigLoader truststorePassword at 574–588, User BasicAuth password at 176, and Lambda password at 159. The merged follow-ups above supersede these historical local-copy lifecycles, while borrowed configuration credentials remain retained. Treat this as low-priority memory exposure hardening subject to the threat model, not blanket false-positive suppression or proof that all secret retention can be eliminated.

A21: SHA-1 for deterministic identifiers

False positive — Excel rows 69, 105.

InstanceCloneIds.uuidV5 and Cli.deterministicUuid hash namespace/name data to construct stable identifiers; they do not encrypt sensitive data, hash passwords, sign bundles or create an authentication proof. UUIDv5 intentionally uses SHA-1. SHA-1 collision resistance must not be relied on for authorization, content authenticity or adversarial uniqueness, but these results do not establish the claimed broken protection of sensitive data. Do not silently change the algorithm: stable IDs are a persistence/replay compatibility contract. Bundle signatures in EnvironmentBundleArchive use Ed25519 separately.

A22: Event names and error identifiers

False positive — Excel rows 70, 71, 72, 89.

PortalConstants PASSWORD_FORGOT_EVENT, PASSWORD_RESET_EVENT and PASSWORD_CHANGED_EVENT contain event type names, not credentials. Lambda INVALID_USERNAME_OR_PASSWORD is an ERR status identifier. Variable names containing password are insufficient evidence for hardcoded passwords.

A23: Heap findings on a password hash and ciphertext

False positive — Excel rows 74, 75.

UserPersistenceImpl:155 reads the password field from the persistence map. The standard CreateUser:116–122 and OnboardUser:98–106 command paths hash it before persistence; the field name alone does not prove plaintext retention at this sink. This does not certify every import/replay writer: verify any alternate producer supplies hashes, and protect hashes from disclosure and offline guessing. ReplayPayloadCodec.StoredPayload.ciphertext is encrypted bytes, not a plaintext password. Its separate plain field may contain sensitive event data and needs its own lifecycle review; the reported ciphertext variable is not proof of plaintext credential leakage.

A24: Archived repositories; technical findings unverified

Unresolved technical assessment; repositories archived — Excel rows 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 112, 113, 114, 115, 116.

Lifecycle update: oauth-kafka and light-controller are archived, verified on 2026-10-28. See the archived repository follow-up above for treatment of these 17 findings and remaining deployment checks.

At the initial assessment, neither oauth-kafka nor light-controller nor the named source files was found under /home/steve/workspace or /home/steve/networknt. No substitute repository was assumed. For oauth-kafka, literal authentication field names and error constants may be false positives, but DefaultAuthenticator’s expectedPassword may be a genuine default credential; heap findings need the actual lifecycle. For light-controller, inspect whether bundled keystore material includes a shared private key and whether production can select it; distinguish a public truststore default from an actual database password. Obtain the scanned commit/artifact, source and redacted effective configuration before assigning a real/false disposition to any of these 17 rows. Do not close them from variable names or scanner comments alone.

A25: Lambda Basic authentication logging

Mitigated in current source — Excel rows 90, 91, 92, 93, 94, 95, 96, 97.

At the initial assessment, BasicAuthMiddleware.handleBasicAuth:146–200 no longer logged decoded credentials at the reported sinks. Failure messages and progress traces are fixed text; the path denial message removes CR/LF from requestPath. The scanner’s duplicated Base64/substr source flows do not demonstrate password disclosure in this revision. Historical comments cannot establish what the partner runs. Verify its deployed revision and use synthetic canary credentials to assert they never appear in ERROR/DEBUG/TRACE logs before closing the original eight results. Username/path logging is a separate data-minimization consideration. The merged Lambda follow-up, tracking issue #191 and PRs #192/#193, confirms this mitigation on both branch baselines and adds TRACE canary coverage alongside the A20 buffer cleanup.

A26: PEM labels classified as key material

False positive — Excel rows 99, 100, 101, 102, 103, 104.

EnvironmentBundleArchive:625–640 loads key bytes from a supplied Path with Files.readString, strips PEM BEGIN/END delimiters and decodes Base64. PUBLIC KEY, PRIVATE KEY and dash delimiters describe the PEM format; they are not cryptographic key bytes. Preserve external key files and permissions; no hardcoded signing key is established by these six results.

A27: OAuth response logging

Confirmed at assessment; source fixes merged — Excel rows 106, 107.

Resolved through issue #60 and issue #61 by master PR #62 and 2.x PR #63.

OauthHelper:670 traces the complete introspection body, which may include identity/claim data. At 836 it traces the full token responseBody before mapping it; successful responses can contain access and refresh tokens. This is a real disclosure when TRACE logging is enabled and accessible to a less-trusted reader. The scanner’s specific keystore-password-to-body flow is unsupported: using a password to initialize TLS does not imply the remote response contains it. Confirm the logging defect on the actual body content, not that taint inference. Remove full-body logging and allowlist safe metadata; similarly review token request form logging at 827–828 because it serializes params. A low log level reduces exposure but is not a code fix. Test synthetic tokens/client secrets across success and error paths before closure.

A28: SPA JWT log forging

Mitigated in reviewed master source; merged 2.x remediation — Excel rows 117, 118, 119.

Merged follow-up: master #189 adds regression protection for the existing master mitigation; 2.x #190 fixes the remaining legacy logging paths and preserves configured rejection codes. See the A28 follow-up for tracking issue #188, merge commits, branch-specific behavior and validation limits. The paragraph below describes the initial master baseline; it did not establish that 2.x was already mitigated.

The current MsalTokenExchangeHandler and StatelessAuthHandler verify tokens through their configured trust providers and no longer contain the reported JWT/claim debug/trace messages around the old sinks. These scan line numbers now refer to different statements. The reported cookie-to-log path is not reproduced by current source inspection. This is a current-source mitigation, not evidence that the historical finding was false or that all logging in these classes is safe: other request-path, authorization-code/state or token-result logging deserves a separate review. Confirm the deployed artifact and exercise CR/LF-bearing rejected input with canary-only logs before closing.

Adjacent diagnostics follow-up: master #192 and 2.x #193, tracking issue #191, address the separate callback/provider logging review. See the follow-up record for error-body behavior, regression evidence and remaining transport/deployment boundaries.

Additional concern found during review

Fixed default in the base decryptor: light-4j/decryptor/.../AESSaltDecryptor.java:getPassword returns a literal default password. This remains in the merged light-4j source by the explicit compatibility waiver in #2828; it is not fixed by the AES-GCM format cutoff. Unlike the AutoAESSaltDecryptor test fallback in row 44, direct production use of this base implementation provides no deployment-specific master secret. Anyone who obtains ciphertext and knows the public default can derive its key. Confirm the configured decryptor class before closure; use an approved runtime-secret implementation such as AutoAESSaltDecryptor and re-encrypt affected values. This is an additional root cause, not an extra row in the 118-row counts.

MRAS partial secret logging — merged source fix: at the initial assessment, MrasHandler traced the first four characters of keystore/key/truststore passwords. This was a real disclosure when TRACE was enabled, beyond the heap-retention category in rows 51–53; truncation was not masking and short passwords could throw. PRs #2829/#2830 remove those statements and validate actual TLS paths with synthetic canary logs, as recorded above. Verify the deployed artifact and logging behavior before partner closure. No production credentials were accessed to establish or test this.

Recommended closure sequence

1. Adopt the merged Gateway demo retirement and remove surviving deployed/cached copies. Deploy and verify the OAuth logging, portal-view and SPA callback/provider fixes linked above, then obtain partner scan or documented retirement closure. Deploy the merged light-4j MRAS logging fix as well and verify credential-free TRACE logs; its source regression tests use synthetic canary secrets.
2. Inventory the configured decryptor and ciphertext formats before adopting light-4j #2829/#2830. Replace fixed-default master secrets and regenerate legacy CBC/nonstandard values as authenticated standard GCM values; both branches now enforce the cutoff without a legacy opt-in.
3. Adopt and deploy the merged HSTS configuration linked in the A02 follow-up where applicable, respecting the dedicated HTTPS ingress restriction (normal sidecar egress needs port 9080). Verify public HSTS using HTTPS response captures and effective application/edge configuration; cover normal, redirect, error and favicon responses and direct-origin access before partner closure.
4. Complete A13/A14 retirement in actual deployments, including old config-server values and public ConfigMaps. For any deliberately retained custom deployment, verify session ownership, rendezvous peer admission and expiry/replay controls, and address reconnect-ID URL logging; repository removal does not repair that deployment. Confirm snapshot UUID validation; adopt the merged A15 safeguards and verify deployed filters, byte policy and remaining aggregate/driver resource boundaries.
5. Obtain the partner scan SHA/artifacts for applicability and closure. For archived oauth-kafka and light-controller, first confirm whether any deployment still uses them and plan retirement or migration; legacy use still requires source/artifact assessment. Re-run the scan and focused regressions on repaired artifacts for maintained components; maintain result-specific evidence rather than category-wide suppressions.
6. Adopt the merged A20 hardening for light-4j, light-portal, light-lambda-native and http-client linked above, with the applicable hybrid/native rebuilds and provider-lifecycle checks. Review remaining heap retention under a documented threat model, prioritizing long-lived master/private-key/DB secrets over public truststore defaults, hashes and ciphertext.

For partner closure, attach the source commit/artifact digest, exact result identifier, redacted effective configuration, focused test output and deployment verification. No real secrets or access tokens should be included. Infrastructure HSTS can satisfy a browser control even when a separate partner policy still requires application defense in depth. An inbound sanitizer cannot justify unrelated output, logging, deserialization or cryptographic findings.

Complete worksheet cross-reference

Every worksheet finding appears once below. Duplicate scanner rows remain separate for reconciliation. The Checkmarx result link/identifier remains in column P of the original workbook; it is not needed to access private partner systems for this review. Source links use the repository name as supplied by the scan; missing repositories have no claimed verified source link.