mirror of
https://github.com/apache/struts.git
synced 2026-08-07 07:37:20 +00:00
Jarek Potiuk
dc90e48909
* Add draft security threat model (THREAT_MODEL.md) Generated-by: Claude Opus 4.8 (1M context) * SECURITY.md: link to THREAT_MODEL.md for scanner/triager discoverability Generated-by: Claude Opus 4.8 (1M context) * Fix dangling §14 refs and tighten provenance in threat model Address code-review findings on the THREAT_MODEL.md draft: - Add the missing §14 Q-env and Q-egress open questions, so every *(inferred)* claim that cites them now resolves (restores the "each inferred claim has a matching §14 question" invariant). - Tag the two previously bare *(inferred)* claims (examples/showcase, on-path attacker) with their matching question IDs. - Soften the §1 header: drop the ASF Security team / PMC authorship attribution on an unratified draft; state it is drafted for PMC review. - Correct the OGNL Java Security Manager wording: SecurityManager is deprecated for removal since JDK 17 and permanently disabled in JDK 24, not simply "does not work on JDK 21+". - AGENTS.md: point the Assess step at THREAT_MODEL.md's disposition guide so the triage wrapper links the model directly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Lukasz Lenart <lukaszlenart@apache.org> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
32 lines
2.3 KiB
Markdown
32 lines
2.3 KiB
Markdown
# 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), and route it through the disposition guide in
|
|
[`THREAT_MODEL.md`](THREAT_MODEL.md) (scope, trust boundaries, in-model security properties, and the known-non-findings list). 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.
|