Add security threat model (THREAT_MODEL.md + SECURITY.md + AGENTS.md security section)#4522
Add security threat model (THREAT_MODEL.md + SECURITY.md + AGENTS.md security section)#4522potiuk wants to merge 3 commits into
Conversation
Adds a threat model for Apache Solr, drafted at the Solr PMC's request following the Apache Security team's threat-model rubric. Adds THREAT_MODEL.md and a new SECURITY.md (ASF disclosure pointer), and appends a ## Security section to the existing AGENTS.md wiring AGENTS.md -> SECURITY.md -> THREAT_MODEL.md (the rest of AGENTS.md is preserved). The model is built around Solr's deployment contract — a search server meant to run in a trusted environment with auth+authz enabled, never exposed unauthenticated to an untrusted network. It treats the admin/config/package APIs as powerful-by-design (authz-restricted), bounds SSRF via shards/streaming by operator network controls, and keeps code-execution-adjacent features as off-by-default. DRAFT for PMC review: section 14 carries open questions (notably the trusted-environment ruling and the risky-feature toggles). Scope: apache/solr; solr-sandbox out of scope; solr-operator/solr-mcp pending a scope confirmation. Generated-by: Claude Opus 4.8 (1M context)
| For security findings, follow the project's threat model: | ||
| [THREAT_MODEL.md](THREAT_MODEL.md) — the trust boundaries, the load-bearing | ||
| auth+authz / trusted-environment posture, the properties Solr provides vs. those | ||
| left to the operator (notably: never expose an unauthenticated Solr to an |
There was a problem hiding this comment.
Also worth to mention as a strong recommendation:
- Never expose Solr in a public-facing network zone / DMZ. Keep it in a firewalled zone as you do with your databases
- Always enable TLS/SSL to avoid leaking of sensitive data or auth credentials
Don't know where in the model to include these, the "never expose an unauthenticated solr to an untrusted network" phrase is repeated several times in this doc.
| Apache Solr follows the Apache Software Foundation security process. Report | ||
| suspected vulnerabilities **privately** to the ASF Security Team at | ||
| [security@apache.org](mailto:security@apache.org) (the Solr PMC is reachable via | ||
| `private@solr.apache.org`). Do **not** open public issues or pull requests for |
There was a problem hiding this comment.
For security purposes, let's mention they can reach out to the Solr PMC security group at security@solr.apache.org.
Should we just copy this content from https://solr.apache.org/security-reporting.html ?
Review feedback from janhoy + anshumg on apache#4522: §10 gains explicit "never expose in a public-facing zone / DMZ" and "always enable TLS/SSL" operator bullets; §1 reporting line names the Solr PMC security group (security@solr.apache.org) + security-reporting.html. Generated-by: Claude Opus 4.8 (1M context)
|
Thanks @janhoy @anshumg — folded all three in: |
3 participants
What
Adds a threat model for Apache Solr, drafted at the Solr PMC's request (the GLASSWING / Mythos scan pre-flight needs a discoverable threat model):
THREAT_MODEL.md— the model (rubric).SECURITY.md— new (ASF disclosure pointer + threat-model reference).AGENTS.md— your existing coding-agent file, preserved, with a## Securitysection appended wiringAGENTS.md -> SECURITY.md -> THREAT_MODEL.md.The model in brief
Built around Solr's deployment contract: a search server meant to run in a trusted environment with authentication + authorization enabled — never exposed unauthenticated to an untrusted network. The admin/config/package APIs are powerful-by-design and must be authz-restricted; SSRF via
shards/streaming is bounded by operator network controls; code-execution-adjacent features (Velocity/scripting, remote streaming) are off-by-default. So scanner/AI reports against "the admin API can change config / unauthenticated instance is dangerous / SSRF via shards" route to the right disposition rather than churning.DRAFT — you own and merge it
The (inferred) trust assumptions are gathered as open questions in section 14; the load-bearing ones are Q-trustenv (confirm the trusted-environment posture so unauthenticated-exposure findings are out-of-model) and Q-features (which risky toggles, when enabled, keep a finding
VALIDvs make itnon-default-build). Please edit freely.Scope note: modelled for
apache/solr;solr-sandboxplaced out of scope (experimental);solr-operator/solr-mcpflagged for a scope confirmation (section 14 Q-scope).Generated by the ASF Security team's threat-model tooling (Claude Opus); reviewed before opening.