[CALCITE-7674] Add Avatica threat model

[rubenada]

CALCITE-7674 Add Avatica threat model

[potiuk]

Reviewed this against the rubric we use for scanner-facing models. Short version: it passes comfortably, and it's stronger than most first drafts we see — including several we've written ourselves. Every section a scanning agent depends on is present and substantive: scope and the Calcite boundary split, attacker profiles, the P1–P5 properties, always/never-a-vulnerability lists, downstream responsibilities, and triage dispositions.

Three things I'd single out as unusually good, because they're the parts that actually change triage outcomes:

• The Inputs table maps every input to a governing rule and then closes the set — "A report that reaches a sink not covered here is a model gap." That catch-all is what stops the table going stale silently.
• Model gap is a disposition with a feedback loop — escalate, rule, then update this document so the next report of its kind is no longer a gap. Most models stop at the escalation.
• The DoS section is honest about missing controls rather than overclaiming, and pairs with a Known limitation disposition instead of pretending the bound exists.

Five things worth your judgement, roughly in order of value:

1. Does this model cover apache/calcite-avatica-go? (substantive — the one I'd most want answered)

The model is JVM-centric throughout: P1 says "client JVM", the assets list has "The Avatica client's JVM", and the class-loading sections are Class.forName / asSubclass. The Go client speaks the same wire protocol from a completely different codebase, where none of that applies. Right now a Go-client finding lands as Model gap by default. One sentence either way — "this model covers the Java server and JDBC driver; the Go client is not covered" or "…and applies to the Go client except where it names JVM mechanisms" — closes it before the first report rather than after.

2. "Always a vulnerability" #7 vs the DoS section.

Item 7 says single-frame resource exhaustion is a vulnerability; the DoS section says treat those gaps as known limitations not per-report vulnerabilities until controls land. Known limitation in the dispositions reconciles them, but a reporter reading item 7 alone will expect Valid and feel bait-and-switched. A clause on item 7 — "except where Denial of service records the bound as not yet landed" — makes the two agree on the page.

3. SECURITY.md link text points at a file that doesn't exist.

[THREAT_MODEL.md](site/_docs/security_threat_model.md) — the path is right, the label names a non-existent THREAT_MODEL.md. Cosmetic, but the label is what a human follows.

4. The CVE-2020-13955 entry doesn't state its rule.

The section says these are recorded "as ground truth for the rule they establish", and CVE-2022-36364 does exactly that — it grounds the surprising-class-loading rule. The 2020 entry currently reads "a Calcite Avatica issue in an earlier release", which establishes nothing. I've deliberately not guessed what it was; you'll know whether it grounds a rule already in the model or should just be dropped.

5. Status: draft for PMC discussion; not yet ratified — worth flipping when this merges, so the merged document doesn't describe itself as unratified.

None of these block anything. Happy to push any of them as commits on this branch if that's easier than doing it yourself — your call, it's your PR.

[rubenada]

Thanks a lot for the review @potiuk !
Regarding your comments:

1. This model does not cover apache/calcite-avatica-go, Avatica-go would require its own model, and for the moment this is out of the scope.
2. I've added your proposed clause, please take a look.
3. Well spotted. Fixed.
4. I double checked, and actually that CVE was related to Calcite, not Avatica, so I've removed it.
5. I've removed that "status" mention, so that it's ready when we decide to merge this; but I'd like to have at least one other PMC approval.

[potiuk]

Re-reviewed at dd8b90c3. Four of the five landed cleanly:

• 2 — item 7 now carries the exception and the see-also; the two
  sections agree on the page.
• 3 — link label fixed.
• 4 — CVE-2020-13955 dropped, and CVE-2022-36364 still grounds
  its rule. Removing it was the right call over inventing a rule for it.
• 5 — status line gone.

1 is the one still open, and I'd argue for one more commit rather
than leaving it. You've answered it here — the Go client is out of
scope — but the answer is in the PR thread, not in the document. The
point of the question was that whoever reads this model in six months
won't have this thread; they'll have a JVM-centric document that says
nothing about the Go client, and a Go-client report will land as
Model gap by default. One sentence turns that into a clean
out-of-scope call at the moment it's needed.

Suggested wording, closing the opening paragraph:

This model covers the Java server and the Java (JDBC) client in this
repository. apache/calcite-avatica-go
is a separate implementation that speaks the same wire protocol; it
is not covered here and would need its own model.

Happy to push that as a commit on the branch if it's easier — your
call, it's your PR.

Otherwise this is good from my side, and agreed on wanting a second
PMC pair of eyes before merge.

[rubenada]

1 is the one still open...

Sorry, @potiuk , I misunderstood your remark (I thought you just needed a confirmation about the scope of the model). I understand now that it makes sense to mention that explicitly on the model itself. I have just committed your suggestion. Thanks.