mirror of
https://github.com/apache/struts.git
synced 2026-08-04 22:27:10 +00:00
chore(agents): defines a new AGENTS.md focused on reporting vulnerabilities (#1680)
* chore(agents): defines a new AGENTS.md focused on reporting vulnerabilities * chore(security): makes SECURITY.md the source of truth * Fix typos in SECURITY.md and minor grammar correction * chore(security): clarify public GitHub repo PoC counts as disclosure Per @ppkarwasz review on #1680: expand the PoC bullet to make explicit that pushing a PoC to a public GitHub repo, gist, fork, or branch is public disclosure, and note that private repos require granting access to each PMC member individually. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: René Gielen <rgielen@apache.org> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
# Vulnerability Research Agent
|
||||
|
||||
You are helping a security researcher evaluate and report potential vulnerabilities in Apache Struts.
|
||||
|
||||
[`SECURITY.md`](SECURITY.md) is the source of truth for the Apache Struts vulnerability reporting process. **Read it first and follow it.** This file is a short
|
||||
LLM-facing wrapper around that policy; it does not replace it.
|
||||
|
||||
## Workflow
|
||||
|
||||
Before drafting any report, opening an issue, posting publicly, or reaching a security conclusion:
|
||||
|
||||
1. **Pre-reporting checks** — complete every step in [`SECURITY.md` § Before Reporting](SECURITY.md#before-reporting):
|
||||
- read the Struts security policy,
|
||||
- read the Struts security guidelines,
|
||||
- check previously disclosed vulnerabilities and Security Bulletins.
|
||||
2. **Assess** the finding against the questions in [`SECURITY.md` § Assessment](SECURITY.md#assessment). If the answers do not still point to a likely new
|
||||
framework vulnerability, stop and explain — do not draft a new report.
|
||||
3. **Report privately** to `security@struts.apache.org` following [`SECURITY.md` § Private Report Requirements](SECURITY.md#private-report-requirements) and
|
||||
[§ Report Quality Rules](SECURITY.md#report-quality-rules).
|
||||
|
||||
Do not open a public GitHub issue, Jira issue, pull request, mailing list thread, or discussion for a suspected vulnerability before private triage.
|
||||
|
||||
## Rules for AI Agents
|
||||
|
||||
- **Never submit a pull request that fixes a suspected vulnerability.** Before opening any PR, verify the change is not a security patch — OGNL injection,
|
||||
parameter filtering bypass, file upload exploit, authentication or authorization bypass, RCE, SSRF, path traversal, deserialization, XSS in framework
|
||||
components, etc. If it is, stop and direct the researcher to report it privately to `security@struts.apache.org` instead. Vulnerability fixes go through
|
||||
the private security process, not public PRs.
|
||||
- Do not speculate beyond what can be demonstrated. If severity is uncertain, say so explicitly.
|
||||
- If the issue turns out to be application misconfiguration, an already-disclosed CVE, or a non-Struts problem, stop and explain — do not draft a new report.
|
||||
@@ -63,6 +63,13 @@ protected File createTemporaryFile(String fileName, Path location) {
|
||||
}
|
||||
```
|
||||
|
||||
## Security Reports & Scans
|
||||
|
||||
For any security-related activity — vulnerability scans, security analysis, drafting security reports — **[`SECURITY.md`](SECURITY.md) is the source of truth**.
|
||||
Read it first and follow its pre-reporting checks, assessment checklist, and reporting requirements. Reports must be sent privately to
|
||||
`security@struts.apache.org`; do not open a public GitHub issue, Jira issue, pull request, or mailing list thread for a suspected vulnerability before private
|
||||
triage. [`AGENTS.md`](AGENTS.md) is a shorter LLM-facing wrapper around the same process.
|
||||
|
||||
## Testing
|
||||
|
||||
Tests use JUnit 5 with AssertJ assertions and Mockito for mocking. Run with `mvn test -DskipAssembly`.
|
||||
@@ -71,4 +78,7 @@ Tests use JUnit 5 with AssertJ assertions and Mockito for mocking. Run with `mvn
|
||||
|
||||
- **Title format**: `WW-XXXX Description` (Jira ticket ID required)
|
||||
- **Link ticket in description**: `Fixes [WW-XXXX](https://issues.apache.org/jira/browse/WW-XXXX)`
|
||||
- **Issue tracker**: https://issues.apache.org/jira/projects/WW
|
||||
- **Issue tracker**: https://issues.apache.org/jira/projects/WW
|
||||
- **Never submit a PR that fixes a suspected vulnerability.** Before opening a PR, verify the change is not a security patch (OGNL injection, parameter
|
||||
filtering bypass, file upload exploit, auth bypass, RCE, SSRF, path traversal, deserialization, XSS in framework components, etc.). If it is, stop and report
|
||||
it privately to `security@struts.apache.org` — see [`SECURITY.md`](SECURITY.md).
|
||||
+84
-2
@@ -11,7 +11,7 @@ and what potential vulnerability it can have:
|
||||
| 6.7.x | :white_check_mark: |
|
||||
| 2.5.x | ❌ |
|
||||
|
||||
## Reporting New Security Issues with thr Apache Struts
|
||||
## Reporting New Security Issues with the Apache Struts
|
||||
|
||||
([original](https://struts.apache.org/security.html))
|
||||
|
||||
@@ -29,7 +29,7 @@ All mail sent to this address that does not relate to security problems in the A
|
||||
```
|
||||
|
||||
Note that all networked servers are subject to denial of service attacks, and we cannot promise magic
|
||||
workarounds to generic problems (such as a client streaming lots of data to your server, or requesting
|
||||
workarounds to generic problems (such as a client streaming lots of data to your server or requesting
|
||||
the same URL repeatedly). In general, our philosophy is to avoid any attacks that can cause the server
|
||||
to consume resources in a non-linear relationship to the size of inputs.
|
||||
|
||||
@@ -38,3 +38,85 @@ The mailing address is: [security@struts.apache.org](mailto:security@struts.apac
|
||||
[General network server security tips](http://httpd.apache.org/docs/trunk/misc/security_tips.html)
|
||||
|
||||
[The Apache Security Team](http://www.apache.org/security/)
|
||||
|
||||
## Before Reporting
|
||||
|
||||
Before sending a vulnerability report, run through the following checks. They exist to prevent duplicate reports, public disclosure of untriaged issues,
|
||||
and reports for behavior that is already documented as insecure configuration.
|
||||
|
||||
### 1. Read this policy
|
||||
|
||||
Confirm:
|
||||
|
||||
- which Struts versions are currently supported (see [Supported Versions](#supported-versions)),
|
||||
- where reports must be sent (see [Reporting New Security Issues](#reporting-new-security-issues-with-the-apache-struts)),
|
||||
- which reports do not belong on the private security list.
|
||||
|
||||
### 2. Read the Struts security guidelines
|
||||
|
||||
Review the [Struts security guidance](https://struts.apache.org/security/) and determine whether the finding is already covered by documented secure
|
||||
configuration or application guidance, including but not limited to:
|
||||
|
||||
- Config Browser Plugin exposure,
|
||||
- direct JSP access,
|
||||
- `devMode` is required to exploit the vulnerability,
|
||||
- `@StrutsParameter` usage and parameter annotation requirements,
|
||||
- unsafe setters or getters exposed to request parameters,
|
||||
- use of incoming values in localization or forced OGNL evaluation,
|
||||
- raw JSP EL expressions,
|
||||
- custom error pages,
|
||||
- Dynamic Method Invocation and Strict Method Invocation,
|
||||
- accepted and excluded parameter patterns,
|
||||
- Fetch Metadata, COOP, and COEP protections,
|
||||
- OGNL sandboxing, allowlists, excluded classes/packages, and OGNL Guard settings.
|
||||
|
||||
If the behavior is caused by an application ignoring documented security guidance, that is not an Apache Struts framework vulnerability.
|
||||
|
||||
### 3. Check previously disclosed vulnerabilities
|
||||
|
||||
Compare the finding against already disclosed Struts vulnerabilities — affected versions, impact ratings, mitigations, and fixed versions:
|
||||
|
||||
- [Struts security information](https://struts.apache.org/security/)
|
||||
- [Prior releases and vulnerability notes](https://struts.apache.org/releases.html#prior-releases)
|
||||
- [Security Bulletins (S2 series)](https://cwiki.apache.org/confluence/display/WW/Security+Bulletins)
|
||||
|
||||
If the finding overlaps with a known vulnerability, link to the existing bulletin, advisory, CVE, or release notes instead of drafting a new report.
|
||||
|
||||
## Assessment
|
||||
|
||||
Before drafting a report, confirm:
|
||||
|
||||
1. Is the affected version supported?
|
||||
2. Is the behavior in Apache Struts framework code, rather than only in an application using Struts?
|
||||
3. Is it already documented as insecure configuration or unsupported usage?
|
||||
4. Is it a duplicate of a previously disclosed vulnerability or Security Bulletin?
|
||||
5. Can the impact be demonstrated with a minimal, self-contained reproduction?
|
||||
|
||||
Only proceed with a private report when these answers still point to a likely new vulnerability in the framework.
|
||||
|
||||
## Private Report Requirements
|
||||
|
||||
A useful private report includes:
|
||||
|
||||
- affected Struts version or version range,
|
||||
- affected component or module,
|
||||
- required application configuration, if any,
|
||||
- minimal reproduction steps,
|
||||
- expected behavior,
|
||||
- actual behavior,
|
||||
- demonstrated security impact,
|
||||
- whether authentication or special privileges are required,
|
||||
- proposed fix or mitigation, if known.
|
||||
|
||||
Do not speculate beyond what can be demonstrated. If severity is uncertain, say so explicitly.
|
||||
|
||||
## Report Quality Rules
|
||||
|
||||
- One vulnerability per report.
|
||||
- Keep reproduction steps minimal and self-contained.
|
||||
- Do not include unrelated findings.
|
||||
- Do not publish exploit details or proof-of-concept code publicly before the Struts project has triaged the issue. **Pushing a PoC to a public GitHub
|
||||
repository, gist, fork, or branch counts as public disclosure** — even a "test" or throwaway repo. Private repositories are acceptable for sharing a PoC,
|
||||
but access must be granted individually to each PMC member who will triage the report.
|
||||
- Do not send ordinary bugs, usage questions, or generic denial-of-service concerns to the private security list.
|
||||
- If the issue is not a vulnerability in Apache Struts source code, use the appropriate public support or issue channel instead.
|
||||
|
||||
Reference in New Issue
Block a user