Add draft project security threat-model document

[potiuk]

Summary

This PR adds an initial draft of a project-level security
threat-model document (draft-THREAT-MODEL.md) so that automated
security scanners running against this repository have a
maintainer-facing reference for which classes of findings are
in-scope vs. out-of-scope for the project.

The document follows the rubric format used by several other ASF
projects piloting improved security-model discoverability for
agentic scanners. Every claim carries a provenance tag:

• (documented) — paraphrased from public artefacts (this repo or
  the project website), cited inline.
• (inferred) — synthesised from code structure or domain
  knowledge; the PMC has not confirmed.
• (maintainer) — confirmed by a Jackrabbit PMC member in response
  to this draft. (Zero in this initial draft.)

Draft stats:

• ~14 documented claims
• ~32 inferred claims (each maps to a §14 question)
• 24 open questions for maintainers in §14

§14 is the highest-leverage section: answering each question
either promotes one (inferred) tag to (maintainer) or corrects
the underlying claim.

Why "draft-" prefix?

The file is named draft-THREAT-MODEL.md rather than
SECURITY-THREAT-MODEL.md because this is a proposal for the
PMC to review — please correct, reject, or discuss as needed.
Once the PMC ratifies (or substantially edits) the content, the
file can be renamed in a follow-up PR and a discoverability
scaffold (AGENTS.md → SECURITY.md → the model) added so
scanners can mechanically follow the chain.

What this is, and what it is not

This is not a security audit. It is a working triage document
— the reference a triager holds against an inbound report to
decide whether the report is about a Jackrabbit vulnerability or
about caller misuse / operator misconfiguration / an out-of-scope
concern.

The draft was generated by an automated agentic security scan
being piloted by the ASF Security team; the discoverability work
is independent of any specific scan run.

How to review

1. §14 first. Each answer either confirms one (inferred) tag or
   replaces the inferred claim with the correct one.
2. After that, please skim §3 (out-of-scope) and §13 (triage
   dispositions) — those govern how a vulnerability report would
   be triaged.

Reply edits / corrections inline on the PR, or to the original
security@apache.org thread, whichever fits the PMC's workflow.

🤖 Generated with Claude Code

[potiuk]

Heads-up on the red SonarQube Analysis: this PR is documentation-only — it adds a draft threat-model document and touches no code — so the Sonar quality-gate / coverage result is unrelated to the change. Flagging so the red check isn't read as a defect in the PR.

[potiuk]

Note for reviewers: the failing Maven Build is a surefire test failure in jackrabbit-core, which this change cannot have caused — the PR only adds documentation/discoverability files (no code, build, or test changes). It appears pre-existing/flaky on the base branch; happy to rebase if a maintainer wants a fresh run.

[potiuk]

Quick note on CI: the red "Maven Build" isn't introduced by this change — it's a docs-only PR (the threat-model doc already carries the ASF license header), and the failure is in the full integration-testing build, unrelated to the added file. It shouldn't block review/merge. Happy to rebase for a clean run if useful.

[reschke]

@potiuk - Jackrabbit has removed RMI support in the current stable branch two years go (https://issues.apache.org/jira/browse/JCR-5042); it's only present in a maintenance branch (2.20.x) which we want to EOL in ca 6 months. Does it make sense to keep this in the document?

[potiuk]

Feel free to skip it.

[reschke]

So: remove & PR against your branch?

Or create a branch in Jackrabbit first and merge your PR?

[potiuk]

Thanks Julian — no need for you to do either. It's our branch, so I'll trim the RMI material from the doc myself (it's touched in a handful of sections, so cleaner in one pass) and push the update here. Since RMI is only in the 2.20.x maintenance line you're planning to EOL, I'll drop it from the in-scope model rather than caveat it. Once that's pushed it's ready for a PMC member to review and merge — I'll ping this thread when it's up.

[reschke]

yes, I'll review again, but getting out the RMI noise will make it shorter (somewhat)

[potiuk]

Pushed — the RMI content is out: dropped jackrabbit-jcr-rmi from the module inventory, the trust-boundary / entry-point / asset rows, the dedicated RMI-deserialisation finding and §9.5, the residual-risk / FAQ / non-goal bullets, and the two RMI-specific open questions (§14), and renumbered the rest with cross-references fixed (caccff5). It's ready for a PMC member to review and merge whenever you like. Thanks for the JCR-5042 catch — good to keep the model scoped to what's actually shipping.

[potiuk]

Still SonarQube "red" can't be fixed by me :)