andrewmusselman opened a new issue, #42: URL: https://github.com/apache/tooling-agents/issues/42
L1 scan at https://github.com/apache/tooling-agents/tree/main/ASVS/reports/mina/accfb47 # mina 2.2.X L1 Audit: Triage Notes The mina 2.2.X ASVS L1 audit (commit `accfb47`) produced 26 findings. We reviewed each one against the actual source. Four need to be flagged so the project's triage does not waste time on them: ## Disregard — false positive **FINDING-011 — ObjectSerializationDecoder default-deny vs default-allow** The finding claims the deserializer defaults to permissive class acceptance when no `ClassNameMatcher` is configured. The actual code in `mina-core/src/main/java/org/apache/mina/core/buffer/AbstractIoBuffer.java` (lines ~2192 and ~2212) does the opposite: ```java if (!acceptMatchers.stream().anyMatch(m -> m.matches(className))) { throw new ClassNotFoundException("Class not in accept list " + className); } ``` An empty matcher list (the default after `ObjectSerializationDecoder` instantiation) means `anyMatch` returns `false`, the negation triggers, and deserialization throws `ClassNotFoundException` for every class. The default is already default-deny, not default-allow. The audit got the polarity wrong. Disregard the finding. ## Disregard — wrong premise **FINDING-016 — Spring Framework 2.5.6 dependency** The finding states this is used by the `mina-integration-xbean` module. `mina-integration-xbean/pom.xml` actually depends on `spring-beans` and `spring-context` (the modular Spring artifacts), which resolve to `${version.springframework}` = 7.0.7 via dependencyManagement. The `org.springframework:spring` 2.5.6.SEC03 entry in the root `pom.xml`'s dependencyManagement is dead version pinning of the legacy monolithic `spring` artifact, which nothing in the build currently pulls. Same shape as the log4j 1.2.17 entry (FINDING-008 is correct about that) — version pinned but unused, becomes a real exposure only if a future transitive dependency pulls the monolith. Disregard the finding as written. Both dead pins (log4j 1.2.17 and spring 2.5.6.SEC03) are best treated as a single Low cleanup item: remove the entries from dependencyManagement so future transitives cannot resolve to them. To prevent the same shape of error on future runs, we are adding a third project guidance document (`dependency_pin_triage.md`) that defines the `<dependencyManagement>` vs `<dependencies>` distinction, how to verify whether a pinned artifact is actually pulled onto a classpath, the modular-vs-monolithic groupId trap that misled the audit here (legacy `org.springframework:spring` vs modular `spring-beans` / `spring-context`), and severity calibration: dead pin → Low cleanup, active dependency on vulnerable version → severity per CVE. The next audit run against mina will be guided by all three documents. ## Treat as duplicate **FINDING-012 — HTTP Response Encoder CRLF** Same file (`mina-http/src/main/java/org/apache/mina/http/HttpServerEncoder.java`) and same bug as FINDING-004 (no CRLF sanitization on application-supplied header values). The two were kept separate during consolidation because they cite different ASVS sections (1.2.1 vs 2.2.1). The finding's own Priority field acknowledges the duplicate. Triage FINDING-012 together with FINDING-004; the only addition is the second ASVS section reference. ## Treat as duplicate **FINDING-013 — Decoder Validation Gaps at the Trusted Service Layer** This is an umbrella observation about `HttpServerDecoder` validation gaps (invalid header name characters, negative Content-Length, malformed request lines). The specific cases are already covered concretely by FINDING-003 (unbounded header accumulation) and the encoder findings (CRLF in headers and request URI). FINDING-013 does not name a specific code path the others miss. Triage FINDING-013 together with FINDING-003; the additional validation categories listed under FINDING-013's remediation are useful to fold into FINDING-003's remediation list. ## The remaining 22 findings These were verified against the actual 2.2.X source and are passed through as-is: - 1 Critical (FINDING-001, redacted from the public report and forwarded to the project's private security mailing list) - 7 High (FINDING-002 through FINDING-008) - 7 Medium after the FINDING-012 / FINDING-013 merges (FINDING-009, FINDING-010, FINDING-014, FINDING-015, FINDING-017, plus FINDING-003 and FINDING-004 carrying the merged content) - 9 Low (FINDING-018 through FINDING-026) The four TLS-related findings (FINDING-018, FINDING-019, FINDING-020, plus FINDING-009 for the in-`mina-core` `BogusTrustManagerFactory` foot-gun) are calibrated per the project guidance documents: modern JDK defaults cover most of the surface, so these are rated as defense-in-depth improvements rather than active vulnerabilities. Maintainers can downgrade further or close as wontfix at their discretion. ## On the audit itself For context, the previous run against the apache/mina default branch was wasted because that branch is dormant — it produced HTTP/2 and CoAP findings against code that does not exist on the active branches (2.0.X, 2.1.X, 2.2.X). The orchestrator now accepts an explicit `branch` parameter and the report metadata table records which branch was audited (`Branch: 2.2.X` for this run). Future testing against this project should pass one of the maintained version branches explicitly. Two project-specific guidance documents were loaded for this run (`mina_framework_scope.md`, `example_code_excluded.md`). They are responsible for the calibration noted above — TLS defense-in-depth at Low rather than High, `mina-example/` and `**/src/test/**` carved out, the in-core `BogusTrustManagerFactory` kept in scope as a real foot-gun. A third document (`dependency_pin_triage.md`) is being added now to prevent the FINDING-016 shape of error on future runs. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
