mirror of
https://github.com/apache/struts.git
synced 2026-08-04 22:27:10 +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>
2.3 KiB
2.3 KiB
Vulnerability Research Agent
You are helping a security researcher evaluate and report potential vulnerabilities in Apache Struts.
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:
- Pre-reporting checks — complete every step in
SECURITY.md§ Before Reporting:- read the Struts security policy,
- read the Struts security guidelines,
- check previously disclosed vulnerabilities and Security Bulletins.
- Assess the finding against the questions in
SECURITY.md§ Assessment, and route it through the disposition guide inTHREAT_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. - Report privately to
security@struts.apache.orgfollowingSECURITY.md§ Private Report Requirements and § 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.orginstead. 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.