V3 Journey Threat Model¶

This document models security and privacy threats for the v3 longitudinal Journey, from untrusted intake through release evidence. It is a design-level assessment of the repository implementation, not a claim of clinical validation, regulatory certification, deployment hardening, or safe autonomous patient-care use.

No confirmed vulnerability was identified while producing this document. The attacker stories below are hypotheses used to define controls and release evidence. Report a suspected bypass under the private security disclosure policy; never include real sensitive data.

1. Overview¶

Scope and review method¶

The in-scope system is the Journey path that receives source metadata and records, normalizes them into evidence-linked artifacts, coordinates ingestion, stores longitudinal state, protects reversible surrogate mappings, governs review and export, serves bounded resource pages, and produces the v3 release decision. Hosted infrastructure, an operator's identity provider, external object-store policy, and downstream clinical decisions are outside this repository-level review.

The architecture review was performed sequentially because an independent reviewer was not available in this work session. It should therefore be treated as first-party threat modeling and re-reviewed independently before a production security sign-off.

Component and source map¶

Effective resources¶

These are the resources that cross a trust boundary or materially affect a security decision. “Effective” means the data or authority actually consumed by the implementation, not merely a deployment diagram label.

Data flow and trust boundaries¶

flowchart LR
    U[Untrusted source] -->|metadata first| A[Archive and format preflight]
    A -->|allow| P[Bounded parser]
    A -->|quarantine or reject| Q[Quarantine ledger]
    P --> E[Evidence artifacts and locators]
    E --> S[Journey stores]
    S --> R[Human review and policy]
    R --> API[Bounded query and export surfaces]
    S --> D[Governed datasets]
    API --> G[Aggregate gate reports]
    D --> G
    G -->|digests plus Git binding| RG[Release gate]
    K[Operator signing key] --> RG
    RG --> O[Signed decision packet]

Boundary changes occur at untrusted intake, parser execution, evidence normalization, persistence, secret access, worker coordination, human review, query serving, export, and release signing. Promotion is a separate operational boundary: a valid packet does not authorize deployment.

2. Threat Model, Trust Boundaries, and Assumptions¶

Protected assets and security objectives¶

Protected assets include clinical source content; patient, encounter, and evidence identifiers; offsets and coordinates; correction and conflict history; consent and authorization policy; review decisions; model, vocabulary, and data artifacts; encryption and signing keys; governed dataset definitions; and release evidence.

The required objectives are:

• confidentiality: raw source values, vault material, credentials, and real patient data do not enter logs, metrics, traces, exceptions, fixtures, or release packets;
• integrity: evidence coordinates, provenance, review history, dataset custody, release inputs, Git identity, and signed decisions cannot change silently;
• availability: malformed or adversarial inputs cannot create unbounded archive, parsing, pagination, retry, or release-gate work;
• authorization: identity linkage, review, identified export, and serving remain constrained by purpose, role, consent, namespace, policy, and explicit human action;
• safety: ambiguity remains typed as unknown, conflict, unsupported, denied, or failure instead of being converted into a successful result.

Attacker starting capabilities¶

The model assumes an attacker may:

• submit malformed, oversized, recursive, misleadingly named, or internally inconsistent source metadata and files through an authorized intake surface;
• control ordinary request fields, pagination cursors, filters, and requested export fields, but not grant themselves a new role;
• replay previously observed requests, manifests, packets, or stale artifacts;
• replace or mutate files in a workspace they can already write, including a race between evidence review and release-gate execution;
• supply a malicious or incorrectly licensed model, dataset, tokenizer, vocabulary, or aggregate report when the release owner accepts that input;
• observe value-free error codes, counts, sizes, timing, and signed release packets available to their current role.

Attacker non-capabilities¶

Unless a specific story states otherwise, the attacker cannot:

• read process memory, a secret manager, the signing key, or the caller-owned vault key;
• modify the installed OpenMed code, trusted operating system, Git executable, or the release-gate process after it starts;
• bypass deployment authentication or storage ACLs outside this repository;
• forge SHA-256 preimages, HMAC-SHA256 signatures, or AES-SIV authentication;
• compel a human reviewer or release operator to approve a known blocker;
• turn a signed decision packet into deployment authority without a separate, deployment-specific promotion action.

Assumptions and open questions¶

The following assumptions are required and must be resolved by each deployment:

• The identity provider, tenant boundary, TLS termination, database ACLs, backups, and secret-manager policies are configured outside this library.
• The release operator controls the manifest, Git checkout, tag, signing key, and output directory. The gate cannot protect a host already controlled by the attacker.
• Upstream aggregate reports are honestly measured. The gate validates schema, freshness, consistency, and digest custody, not the truth of an instrumented benchmark it did not observe.
• External FHIR, OMOP, terminology, device, and implementation-guide validators remain necessary for the exact downstream environment.
• HMAC uses shared-secret trust. Environments that require verifier separation should wrap or replace it with an approved asymmetric signing service without weakening the packet contract.
• Synthetic fixtures and bounded evaluations cannot represent every language, institution, scanner, parser, device, workflow, or population.
• Authentication and policy adapters must fail closed when caller identity, consent, purpose, or role cannot be established.

3. Attack Surface, Mitigations, and Attacker Stories¶

The priorities below indicate review urgency, not confirmed findings. Every story is a hypothesis until reproduced against a supported version. A suspected privacy or integrity bypass must follow private disclosure rather than a public issue.

Release invariants and response¶

• Every mandatory gate appears exactly once and must report success.
• Critical leakage, invalid evidence, broken provenance, migration failures, non-idempotence, unresolved high-risk review, and high/critical security findings remain blockers.
• Critical and high exceptions cannot waive a blocker.
• Packets contain digests, counts, controlled codes, and bounded performance metadata, not clinical values or local frozen-input paths.
• Network access is unnecessary after explicitly requested assets are present.
• Restricted assets remain user supplied or isolated out of process.
• Signing establishes packet integrity; it does not establish clinical efficacy and does not authorize promotion.

On gate failure, preserve the signed NOT_READY packet and hashed aggregate reports under access control. Do not copy source values into an issue or log. Repair the underlying control, regenerate the affected evidence on the same or a new tagged candidate, and rerun the complete gate. Never edit a packet in place. See the v3 Journey release gate for the machine-readable contract.

4. Severity Calibration¶

Severity follows the repository policy: CVSS v4.0 where applicable plus a privacy-impact override. Privacy-impacting defects are never rated below High (SECURITY.md:103-115).

Security scope and private-reporting requirements are defined in SECURITY.md:64-88; concrete repository severity examples are defined in SECURITY.md:103-115. A release-gate NOT_READY result is not itself a vulnerability. Conversely, a READY result cannot downgrade a demonstrated security or privacy defect.