I'll leave it to other PMC members to add anything.
> Am 13.11.2026 um 14:27 schrieb Ronzy Thomas <[email protected]>:
>
> 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
>>
>>
