Skip to content

Add threat model + security-model discoverability (AGENTS.md → SECURITY.md → THREAT_MODEL.md)#7214

Open
potiuk wants to merge 3 commits into
apache:mainfrom
potiuk:asf-security/threat-model-2026-06-01
Open

Add threat model + security-model discoverability (AGENTS.md → SECURITY.md → THREAT_MODEL.md)#7214
potiuk wants to merge 3 commits into
apache:mainfrom
potiuk:asf-security/threat-model-2026-06-01

Conversation

@potiuk

@potiuk potiuk commented Jun 1, 2026

Copy link
Copy Markdown
Member

Add a threat model + security-model discoverability for Apache Hop

This PR adds an initial threat model for apache/hop and wires up the
standard discoverability chain so automated security tooling can mechanically
find it:

  • THREAT_MODEL.md — a v1 draft threat model authored by the ASF Security
    Team for the Hop PMC to review.
  • SECURITY.md — points reporters at the threat model and the ASF security
    reporting process.
  • AGENTS.md — a Security section linking SECURITY.md → THREAT_MODEL.md
    so an automated reviewer can follow the chain.

Please read this as a proposal to react to, not a finished document

Following up on the mailing-list thread (thanks @hansva for the go-ahead to
make the initial files): this is a first draft built from public artefacts
only
— the README and the repository structure. Almost every security
claim is tagged *(inferred)* and has a matching open question in §14.
The PMC is the decision-maker; please correct, reject, or refine any of
it.

The highest-value things to confirm or correct (all in §14):

  1. Hop Server auth posture (Q5) — the crux. What is the default auth on
    the remote-execution REST/web surface? Can a default deployment accept
    unauthenticated remote run requests, or is auth required / is it bound to
    localhost by default?
  2. Trust framing (Q1, Q2) — that Hop runs operator-authored pipelines
    (incl. scripting/exec steps) by design and is not a sandbox; the pipeline
    author + operator are trusted.
  3. Out-of-scope set (Q3) — website, tests/samples, and bundled third-party
    driver/dependency CVEs.
  4. Recurring non-findings (Q18a) — what do scanners most often report
    that you consider non-findings? (e.g. the scripting/exec transforms.)

The point of the model is to let a triager (or an automated scan) classify an
inbound finding as valid / out-of-model / disclaimed-by-design and cite a
section — and to cut false-positive noise (the §11a known-non-findings list
especially).

This is part of an automated agentic security-scan pilot the ASF Security team
is running; a discoverable threat model lets the scan focus on real issues and
suppress the by-design ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant