Add a draft security threat model (THREAT_MODEL.md) + discoverability wiring

[potiuk]

This is a proposal for the ActiveMQ PMC to review — please correct, reject, or discuss as needed. Nothing here is a requirement; the maintainers are the decision-makers and the PMC owns the document.

This adds a draft THREAT_MODEL.md for apache/activemq (Classic) and wires AGENTS.md -> SECURITY.md -> THREAT_MODEL.md so an automated security scanner can mechanically discover the model. This is the "jump start" the PMC asked us to bootstrap — a concrete starting point to react to rather than a blank form.

The draft was generated from ActiveMQ's own public artefacts (SECURITY.md, the security docs, advisory history) using the threat-model-producer rubric. Every claim carries a provenance tag:

• (documented) — lifted from an ActiveMQ doc; cited inline.
• (inferred) — our guess from architecture / domain norms. Every (inferred) tag has a matching numbered question in §14 "Open questions for the maintainers" to confirm, correct, or strike.

What's most useful from the PMC: walk the §14 questions (10 of them) and answer in-thread / on the PR — a one-line confirm / correct / strike each is enough. We fold the answers in and the (inferred) tags become (maintainer).

Please sanity-check these especially:

• §8 — the deserialization RCE guarantees (SERIALIZABLE_PACKAGES allow-list; OpenWire unmarshalling);
• §9 — the "default distribution is not secure until configured" stance and the false-friends (JMS selectors, ClientId, BlobMessage URIs);
• §11a — the known-non-findings list that suppresses recurring scanner noise.

Context: the ASF Security team is preparing projects for an automated agentic security scan we're piloting; discoverability (the AGENTS.md chain) is the one hard prerequisite — everything else is suggestion. This PR is the public-repo piece; program details are on the PMC's private list. This PR does not edit any existing content — it only adds the model + the discoverability wiring.

Questions / pushback welcome.

[mattrpav]

@potiuk thank you for the draft!

I made a first pass at edits. I would appreciate clarity on the proper way to edit the inferred areas and address the open questions from a how-to-format-it-in-the-doc perspective.

Is the intent to leave the references and simply update, or remove them?

A quick example of how to move one question from inferred -> confirmed would be appreciated.

Thanks

[potiuk]

mattrpav thanks for jumping in and for the first-pass edits — much appreciated.

Two equally-good ways to handle this; pick whichever is less friction for you:

Option A — just answer inline (easiest). Drop a comment on this PR with one line per §14 question: confirm / correct / strike. That's genuinely all we need — I fold the answers into THREAT_MODEL.md and push the revision back to this branch, so the PMC never has to touch the doc mechanics. This is how most projects have done it (examples below).

Option B — edit the doc directly in the branch, if you'd rather own the wording. The mechanics for that are below.

On the "leave the references or remove them?" question — leave them, just flip the tag. The provenance tags are load-bearing (they tell the scan agent and future readers which claims the PMC has ratified vs. which are still our guess), so they stay for the life of the doc. What changes per answered question is three small things:

1. Flip every matching *(inferred — see §14 Qn)* tag in the body to *(maintainer)* (or to *(documented — <cite>)* if it turns out a project doc already says it).
2. Fold the substance of your answer into the surrounding prose if it corrects or sharpens the claim.
3. Retire the §14 question itself once it's fully resolved — that numbered entry is scaffolding and does get removed (or struck). The tag in the body is what persists.

So: references-in-the-body stay (re-tagged); the §14 question goes away.

Worked example — moving Q9 (peer broker) from inferred → confirmed.

The claim today, in §2, reads:

• Peer broker (authenticated but adversarial): the other end of a network-of-brokers link. Holds a legitimate identity but can behave arbitrarily. (inferred — see §14 Q9)

and §14 Q9 asks whether ActiveMQ provides any cross-link safety guarantee or whether a malicious peer is wholly the operator's trust decision.

Say the PMC answers: "No cross-link authorization guarantee — a compromised/malicious peer is the operator's trust decision." After folding that in, the §2 bullet becomes:

• Peer broker (authenticated but adversarial): the other end of a network-of-brokers link. Holds a legitimate identity but can behave arbitrarily; the broker provides no forwarded-message authorization guarantee across the link, so a compromised peer is the operator's trust decision. (maintainer)

…and §14 Q9 is deleted. That's the whole transformation — tag flips, the answer's substance lands in the prose, question retires. A one-line "Q9: confirmed, no cross-link guarantee" from you produces exactly that edit on my end.

A few past models where this played out, if it helps to see the pattern:

• RAT-558: Add security threat model (THREAT_MODEL.md + SECURITY.md + AGENTS.md) creadur-rat#677 — Claudenw asked this exact question ("we answer questions and push the resulting file?"); the thread walked each item, and answered ones became (maintainer) (e.g. the archive-OOM gap, XXE hardening, the custom-matcher trust surface).
• Add threat model + security-model discoverability (AGENTS.md → SECURITY.md → THREAT_MODEL.md) helix#3148 — junkaixue confirmed a batch inline (helix-rest ships auth-less by default, ZK access is ZK-gated, gateway/agent are pluggable); all folded in as (maintainer) in one push.
• Add draft security threat model (THREAT_MODEL.md + SECURITY.md + AGENTS.md) drill#3052 — cgivre corrected an inferred call (the contrib/ plugins are in-scope, not out) and added a KNOWN-NON-FINDING for storage enumeration — a good example of the "correct / strike," not just "confirm," path.

No rush on any of it — one line per question whenever you have a moment is plenty. Happy to fold as they come in rather than waiting for all ten.