(tomcat) branch main updated: Add SECURITY.md per dev-list discussion 'Considering AI suggestions/guardrails for the tomcat project' (#1001)

This is an automated email from the ASF dual-hosted git repository.

csutherl pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
     new 42290257ec Add SECURITY.md per dev-list discussion 'Considering AI suggestions/guardrails for the tomcat project' (#1001)
42290257ec is described below

commit 42290257ec911aa358625af257886f2b8c85cffa
Author: Coty Sutherland <[email protected]>
AuthorDate: Tue Aug 18 14:11:01 2026 -0400

    Add SECURITY.md per dev-list discussion 'Considering AI suggestions/guardrails for the tomcat project' (#1001)
---
 SECURITY.md | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 133 insertions(+), 11 deletions(-)

diff --git a/SECURITY.md b/SECURITY.md
index db79646e0c..d835cb1520 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,14 +1,136 @@
-# Security
+# Security Policy
 
-Apache Tomcat's security model and disclosure process are
-published on the project website rather than in the repository:
+## Before You Report - Required Self-Check
 
-- **Threat model and security policy**:
-  <https://tomcat.apache.org/security-model.html>
-- **How to report a vulnerability**: see the Security section
-  of <https://tomcat.apache.org/>.
+**Complete this checklist. If you answer "No" to any question, do not submit a report:**
 
-The project website is the authoritative source; this file
-exists so agents and tooling that look for `SECURITY.md` in
-the repository can mechanically follow the link to the
-canonical documents.
+- [ ] I have read the [Tomcat Security Model](https://tomcat.apache.org/security-model.html) and my finding doesn't require access to config files, data stores, binaries, or admin interfaces
+- [ ] I have written a working Tomcat JUnit test case that compiles, runs, and demonstrates the vulnerability, or I have provided a justification as to why a JUnit test case cannot be written for this report and I have provided a minimal proof of concept
+- [ ] I have tested against the most recent release of a supported Tomcat version - this is not theoretical analysis or scanner output
+- [ ] I am submitting in plain text (no PDFs, archives, videos, or formatted documents)
+
+**Include this completed checklist in your report. If you cannot check all boxes, your report will be rejected.**
+
+## Where to Report
+
+**[email protected]** - Exclusively for undisclosed security vulnerabilities in Tomcat
+
+**Not for:** Bug reports ([Bugzilla](https://bz.apache.org/bugzilla/)), configuration help ([users list](https://tomcat.apache.org/lists.html)), theoretical issues, scanner output, or application vulnerabilities.
+
+## Common Invalid Reports - Do Not Send
+
+These will be **rejected without response**:
+
+- "Tomcat allows deploying WAR files that execute code" - Web apps are trusted, this is normal
+- "I can modify server.xml to change behavior" - Config files are trusted
+- "Sending lots of data crashes Tomcat" - Generic DoS without non-linear consumption
+- "XSS/SQLi in my deployed application" - Your app's bug, not Tomcat's
+- "Manager app accessible with valid password" - Admin users are trusted
+- Scanner reports without actual testing - Must verify manually with working PoC
+- Theoretical vulnerabilities or AI-generated reports - Must include working test case
+
+**Review the [security model](https://tomcat.apache.org/security-model.html) to understand what qualifies as a Tomcat vulnerability.**
+
+## Required: Working Test Case
+
+**Every report MUST include a complete Tomcat JUnit test case that:**
+- Extends `TomcatBaseTest` or appropriate test base class
+- Compiles against Tomcat source without errors
+- Runs via `ant test` and demonstrates the vulnerability
+- Uses real Tomcat APIs (not pseudo-code)
+- Includes comments explaining the attack and impact
+
+**The test must actually work - we will run it. If it doesn't compile or doesn't reproduce the issue, your report will be rejected.**
+
+**Exception:** If a JUnit test case cannot be written for your report, you must provide a clear justification explaining why a test case is not possible, along with a minimal proof of concept that demonstrates the vulnerability.
+
+### Example Structure
+
+```java
+package org.apache.catalina.security;
+
+import org.junit.Assert;
+import org.junit.Test;
+import org.apache.catalina.startup.TomcatBaseTest;
+import org.apache.catalina.startup.Tomcat;
+import org.apache.catalina.Context;
+import org.apache.tomcat.util.buf.ByteChunk;
+
+/**
+ * Demonstrates [specific vulnerability].
+ * Attack: [how it works]
+ * Impact: [security consequence]
+ */
+public class TestSecurityIssueXXXXX extends TomcatBaseTest {
+
+    @Test
+    public void testVulnerabilityName() throws Exception {
+        // Setup: Configure Tomcat to expose the vulnerability
+        Tomcat tomcat = getTomcatInstance();
+        Context ctx = tomcat.addContext("", null);
+        Tomcat.addServlet(ctx, "test", new YourTestServlet());
+        ctx.addServletMappingDecoded("/test", "test");
+        tomcat.start();
+
+        // Attack: Send malicious request
+        ByteChunk response = new ByteChunk();
+        int rc = getUrl("http://localhost:" + getPort() + "/test?malicious=payload",
+                        response, null);
+
+        // Verify: Demonstrate security impact
+        Assert.assertNotEquals("Should reject malicious input", 200, rc);
+        // Or: Assert.assertFalse("Response leaked sensitive data",
+        //                        response.toString().contains("secret"));
+    }
+}
+```
+
+## Required Report Information
+
+Include all of the following:
+1. **Summary** - 1-2 sentences describing the vulnerability
+2. **Tomcat Version** - Exact version tested (e.g., `Apache-Tomcat/11.0.5`)
+3. **Configuration** - Non-default settings needed to reproduce (if any)
+4. **Impact** - Specific consequence (RCE, information disclosure, authentication bypass, etc.)
+5. **Test Case** - Working JUnit test as described above
+
+**Format:** Plain text only (email body or `.txt`/`.java` attachments). No `.zip`, `.pdf`, `.docx`, videos, or screenshots.
+
+## What Happens Next
+
+1. **Acknowledgment** - Usually within a few business days, if the report passes initial screening
+2. **Validation** - We run your test case and assess impact against the security model
+3. **Fix & Disclosure** - If valid, we develop a fix and coordinate public disclosure timing
+4. **Credit** - Valid reports receive acknowledgment in security advisories
+
+Allow reasonable time (typically 90+ days) for fix development. We'll work with you on disclosure timing.
+
+## Security Model Quick Reference
+
+**Trusted (not security bugs):**
+- Administrative users, configuration files, data stores, Tomcat binaries (JARs, scripts)
+- Deployed web applications (app bugs are the app's responsibility)
+- Manager/Host Manager access, JMX, debugging interfaces
+
+**Untrusted (potential security bugs):**
+- HTTP/AJP connector data from clients
+- Malicious requests via supported protocols
+
+See the full [security model](https://tomcat.apache.org/security-model.html) for details.
+
+## Published Vulnerabilities & Updates
+
+- **Advisories:** https://tomcat.apache.org/security.html
+- **Announcements:** [Mailing lists](https://tomcat.apache.org/lists.html)
+- **Secure configuration:** https://tomcat.apache.org/tomcat-11.0-doc/security-howto.html
+
+---
+
+**Thank you for helping keep Apache Tomcat secure through high-quality, actionable vulnerability reports.**
+
+---
+
+The [project website](https://tomcat.apache.org/) is the authoritative source for
+Apache Tomcat's security policy and disclosure process. This file exists so agents
+and tooling that look for `SECURITY.md` in the repository can find the canonical
+documents.