AURORA's security posture is engineered, not asserted. Signed weights, hash-chained audit logs, mTLS-only federation, opt-in telemetry, reproducible builds, and a vulnerability-disclosure path with a 72-hour triage SLO. This page is the running specification.
AURORA is decision-support software handling consented clinical data inside hospital perimeters. The threat surface is asymmetric: a small number of high-impact failure modes, and a large number of low-impact ones. We name the high-impact ones explicitly.
A modified weights file that returns confident-looking but wrong predictions. Mitigated by Sigstore signature verification at load time; the runtime refuses to render unverified weights.
An attacker rewriting the override log to erase a clinician decision. Mitigated by hash-chained audit entries with per-site federation keys; chains are signed before the next render.
A malicious site exfiltrating data via the federation runtime. Mitigated by signed, rate-limited, schema-validated updates — gradients only, no record-level payloads ever leave a site.
A compromised dependency landing in an AURORA release. Mitigated by reproducible builds, pinned digests, SBOM published per release, and a 2-of-N maintainer sign-off on artefact promotion.
A clinician credential lifted from another system and used against AURORA. Mitigated by per-site OIDC binding, short-lived tokens, per-clinician identity in every audit entry.
An attacker reconstructing training data from model outputs. Mitigated by DP budgets per registry, output-rate limiting, and refusal-mode when input distribution drifts.
Combining outputs across cases to identify a patient. Mitigated by case-bound rendering, no cross-case batch APIs, and consent metadata that travels with records.
A privileged site operator running queries outside clinical purpose. Mitigated by role-bound consent policies enforced by the runtime, and an audit log the operator cannot rewrite.
What we do not claim to protect against. Physical access to a site's hardware, hospital-IT-level compromises that already own the EHR, nation-state adversaries with persistent on-prem footholds. These are real risks; they are not AURORA's threat surface and we will not pretend otherwise.
The supply chain is the substrate's most boring and most important property. AURORA's release pipeline is intentionally over-engineered: reproducible builds, hermetic CI, hardware-rooted signing keys, SBOM-per-release, and 2-of-N maintainer attestation on promotion.
rc to release requires signatures from two maintainers on different working groups. The promotion is itself a Rekor entry.latest tags are not used anywhere in the release path.If you are a security reviewer, the entry points are the public Rekor entries and the published SBOMs. If you are a pilot site, the runtime verifies all of this for you at install time — aurora doctor exits non-zero if any signature does not chain back to the public key.
The AURORA runtime makes minimal assumptions about its host. It runs as an unprivileged user, talks to the network only outbound, and refuses to operate without an audit-log sink it can write to.
Runs as UID 10000 by default. Drops every Linux capability except those required for GPU access (when present). No setuid binaries.
Container images mount read-only; writable paths are explicit tmpfs/PVC mounts. SELinux/AppArmor profiles published per release.
Federation requires only outbound mTLS. The runtime refuses to bind a public-facing inbound port unless the operator explicitly opts in.
PIE + RELRO + stack canaries on every binary. Rust crates compiled with overflow checks on; Python runs with -W error for DeprecationWarnings on security-sensitive paths.
Federation keys, OIDC client secrets and registry tokens live in Vault / KMS / HSM per site policy. The runtime fetches a short-lived bearer; secrets never land on disk in plaintext.
If the runtime cannot durably write the audit log, it refuses to render. Sinks supported: local disk, S3-compatible object store, Kafka, syslog. NDJSON over HTTPS is the default.
On signature verification failure, input-distribution drift, or DP budget exhaustion, modules enter refusal mode — they render the refusal and the reason, never a low-confidence prediction.
Per-clinician and per-cohort rate limits enforced by the runtime. Bulk queries against cohorts require a documented research-use token signed by the site's IRB delegate.
Federation is the most-asked-about security question. The short answer: there is no central data lake. Sites open outbound mTLS connections; the federation control plane orchestrates signed, rate-limited, schema-validated model updates.
The control plane is a transparency-log-backed service that records every round, every contributing site, every update hash and every validation outcome. Its source is open; its operator is the AURORA foundation; its log is independently mirrored. The control plane sees update metadata, not updates.
A model is only as trustworthy as the path from training to the GPU that loaded it. AURORA's model-integrity chain is verified at every step.
aurora replicate <run-id> command. Replications drift; the recipe tells you why.Data inside an AURORA deployment moves over TLS 1.3 only; data at rest is encrypted by the site's storage system; consent metadata travels with every record.
Inbound, outbound and intra-cluster traffic. TLS 1.2 is rejected; cipher suites limited to AEAD only.
AURORA does not impose its own encryption layer over the site's storage; it requires that the underlying volume is encrypted, and refuses to render if a volume's encryption status cannot be verified.
Every record carries a cohort policy. Subsystems with an explicit consent dependency refuse to run on records that lack matching policy.
PHI is processed inside the runtime; derived artefacts (signatures, hashes, audit entries) contain no PHI by construction.
Patient withdrawals propagate through cohort policies; the site's existing legal flow (GDPR Art. 17, HIPAA, India DPDP) is the binding mechanism, AURORA respects it.
AURORA's runtime is stateless; the data path is the site's. We do not back up patient data because we never have it.
AURORA runs a coordinated disclosure program with a 72-hour triage SLO. We thank researchers in releases and publish a CVE for every fix that warrants one. There is no bounty programme — we are a non-profit — but every disclosure gets a written acknowledgement and a named entry in the release notes.
security@aurora.health with a description, reproduction steps, and any artefacts. Encrypt with the PGP key in the page meta (0x A0F2 · 8C91 · 6E4B · D7A2); the unencrypted address is monitored but encrypted reports are preferred.Everything under github.com/aurora-collective at public alpha, plus the federation control plane, the website, and the published OCI / Helm / wheel artefacts. Out of scope: third-party services hosting our documentation (until they become first-party), social-engineering attacks against staff, and physical-security testing of pilot sites.
The incident-response playbook is public. It is not a marketing document; it is the document on-call engineers run.
The incident archive lives on the changelog; it is part of the public history of the project. We are not in the business of pretending nothing went wrong.
AURORA is research and decision-support infrastructure; specific clinical deployments are validated and submitted to regulators by the partner institutions. The substrate itself maintains the controls a deployment will need to inherit.