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:
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.
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
ClassNameMatcheris configured. The actual code inmina-core/src/main/java/org/apache/mina/core/buffer/AbstractIoBuffer.java(lines ~2192 and ~2212) does the opposite:An empty matcher list (the default after
ObjectSerializationDecoderinstantiation) meansanyMatchreturnsfalse, the negation triggers, and deserialization throwsClassNotFoundExceptionfor 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-xbeanmodule.mina-integration-xbean/pom.xmlactually depends onspring-beansandspring-context(the modular Spring artifacts), which resolve to${version.springframework}= 7.0.7 via dependencyManagement.The
org.springframework:spring2.5.6.SEC03 entry in the rootpom.xml's dependencyManagement is dead version pinning of the legacy monolithicspringartifact, 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 (legacyorg.springframework:springvs modularspring-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
HttpServerDecodervalidation 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:
The four TLS-related findings (FINDING-018, FINDING-019, FINDING-020, plus FINDING-009 for the in-
mina-coreBogusTrustManagerFactoryfoot-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
branchparameter and the report metadata table records which branch was audited (Branch: 2.2.Xfor 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-coreBogusTrustManagerFactorykept 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.