Thank you for your response. I appreciate the significant effort involved in maintaining TomEE, particularly with limited contributors.
However, I would like to clarify a few points. *First, regarding security disclosures*, Apache Tomcat provides a good example of coordinated vulnerability management. In some cases, fixes are released one or two maintenance versions before the CVE is publicly disclosed, allowing time for additional testing and identifying potential regressions. Publishing dozens of CVEs simultaneously, particularly for EOL versions without available fixes, can create serious security risks. Attackers receive vulnerability information while enterprise users may have no immediate remediation options. I believe disclosure timing, validation, and regression testing deserve more consideration. *Second, regarding project governance*, TomEE is an open-source project, and transparency is fundamental to its community. Looking at recent development activity, it appears that you and Markus Jung are among the few actively contributing developers. I understand that security vulnerabilities must be discussed privately. However, are broader project decisions, such as participation in AI-based scanning initiatives and general disclosure policies, also being made outside the public developer mailing list? If so, how can the community participate in those decisions? Do you have any other discussion channels privately? *Finally, regarding volunteer contributions*, you emphasized that nobody is paid by the project. Looking at the commit history, you clearly dedicate substantial time and effort to TomEE, which is appreciated. May I respectfully ask whether all this work is done entirely in your personal time, purely out of interest in the project, or whether some of your contributions are supported by an employer, sponsor, or another organization? There is absolutely nothing wrong with commercially supported open-source development. I am simply interested in understanding how the project is maintained, particularly given your comments about volunteer resources and participation. My intention is not to question anyone's dedication, but to encourage transparency, broader community involvement, and responsible security management. I fully respect that your volunteer time is limited, and I appreciate your contributions to the project. However, I do not believe that limited volunteer time should be used as a reason to dismiss legitimate questions about project governance, security decisions, and transparency. Apache TomEE is an ASF project governed by ASF policies, not a privately managed project. While individual contributors are not obligated to respond to every question, the PMC has a collective responsibility to ensure appropriate transparency and accountability for project-level decisions. I am not requesting confidential vulnerability details or internal scanning methodologies. I am asking about the decision-making process and general security policies that affect the entire TomEE community. If you do not have the time to address these concerns personally, I would appreciate it if other PMC members could participate in the discussion rather than leaving these questions unanswered. (*ASF Bylaws §6.3*) Best regards, Ronzy On Fri, Nov 13, 2026 at 1:35 AM Richard Zowalla via dev < [email protected]> wrote: > Hi Ronzy, > > ASF projects get security reports every day, many of them AI-generated. > ASF Security triages them against the project’s security model > and forwards the valid ones to the PMC’s private list, where the PMC deals > with them. CVEs are not discussed in public. > > If a PMC doesn’t do this itself, someone else will. These tools are > available to everyone, and every project is a scan target. > Look at the volume of ASF advisories on oss-security ( > https://oss-security.openwall.org/wiki/mailing-lists/oss-security), > and you’ll see it’s happening to every project, not just TomEE. > > Glasswing was announced before that blog post, while the scans were > already running. PMCs were asked privately > (via ASF Security and ASF Tooling) to participate, and we did. ASF > Security pre-triaged each report before it reached us. > The methodology won’t be shared. That’s an ASF-wide decision. > > A CVE doesn’t disappear because it isn’t listed. EOL versions are > affected, as are a lot of the transitive dependencies they ship. > EOL is EOL. Only 10.x and 11.x are maintained, and we just made that > clearer on the security page. > If you need support or help for older versions, there are commercial > vendors for that. > > TomEE is a volunteer-driven project. No one is paid by the project to work > on it. > If someone's employer pays for their time, that's an investment in a > component the employer uses. > However, TomEE has had a participation problem for a long time. Most of > the work is done by a few people, > often the same people who also maintain our upstream dependencies. > > No volunteer wants to spend their evenings after the day job reproducing, > triaging and fixing security reports. > It's not fun work, but we do it anyway. > > AI has sped up open source work, but maintainer burnout and maintainers > leaving are a real threat. > Since all of this is volunteer work, as David Blevins once put it: “If you > frequently take pennies and do not give, there will be no pennies.” > > If you care about the project as a user, it might be time to contribute. > The security model, the website, EE11, tests and fixes are all open for > PRs. > > I won't go into the individual points further because my volunteer time is > limited. > > Gruß > Richard > > > Am 12.11.2026 um 22:56 schrieb Ronzy Thomas <[email protected]>: > > > > Dear TomEE Community and PMC Members, > > > > I would like to raise some serious concerns regarding the recent large > > number of CVEs published for Apache TomEE, particularly those identified > > through Claude-based security scanning. > > > > First, I want to emphasize that I fully support improving the security of > > Apache TomEE. Identifying and fixing genuine security vulnerabilities is > > essential, and I appreciate the efforts of everyone contributing to that > > work. > > > > However, I believe we need a broader community discussion about how these > > security scans were initiated, how their findings were evaluated, and how > > the resulting CVEs affect users of older, unsupported TomEE versions. > > > > *1. Who decided to introduce Claude-based security scanning?* > > > > According to the ASF announcement published on September 3, 2026, the > > Foundation conducted large-scale security scanning using Anthropic's > Claude > > Mythos through Project Glasswing. > > > > Reference: > > > https://news.apache.org/foundation/entry/security-scanning-at-foundation-scale > > > > I understand that this was an ASF-level initiative. However, I have not > > been able to locate a public TomEE community discussion concerning > > participation in this scanning program. > > > > My questions are: > > > > - > > > > Was the TomEE PMC consulted before TomEE was included in these scans? > > - > > > > Who decided that this approach should be applied to the TomEE codebase? > > - > > > > Was the decision discussed on the TomEE development mailing list? > > - > > > > Was there a formal PMC decision, consensus discussion, or VOTE? > > - > > > > If such a discussion took place, could someone provide a reference to > > the corresponding mailing-list thread? > > - > > > > Did the TomEE PMC review and approve the threat model and scanning > scope? > > > > I recognize that individual security reports may require confidential > > handling and that not every operational decision requires a public vote. > > > > Nevertheless, adopting an initiative that results in dozens of public > > vulnerability announcements affecting a large existing user base deserves > > appropriate project-level oversight and transparency. > > > > *2. Why are we publishing so many CVEs affecting EOL versions?* > > > > On November 10, 2026, approximately 38 CVEs were announced for Apache > > TomEE, including findings affecting historical OpenEJB and TomEE > releases. > > > > A significant number of these findings affect older versions, including > > TomEE 7.x, 8.x, and 9.x, as well as legacy modules that have been removed > > from the current releases. > > > > This raises an important concern. > > > > There are many enterprise applications still running these older TomEE > > versions in production. In many cases, organizations cannot immediately > > upgrade because their applications depend on Java EE APIs, older Java > > runtimes, or complex application architectures. > > > > These organizations are already operating on versions that are no longer > > actively maintained by the Apache TomEE community. > > > > When we suddenly publish numerous additional CVEs against those releases, > > we create significant operational and compliance challenges for their > users. > > > > Security scanners begin reporting additional findings. Enterprise > security > > teams demand remediation, and customers are required to explain why these > > vulnerabilities remain unresolved. > > > > Yet, for many of these users, no official security patch is available for > > their existing version. > > > > In addition, migrating from TomEE 8.x or 9.x to TomEE 10.x is not > > necessarily a straightforward version upgrade, particularly because of > the > > transition from javax.* to jakarta.*. > > > > I believe our proactive security-scanning efforts should primarily focus > on > > the actively supported TomEE branches. > > > > This is not an argument for concealing genuine vulnerabilities in older > > software. Valid vulnerabilities should still be disclosed accurately, > > including their historical affected versions. > > > > However, I strongly believe that findings affecting only EOL releases or > > abandoned components should be handled and presented separately, with > clear > > support status, applicability information, and realistic remediation > > guidance. > > > > Otherwise, we risk creating significant problems for users without > > providing a practical solution. > > > > *3. Have all AI-generated findings been independently validated?* > > > > Another concern is how these vulnerabilities were evaluated before CVE > > publication. > > > > AI-based security analysis can be extremely useful, but the existence of > an > > AI-generated finding does not automatically establish that a > vulnerability > > is exploitable in a real-world deployment. > > > > For each reported vulnerability, I believe we should be able to > establish: > > > > - > > > > Whether it was independently reproduced and validated by a human > > reviewer. > > - > > > > Whether the affected functionality is enabled by default or requires a > > specific configuration. > > - > > > > Whether the vulnerable component is included in standard TomEE > > distributions. > > - > > > > Whether the issue can actually be exploited through a supported and > > realistic deployment configuration. > > - > > > > Whether all listed historical versions were tested or their affected > > status was inferred from source-code analysis. > > - > > > > Whether the finding was evaluated against TomEE's documented security > > model and trust boundaries. > > > > We should also distinguish between an actual security vulnerability, > > insecure configuration, a theoretical attack scenario, and behavior that > is > > intentionally supported by the architecture. > > > > I am particularly concerned about assigning broad affected-version ranges > > without clearly distinguishing verified impacts from inferred ones. > > > > *4. CVEs for components that have already been removed* > > > > Several of the recently announced CVEs affect legacy modules such as the > > embedded OpenEJB HTTP server, Hessian remoting, and the SSH > administration > > shell. > > > > The current TomEE security page explicitly states that these modules have > > been removed and that no fixed versions of those components exist. > > > > I understand that removing vulnerable functionality can be a legitimate > > security measure. > > > > However, for organizations that depend on these modules, removal is not > > equivalent to a security patch. > > > > How are such users expected to remediate these findings without > potentially > > redesigning their applications? > > > > Should we distinguish more clearly between vulnerabilities that have been > > patched and vulnerabilities whose affected functionality has simply been > > removed? > > > > I believe this distinction is extremely important for enterprise users > and > > security auditors. > > > > *5. Who approved the publication of these CVEs?* > > > > I found the public release votes for TomEE 10.3.0 and TomEE 11.0.0-M2. > > > > However, these votes concern the release artifacts. > > > > I would like to better understand the decision-making process surrounding > > the security advisories themselves. > > > > Were the findings reviewed collectively by the TomEE PMC or designated > > security team before publication? > > > > Was the scope of the affected versions reviewed? > > > > Was there a coordinated disclosure and remediation plan, particularly for > > users of unsupported branches? > > > > I am not suggesting that each CVE requires a public vote, nor that > > confidential vulnerability details should have been discussed publicly > > before disclosure. > > > > I am asking whether an appropriate project-level review took place and > > whether the community can receive a non-sensitive summary of that > process. > > > > *6. We need a clearer security policy for EOL releases* > > > > I would like to propose that the TomEE community establish a clearer > policy > > for future AI-assisted security scanning and CVE publication. > > > > In particular: > > > > - > > > > Prioritize active and supported release branches when planning > proactive > > scans. > > - > > > > Clearly separate supported and EOL versions in security advisories. > > - > > > > Distinguish verified affected versions from potentially affected > > versions. > > - > > > > Document actual exploitability conditions and relevant deployment > > assumptions. > > - > > > > Clearly distinguish a security fix from the removal of vulnerable > > functionality. > > - > > > > Provide realistic workarounds or migration guidance when no fix is > > available. > > - > > > > Review large batches of AI-generated findings through an agreed PMC > > security-triage process. > > - > > > > Communicate major changes in scanning and disclosure practices to the > > community, while protecting confidential security information. > > > > For legacy vulnerabilities, users should be told explicitly when no > > community-maintained fix is planned, rather than receiving upgrade > > recommendations that may not be technically feasible in their > environment. > > > > *7. The impact on the TomEE ecosystem* > > > > Apache TomEE has been used by organizations for many years, and the > > stability of its enterprise application environment is one of its > important > > strengths. > > > > A sudden increase in published CVEs can create substantial uncertainty > > among organizations that have relied on TomEE in production. > > > > Security transparency is essential, but so are accurate risk > > classification, responsible communication, and realistic remediation > > options. > > > > Publishing dozens of CVEs should not become the measure of success of an > AI > > security-scanning initiative. The real objective should be to reduce > > exploitable risk and improve the security of software that people > actually > > deploy. > > > > I am not against Claude, AI-assisted security analysis, or responsible > CVE > > disclosure. > > > > My concern is whether we have established the right governance, > priorities, > > validation standards, and disclosure practices for using these tools > within > > the TomEE project. > > > > I would appreciate clarification from the TomEE PMC on the original > > decision to participate in this initiative, the relevant discussion or > > approval records, and the policy we intend to follow for future security > > scanning and EOL-related CVE announcements. > > > > I believe this deserves an open discussion on the development mailing > list. > > > > Thank you for your attention. > > > > Best regards, > > > > Ronzy > >
