security-model.adoc: draft additions for adversary model, known non-findings, triage dispositions

[potiuk]

This is a proposal for the PMC to review — please correct, reject, or
discuss as needed. The additions below are a draft; every claim
carries a provenance tag (*(documented)*, *(maintainer)*, or
*(inferred)*) and all *(inferred)* items are collected in a new
"Open Questions for the PMC" section at the bottom so they can be
explicitly confirmed, corrected, or rejected before this is
considered ready.

Context

The ASF Security team is piloting an automated agentic security
scan with PMCs who have opted in. Apache Shiro is one of the
opted-in PMCs (thread on private@shiro.apache.org, Lenny Primak
confirming).

Pre-flight review of the existing security model document showed
substantive coverage of authentication, authorization, session
management, cryptography, web security, and operator
responsibilities. The four sections this PR adds are the
ones the scan rubric expects but that the existing document
either does not address explicitly or addresses only implicitly:

1. == Adversary Model — names the in-scope adversary
   classes (external untrusted network user; authenticated
   low-privilege user) and explicitly lists what's out of
   scope (the application code itself, administrators with
   configuration access, local-shell / co-tenant adversaries,
   compromised realms). This section cross-references the
   existing Trust Boundaries section rather than restating it.

2. == Known Non-Findings — recurring report categories
   that the PMC has already decided are not vulnerabilities
   under the model. Seven categories were lifted from the
   existing document (default username-enumeration behavior,
   username / session-ID appearance in logs, version
   disclosure, deprecated-hash exposure in the API,
   RememberMe's weaker guarantees, pluggable-crypto allowing
   weak operator configurations, omissions of CSRF / MFA /
   account-lockout). Each is linked back to the section that
   licenses the classification.

3. == Triage Dispositions — a closed set of outcomes
   triagers can pick when handling an inbound report:
   VALID, VALID-HARDENING, OUT-OF-MODEL:*,
   BY-DESIGN:property-disclaimed, KNOWN-NON-FINDING,
   MODEL-GAP. Every cell in the table cross-references
   the section of the model that licenses the call, so the
   reply to a reporter can say "see <<known_non_findings>>"
   rather than ad-hoc prose.

4. == Open Questions for the PMC — temporary section
   collecting every *(inferred)* tag elsewhere in the
   document. When the PMC confirms or corrects each item,
   the corresponding tag is promoted to *(maintainer)*
   and this section is removed.

Why these additions and not others

The rubric the team uses is published at
https://gist.github.com/potiuk/da14a826283038ddfe38cc9fe6310573.
That gist enumerates roughly a dozen subsections a thorough
threat model is expected to cover. For Shiro, the
existing document already covered most of them substantively
— what was missing (or only implicit) were the four sections
above. Other rubric subsections that are already adequately
covered (§4.2 Architecture via the existing Overview and
Trust Boundaries; §4.3 Trust Boundaries itself;
§4.6 Authentication, §4.7 Authorization,
§4.10 Cryptography, §4.12 Operational guidance, etc.)
are not changed by this PR.

What this PR does not claim

• It does not claim to be authoritative. The PMC is.
  Every *(inferred)* tag is a hypothesis we'd like the
  PMC to confirm or correct.
• It does not change any normative behavior. This is a
  documentation-only PR against src/site/content/security-model.adoc.
• It does not address discoverability. A separate PR
  against apache/shiro adds the discoverability pointers
  (AGENTS.md + SECURITY.md) the scan rubric also expects.

How to review

1. Read the Open Questions for the PMC section first.
   Anything you can answer there moves an *(inferred)* tag
   to *(maintainer)* in the body and removes one bullet
   from Open Questions.
2. Reject anything that's wrong. If a "Known Non-Finding"
   shouldn't be in that category, say so — the framing here
   is the PMC's call, not ours.
3. Add anything missing. Categories of report Shiro
   has seen repeatedly that aren't in the Known Non-Findings
   table belong there too — we surveyed the existing
   document but didn't survey the historical security-report
   archive.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.7), used by the ASF Security
  team to draft the proposed additions against the
  rubric linked above. All content was reviewed by a
  human before submission.

Generated-by: Claude Code (Opus 4.7)