Add draft threat model + SECURITY.md/AGENTS.md discoverability

[potiuk]

What this is

A draft threat model for Apache JMeter, proposed by the ASF Security team for the JMeter PMC to review, correct, or reject — drafted by the Security team's threat-model tooling from JMeter's public docs and security.html, following the ASF Security threat-model rubric.

It is built on the existing security.html: that page's "Security Model" statements are lifted in verbatim as the documented core, and this document adds the surrounding threat-model structure (adversary model, in/out scope, properties, known non-findings, triage dispositions). It is a strict superset — nothing in security.html is weakened; that page stays the canonical reporting/policy page and should link here for the expanded model.

This PR:

• adds THREAT_MODEL.md — the draft model;
• adds SECURITY.md — a short security policy linking the threat model (and security.html);
• adds AGENTS.md with a ## Security section, so the chain AGENTS.md → SECURITY.md → THREAT_MODEL.md is mechanically discoverable by automated security scanners.

How to read it

Every claim is provenance-tagged: (documented) (from JMeter's docs/security.html/repo), (inferred) (reasoned from architecture, not yet confirmed), (maintainer) (confirmed by the PMC). This v0 is ~10 documented / ~26 inferred. The §14 Open questions section collects the inferred claims into waves for the PMC to confirm or correct. The model leads with the documented BY-DESIGN core — JMeter executes the (trusted) test plan it is given, and isolating untrusted .jmx is the user's responsibility — and then focuses the in-model boundaries on:

• the distributed-mode RMI surface (jmeter-server) and its RMI-over-SSL + Security-Manager defaults (wave 1);
• the opening-vs-running line for non-.jmx files (wave 2);
• whether a hostile system-under-test's responses are in scope for JMeter's parsers (wave 2);
• the forward isolation story given the JDK Security Manager's deprecation (wave 2).

Nothing here is a requirement — the model is for the PMC to own. Comment inline, edit the branch, or reply on the email thread.

[vlsi]

Thanks for the fast turnaround. If you have a public skill to create the model, it would be great if you could share it (sure we can run, steer it and so on).

I will check the output soon, however, my immediate thought is that we must forbid license headers in AGENTS.md.

They are pure waste of tokens. AGENTS.md loads in every session, so the files must contain only the bare minimum. Sure license header is a pure waste when it comes to AGENTS.md and any other reference files the model consumes.
There's .ratignore and friends (sure I can configure it, it is not like I am asking you to update the PR). If you created other AGENTS.md with license headers, I would recommend removing the headers.

PS. I consider using https://github.com/microsoft/apm for managing agent configurations and sharing skills, however, it is orthogonal to the PR.

[potiuk]

Thanks for the fast turnaround. If you have a public skill to create the model, it would be great if you could share it (sure we can run, steer it and so on).

I will check the output soon, however, my immediate thought is that we must forbid license headers in AGENTS.md.

They are pure waste of tokens. AGENTS.md loads in every session, so the files must contain only the bare minimum. Sure license header is a pure waste when it comes to AGENTS.md and any other reference files the model consumes. There's .ratignore and friends (sure I can configure it, it is not like I am asking you to update the PR). If you created other AGENTS.md with license headers, I would recommend removing the headers.

PS. I consider using https://github.com/microsoft/apm for managing agent configurations and sharing skills, however, it is orthogonal to the PR.

IN Airlfow we are using SPDX headers for all agentic skills for that very reason. If you want I can change ti this way in your PR as well, not sure if you are checking licences but this seemed to be result of the discussion we had on this subject in https://lists.apache.org/thread/j1tn63r2lf13v3d1tnnqff8fkcl4nx53 - while we do not have formal legal policy on that , seems that we can interpret the existing poliicy this way.

[potiuk]

I am absolutely happy to update the PR :)

[potiuk]

Done — stripped the Apache license headers from AGENTS.md, SECURITY.md, and THREAT_MODEL.md (they're reference docs consumed by agents/scanners, so the headers were just token overhead), and added all three to .ratignore so the RAT check stays green.

[potiuk]

Ad the SKILL is linked above in the PR description

[milamberspace]

PMC review of the draft threat model (v0) — 6 inline comments below addressing the open questions in §14, one identified gap (HTTPS recording proxy), and a correction on the Security Manager forward story for JDK 24+.

[milamberspace]

On ASF license headers in AI agent-facing files

Following up on @vlsi's comment about token waste in AGENTS.md: the PR already handles this correctly (headers removed, .ratignore updated), but it is worth stating the rationale explicitly for future reference.

Why license headers should be omitted from AI-facing files:

Files such as AGENTS.md, CLAUDE.md, COPILOT-INSTRUCTIONS.md, or any file whose primary purpose is to be loaded as instructions by an AI agent should not carry ASF license headers. The reasons:

1. Every token has a cost. These files are loaded into the AI model's context window at the start of every session. A standard Apache license header is ~80–100 tokens. For a file like AGENTS.md (currently 9 lines of actual content), the header would exceed the useful payload. At scale — many contributors using AI tooling daily — this is a measurable and entirely avoidable waste.

2. Zero informational value for the consumer. An AI agent reading AGENTS.md needs instructions, not license metadata. The header adds noise that dilutes the signal-to-noise ratio of the file and may marginally affect how the model prioritises the actual instructions.

3. .ratignore is the right mechanism. ASF RAT exists to ensure source files carry attribution. Files designed for machine consumption are not "source files" in that sense — excluding them from RAT via .ratignore is exactly the intended use of that escape hatch.

Recommendation for future files of this type: any file whose primary consumer is an AI agent (not a human reader or a build tool) should be added to .ratignore from the start and kept as concise as possible. This applies to AGENTS.md, SECURITY.md and THREAT_MODEL.md as added in this PR, and to any similar files added in the future.

The current PR's approach — removing the headers and updating .ratignore — is the correct one.

---

Broader suggestion: an ASF-level discussion on AI-facing files

This raises a question that goes beyond JMeter alone. As AI tooling becomes standard in open source development, it would be worth opening a discussion within the ASF (e.g. via the dev@community.apache.org list or the ASF Infrastructure / Legal teams) to establish a shared policy on how AI-facing files should be treated across all Apache projects.

The current full license header is clearly overkill for these files. A reasonable middle ground could be a lightweight attribution line — something like:

# Part of the Apache JMeter project — https://jmeter.apache.org — Apache License 2.0

This would:

• Preserve attribution and licence discoverability for any agent or tool that reads the file
• Cost only a handful of tokens instead of ~100
• Satisfy the spirit of ASF attribution without the overhead of the full boilerplate

A shared ASF convention on this point would benefit all projects adopting AGENTS.md, CLAUDE.md, or similar files, and would give RAT maintainers clear guidance on how to handle this growing category of files.

[potiuk]

Recommendation for future files of this type: any file whose primary consumer is an AI agent (not a human reader or a build tool) should be added to .ratignore from the start and kept as concise as possible. This applies to AGENTS.md, SECURITY.md and THREAT_MODEL.md as added in this PR, and to any similar files added in the future.

@milamberspace - of course - I 100% agree with it. Chiming in in https://lists.apache.org/thread/j1tn63r2lf13v3d1tnnqff8fkcl4nx53 and stating your position in the thread might be a good first start - as well as anyone else who thinks like it.

This is in the camp of legal now to clarify it - and we need people like you to take the lead and drive it to policy change. I am 100% happy to support you!

[potiuk]

Generally - the more people we have stating their poistion in those discussions - the better! Please do so.

[potiuk]

Pushed a v1 folding in your review — thanks @vlsi @milamberspace. What changed:

• RMI SSL defaults (your source review): adopted in full — §4/§5a/§8 now state server.rmi.ssl.disable=false, mutual client-auth, keystore-not-shipped (engine won't start unprotected), resolved-address bind. "Unauthenticated/RCE-by-default" is now explicitly not valid; an exposed engine needs server.rmi.ssl.disable=true, classified OUT-OF-MODEL: non-default-config (@vlsi's point — runtime opt-out, no rebuild), added as a distinct §13 disposition. CVE-2019-0187 noted as the class these defaults close.
• Security Manager: dropped as a recommended defense (§5/§9/§10) — flagged deprecated for removal (JEP 411); the real distributed defense is RMI-over-SSL. Noted security.html's recommendation should be updated.
• Opening vs running (@vlsi): adopted your line — opening a .jmx is safe given trust in the distribution's existing classes; in-model only if opening generates and executes a new class.
• Hostile SUT (@vlsi → @milamberspace): moved out of model — the tester targets only systems they own/are authorised to test, so parser robustness vs a hostile SUT is hardening, not a claimed property. Marked "pending @milamberspace" in the doc; happy to add a narrow in-model carve-out if you'd both prefer.
• Added @milamberspace's "disable RMI SSL then expose jmeter-server" misuse (§11). §14 waves 1–2 marked answered.

On the broader "AI-facing files" point (@milamberspace): strongly agree it's worth an ASF-level convention. Happy to help take it to the relevant list.

[milamberspace]

Q5 (hostile SUT) — confirmed out of model

Agreed — no in-model carve-out needed.

The trust boundary is clear: an operator tests only systems they own or are authorised to test. Parser robustness against a hostile SUT (XXE on XPath Extractor, ReDoS on regex patterns, unbounded response sizes) is desirable hardening, but classifying it as a claimed security property would essentially mean saying "JMeter is safe to point at attacker-controlled infrastructure" — which is not the intended use case and would be an untenable claim.

Classification: VALID-HARDENING (internal audit track, not an in-model threat). §9 "safe response handling — UNSPECIFIED / best-effort" is the right framing.

The current v1 wording works well. §14 wave 2 can be fully marked answered.

[milamberspace]

One additional suggestion on §2 scope — see inline comment below.

[potiuk]

Thanks @milamberspace and @vlsi — pushed a revision addressing the review:

• Security Manager: dropped the recommendation; reframed as removed on JDK 24+ (JEP 486), not a forward defense, with the JDK 17 / 18–23 / 24 table. OS-level isolation (container / systemd / dedicated user) is the replacement story.
• Hostile-SUT responses (§6–§8 contradiction): resolved — a hostile system-under-test's responses (XXE/ReDoS) are out-of-model (VALID-HARDENING at most), now consistent across §3/§6/§7/§8/§9/§11a.
• Opening vs running (§14 Q4): formalized — opening a .jmx is safe iff you trust the existing classes in the distribution (deserialization → existing-class init); new-class instantiation / unanticipated execution is a vuln. Marked answered.
• HTTPS recording proxy: added ProxyControl as a modeled surface (CA-key boundary, proxy.cert.validity default, operator duties, proxy-port non-finding).
• Added five §11a known-non-findings (Runtime.exec, reflection, proxy port, changeit, XXE) and folded your §14 Wave-1/2 answers in as (maintainer); corrected the jmeter-server bind story (not loopback-restricted by default).

Two items I left as §14 questions rather than guess: the exact XStream allowlist mechanism (a static org.apache.jmeter.** would break third-party plugins — classloader vs manifest vs denylist), and the security.html backlink / reference Dockerfile (separate-file follow-ups). WDYT?

[potiuk]

Note for reviewers: the only failing matrix cell is 25, microsoft, windows, Pacific/Chatham, fr_FR (Java 25 EA on Windows with a non-default locale + timezone) — environment-specific and unrelated to this PR, which only adds documentation/discoverability files. The other cells pass. Happy to rebase if you'd like a fresh run.

[potiuk]

Thanks @milamberspace and @vlsi — your full review is already folded into the v1 model; resolving the threads now. Confirmed in-model: the HTTPS recording-proxy (ProxyControl) local trust boundary (§2/§4/§5a); the RMI defaults (server.rmi.ssl.disable=false, mutual client-auth, keystore-not-shipped) + bind-interface-not-restricted nuance (§4/§5a); the Security-Manager JDK-24/JEP-486 removal with OS-level isolation as the forward path (§5/§9/§10); the open-vs-run / XStream AnyTypePermission no-op boundary (§4/§8/§9); §11a seeds (Runtime.exec/OS Process Sampler, proxy port, changeit); authorized pen-testing as a recognized §2 use; and the security.html backlink tracked as §14 Q8. Wave-1/2 §14 questions are marked answered.

Applied @vlsi's AGENTS.md suggestion — trimmed to the bare Security model: [SECURITY.md](./SECURITY.md) pointer.

Tracked follow-ups (engineering, not model blockers): the XStream allowlist (closes the CVE-2013-7285 TODO), the security.html backlink, and a reference hardened-jmeter-server Dockerfile/unit. The model is the PMC's to merge whenever — thanks for the deep source-level review.

[milamberspace]

LGTM @vlsi
If it's good for you also, please, merge this PR.

[vlsi]

Many thanks to @potiuk for extremely fast turnaround and pushing this forward.

[potiuk]

Thank you for being so responsive :)