R5 · Security and threat model

Done 2026-10-26 · 30 findings: 2 blockers, 23 majors, 5 minors · 0 dropped · 8 questions for Thomas

What changed

• New review file: docs/reviews/R5-security.md. It holds:
  • the 30 findings SEC-101 to SEC-130, ranked by severity, each with its evidence (quoted passages), a risk rating, a proposal and Status: open;
  • a findings table with the trust boundary of each finding and the specs it touches;
  • 8 questions for Thomas;
  • 5 proposed spikes (sec-single-mode, sec-runner-confinement, sec-redaction-canary, sec-authz-matrix, sec-slurm-identity);
  • an appendix with the reviewer's outline for a future docs/specs/security-and-threat-model.md.
• No spec was edited. This is a review round (see the review rules in docs/reviews/README.md). The prompt asked for a draft threat-model spec; the step wrote only the outline in the appendix. Question 8 asks whether APPLY1 should create the spec from it.
• The file was committed on autopilot/integration in ad6bc9b, together with the other W1 review files, the nav entry and map.md.

Why

Spectio runs code on shared clusters as real Unix accounts, accepts events from engines, and lets people, service accounts and AI agents decide gates. Before any code, the design needs a threat model per trust boundary, and the places where tenancy can leak need to be named.

Prompt: next-phase.md · R5. It asks for STRIDE per trust boundary: browser, embeds, service accounts, runners, engine ingest, AI agents on gates, event bridges, plugins, backups, depictio trust, the co-hosting proxy and every sign-in method. It also asks for tenancy leaks through search, SSE, webhooks, exports, logs and the task ledger. The round runs as an autopilot step: decision log, 2026-10-26, autopilot.

Evidence

How the round ran (from the round's header in the review file):

Item	Value
Commit read	autopilot/integration at 3b209d3; every line number in the file refers to it
Reviewers	security-reviewer, one instance, with the whole design in scope. It returned a full report; none failed.
Read	every spec in docs/specs/, the decision log, decision 0001, and the research notes on depictio auth and harmonisation
Upstream code	read-only scratch clones: nextflow 114f1fe (secret masking in config, unmasked params in TowerObserver, publishDir default mode), nf-core/rnaseq 95dbcd9 (remote includeConfig), and the Slurm slurm.conf docs (PrivateData, AccountingStoreFlags=job_env)
Merge	IDs renumbered in rank order; the reviewer's draft IDs (d1nn) kept in the table's last column. Two sub-points removed as duplicates of R1 SR-002 and SR-024.
Merger's check	every quoted passage of every blocker and major was opened at 3b209d3. All reproduced, so 0 findings were dropped. External file:line claims were spot-checked in the clones.
Correction during the merge	nextflow's SECRET_KEYS is @deprecated in favour of StringUtils.isSensitiveName. Whether the two patterns match was not compared, and the file marks this [to be validated].
Earlier rounds	R8b (DEP-T-) and R12 (UX-) findings are cited, not repeated. Eight R1 findings are shared and kept, because R5 adds the attacker and the controls; each has a Related line so that both are triaged together.

Counts, checked against the file's headings:

$ for s in blocker major minor; do printf "%s " $s; grep -c "^### SEC-[0-9]* · $s ·" docs/reviews/R5-security.md; done
blocker 2
major 23
minor 5
$ grep -c '^| SEC-' docs/reviews/R5-security.md
30

These match the summary table in the file (total 30, dropped 0) and the merge summary returned by the step's workers (2 blockers, 23 majors, 5 minors, 0 dropped).

Exit criterion. R5 is done when its review file exists, so that TRIAGE1 can read it:

$ ls docs/reviews/R5-security.md
docs/reviews/R5-security.md

Figures and media

None required (review step).

Findings and open questions

The five findings that matter most (as ranked in the review file's summary):

1. SEC-101 · blocker: a runner's Unix account is not tied to the people who launch on it. On a group environment, any launcher, or any editor who adds a script: binding, runs code as a colleague's or an admin's cluster account. Related to R1 SR-014.
2. SEC-102 · blocker: single mode trusts 127.0.0.1. On an HPC login node, an MVP target, every other user can drive the owner's runs as the owner, and so can a web page through DNS rebinding. Same core problem as R1 SR-031, rated major there; R5 adds the browser path and rates it a blocker.
3. SEC-104 · major: there is no endpoint → action → scope → role matrix, so "every endpoint has a principal and a can()" cannot be built or tested. IDs in request bodies and plugin routes are the likely gaps.
4. SEC-113 · major: identities are linked by email across IdPs, including depictio, which cannot verify email. Group sync is not namespaced, so an IdP group named admin can lead to account takeover or admin rights.
5. SEC-115 · major: a server compromise means code execution on every runner's Unix account, because runners enforce no local policy. The file proposes a runner-side runner.toml that the runner enforces whatever the server says.

Questions for Thomas. The full wording is in the review file. In short:

#	Topic	Question
1	single mode on login nodes (SEC-102, R1 SR-031)	Keep it there, with a Unix socket, a local token, a Host allow-list and CSRF, or restrict it to laptops and service nodes?
2	Group clusters (SEC-101, R1 SR-014)	One runner per user, a service-node runner using slurmrestd with per-user JWTs, or a declared shared account with explicit delegation? Does the EMBL acceptable-use policy forbid shared accounts, and is slurmrestd with per-user JWTs available? [to be validated]
3	Project visibility (SEC-121, R1 SR-029)	Two values (private / instance), or split instance (signed-in users) from public (guests too)? Does depictio's is_public map to public?
4	depictio trust (SEC-120)	Should a depictio admin ever become a Spectio admin automatically (proposed: no)? Ask depictio for aud and a JWKS endpoint, or drop the audience test?
5	Co-hosting default (SEC-109, DEP-T-013)	Separate hosts with IdP SSO, or path co-hosting on one domain, which merges the two applications' trust domains?
6	Agent approvals (SEC-111)	Are the defaults acceptable: a 15-minute hold before an agent approval takes effect, and a 10 % cap on items an agent may exclude?
7	Plugins (SEC-124)	Accept that installed server plugins are as trusted as admins, and reword architecture §10 risk 2 to match?
8	Threat-model spec	Should /apply-findings R5-security create docs/specs/security-and-threat-model.md from the outline in the appendix?

Next. TRIAGE1 sorts these findings with the triage policy, together with the related R1 findings. It moves the questions it cannot settle to the inbox. APPLY1 then changes the specs and adds the decision-log entries.