Add security threat model (THREAT_MODEL.md) + SECURITY.md and AGENTS.md discoverability

[potiuk]

This adds a v0 security threat model + discoverability wiring to apache/streampipes, produced by the ASF Security team for the StreamPipes PMC to review and own — the pre-flight step for the Glasswing security scan the PMC opted into (path 3).

What's here

• THREAT_MODEL.md (new) — a v0 model (Michael Scovetta rubric, run with Claude Opus) covering the streampipes-rest front door, the external-data ingestion boundary at the adapters, and the extension runtime (custom adapters/processors/sinks as code-execution by design): trust boundaries, in/out-of-scope adversaries, what StreamPipes upholds vs. what it leaves to the operator (TLS, network isolation, extension vetting, source trust), known non-findings, and triage dispositions. Every non-trivial claim is provenance-tagged (documented) / (maintainer) / (inferred).
• SECURITY.md (new) — private reporting via security@streampipes.apache.org + a pointer to the model.
• AGENTS.md (amended) — appends a ## Security section to your existing root AGENTS.md, wiring AGENTS.md → SECURITY.md → THREAT_MODEL.md (your existing guidance is untouched).

How to engage — this is a draft to react to. THREAT_MODEL.md §14 collects open questions in waves; the highest-leverage one is Q2 — the ingestion boundary: what StreamPipes guarantees about handling hostile data from an external source an adapter connects to. Answer inline a few at a time, correct anything wrong, and the model becomes the PMC's. Once you're happy, we queue the scan in OSS-criticality order. No deadline pressure with the Mythos 5 window being extended.

Generated-by: Claude Opus 4.8 (1M context)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a security policy and initial threat model documentation, and wires both into the repository’s agent guidance to standardize vulnerability reporting and triage.

Changes:

• Added SECURITY.md with private reporting guidance and links to the threat model.
• Added THREAT_MODEL.md (v0 draft) defining scope, trust boundaries, and triage dispositions.
• Updated AGENTS.md with a Security section pointing contributors/triagers to the new docs.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
THREAT_MODEL.md	Introduces a draft threat model, boundaries, and triage taxonomy
SECURITY.md	Adds vulnerability reporting instructions and references threat model
AGENTS.md	Adds security workflow steps and links to the new security docs

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[obermeier]

I think it doesn't apply to this specific table.

[potiuk]

Thanks @obermeier — agreed on the table comments; the || rows render correctly and are intentional in those two tables, so I've left them as-is.

On Copilot's other points: the §11a numbering is deliberate — it mirrors the threat-model rubric's section scheme (11a is a distinct "known non-findings" subsection), and it's consistent with the other project models we've produced, so I've kept it.

I did take the timeless-wording point on §14.13 — reworded so it no longer references "this PR adds them" (just pushed). The rest of the Copilot comments are outdated against the current revision.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

[obermeier]

I did some adjustments in THREAT_MODEL to be more SP-specific and tried to answer the provided questions. What do you think about it?

[potiuk]

@obermeier this is great — thank you for taking it over and making it
genuinely StreamPipes-specific. It now reads as StreamPipes' own model rather
than a generic draft, which is exactly the outcome we're after.

A few things I especially like:

• §9 (known non-findings) is the highest-leverage section for keeping an
  automated scan's noise down, and yours is excellent. The GraalJS distinction
  — installed JAR extensions are trusted code (BY-DESIGN), but a break of the
  SandboxPolicy.CONSTRAINED + HostAccess.CONSTRAINED script boundary is
  in-model and VALID — is exactly the nuance a scanner needs spelled out. Same
  for the WRITE_ADAPTER / ROLE_CONNECT_ADMIN framing on the SSRF case and the
  non-sensitive asset allowlist.
• Your refinement on default credentials — not auto-dismissing a
  production-reachable fresh install that accepts shipped bootstrap creds as
  out-of-model unless there are real safeguards — is a good, conservative call.
• The JAR-vs-JS-sandbox split in §7 is clear and correct.

From our side it clears the completeness bar comfortably: scope/assets, the
adversary model, trust boundaries + data flow, properties upheld and
disclaimed, operator responsibilities, known non-findings, and the triage
dispositions are all substantive — and the AGENTS.md -> SECURITY.md ->
THREAT_MODEL.md discovery chain resolves cleanly.

No changes requested on my end. Merge whenever you're happy with it; once it
lands I'll follow up over the private thread with next steps. Thanks again for
the thorough pass.