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:

• ~35 documented claims
• ~28 inferred claims (each maps to a §14 question)
• 28 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-Oak 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]

Thanks @mreutegg, @mbaedke, @reschke, @rishabhdaim — pushed a revision addressing the review:

• Runtime corrected to Java 17 (oak-parent/pom.xml; cites PR OAK-12235: fix Java version information in README #2927 / the README fix). — @mreutegg
• Trust boundary widened to "the JCR Session / Oak ContentSession API surface, including all immediately derived interfaces" (Workspace, QueryManager, ObservationManager, AccessControlManager, UserManager, …); XML import + SQL2/XPath parsing now in-model with a new property + entry-point rows (XXE = VALID); the JCR-API → Oak-API security-entity mapping is explicitly in scope. — @mbaedke
• Error messages: leaking the existence of an unauthorized path is acceptable; leaking the path itself is VALID. — @mbaedke
• oak-http + oak-run server (:8080) added to the component table; softened the "no network listener" wording so HTTP-surface findings aren't mis-triaged as host-only; aligned oak-standalone (under oak-examples/standalone) with §3. — @rishabhdaim
• Noted the shared Jackrabbit bundles used by both Filevault and Oak (commons lib, JCR/SPI, oak-run/upgrade) + the OAK-12235: fix Java version information in README #2927 cross-reference. — @reschke

On TarMK: @mbaedke flagged it as entirely Oak's responsibility (in-model) while @reschke was unsure — so rather than pick a side I've kept TarMK in-scope with an open §14 question (Q2a) for the PMC to settle. Same for the XXE default-config question (Q1a). Pushback welcome on either.

[potiuk]

Note for reviewers: the failing Maven Build is a single test failure (DataStoreCommandTest, 1 of 62) in oak-run — unrelated to this PR, which only adds documentation/discoverability files (no code or build changes). Appears pre-existing/flaky on the base branch; happy to rebase for a fresh run.

[potiuk]

Thanks @mbaedke, @reschke, @mreutegg, @rishabhdaim — all 11 points are folded; resolving the threads now. Highlights:

• TarMK / oak-segment-tar is now in-scope as Oak's own code — a malformed-segment / tar-format parsing bug is an Oak finding, not a "trusted backend" issue (§2 component table, §3, §6). mbaedke's position is folded; reschke's uncertainty is kept as an explicit open item (§14 Q2a) for the PMC to settle.
• oak-http / oak-run server (:8080) added as in-model HTTP entry points; the "Oak ships no listener" wording is softened so request-parsing/path/response bugs aren't mis-triaged as host-only (§2 table, §3).
• XXE / XML / SQL2-XPath parsing is in-model via Workspace.importXML / Session.importXML and the document/system-view importers (§3/§6).
• JCR-API → Oak-API security-entity mapping (Privilege/Principal/Authorizable) is in-model — a mis-mapping is a finding (§6).
• Trust boundary stated explicitly as the JCR Session / Oak ContentSession API surface (§4).
• Error-leak distinction (§9.5): leaking the existence of unauthorized paths is disclaimed; leaking the paths is not.
• Java 17 at HEAD (README outdated, OAK-12235: fix Java version information in README #2927 fixes it); shared Jackrabbit bundles spanning Filevault/Oak noted.

The one genuinely-open item is the TarMK in-scope question (mbaedke ↔ reschke, §14 Q2a). The model is the PMC's to merge whenever — thanks for the thorough multi-reviewer pass.