[CALCITE-7605] Add threat model

[rubenada]

Jira Link

[CALCITE-7605] Add threat model

Changes Proposed

Add security threat model.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rubenada]

@vlsi I have tried to combine here the initial drafts that we discussed on the email thread.
Should we ping someone from Apache security to help us out?

[xiedeyantu]

Appreciate you driving this! It looks reviewed based on the emails—should we finish it up?

[rubenada]

@potiuk , if you have a bit of time, could you please take a quick look at this draft? Thanks!

[vlsi]

I opened #5115 as an alternative draft for the same Jira.

It reorganizes the same normative content (attacker model, P1–P4, the class-loading rule, DoS goals) rather than replacing it, and makes two structural changes I found easier to review as a whole diff than as inline comments here:

• the concrete class-loading sinks move to a separate living document, so a new CVE updates that inventory and not the ratified model;
• the STRIDE table and the ASCII diagram are dropped — the reasoning is in the PR description.

This isn't meant to compete with your PR. Whichever framing the PMC prefers, I'm happy to fold the pieces back into #5020 instead. Interested in your take.

[rubenada]

Thanks @vlsi ! No problem at all. I'm happy to move this forward with your PR.

[potiuk]

Sorry for missing it before - looking at it now !

[potiuk]

Thanks @rubenada for driving this and combining the initial drafts. I read both this and #5115 against the threat-model rubric — the normative core (attacker model, P1–P4, the surprising-vs-unsurprising class-loading rule) is the same in both, and #5115 consolidates it a bit tighter: it drops the STRIDE table (which carried a couple of internal tensions — pushed-down SQL injection framed as both in- and out-of-scope, and the Janino/UDF row describing the boundary as input-sanitization rather than the actual class-loading gate), reframes DoS as a hardening goal rather than per-report vulnerabilities, and splits the concrete sink list into a separate living doc.

Since you've already offered to move forward with @vlsi's #5115, that reads as the right call to me too — so this one can probably be closed in favor of #5115. I've layered three additive suggestions on top of #5115 — an inputs table, a downstream-responsibilities section, and a closed triage-disposition set — in vlsi#3, for you both to take or leave.

Thanks again for pushing this forward — the model's in good shape.

[rubenada]

Thanks @vlsi and @potiuk for the suggestions.
As agreed, closing this in favor of #5115