Confidentiality
A connected service can receive only the answers or fields configured for it. Source access should use a read-only account limited to the records and fields the deployment needs.
Security
What the security model covers, and what remains your responsibility.
A Registry Stack deployment reads the source data and uses the credentials and signing keys configured by its operator. It is therefore a sensitive infrastructure component. This page explains the controls in the software, the risks those controls address, and the security work required from the operating team.
Security properties
How Registry Stack addresses confidentiality, integrity, availability, and auditability.
These properties depend on both the software controls and how the deployment is configured and operated.
Integrity
Evidence Gateway assertions are signed, audience-bound, and time-limited. Registry consultation is read-only, so Registry Stack does not change the source record.
Availability
Each registry can run its own deployment without relying on an Aubex-hosted service to answer requests. Availability still depends on the operator and the connected source system.
Auditability
Evidence Gateway records authorized access before a source read and records disclosure before releasing a signed answer. Relay also records protected reads. Retention and independent review remain operator responsibilities.
A deployment holds the read-only source credential, signing keys used for configured Evidence responses, and secrets used for audit integrity and subject pseudonyms. These secrets stay in the operator’s secret management system and are not held by Aubex. Audit records can themselves reveal sensitive activity and need access controls and protected retention. The operator also provides TLS and protects the source records at rest.
Deployment access
What a Registry Stack deployment can access.
A deployment sits between a public or partner service and a registry source. Its source account and network access should be limited to the data required for the configured questions and fields.
What a deployment can reach
- The source fields and records you connect it to, within the scope you configure.
- The credentials you give it to read that source.
- The audit log it writes about the requests it handles.
What it is built not to do
- Act as a data warehouse: it reads to answer and returns a minimized result, not a bulk export.
- Return more to a connected service than the configured scope allows.
- Write back to, or change, the source system; source connections are read-only.
- Send records or audit logs to Aubex: you self-host, and those data stay in your environment.
Limiting exposure
Controls that limit the impact of a flaw or compromised deployment.
No control makes a breach impossible. These controls limit what the deployment can reach, isolate registries from each other, and help operators detect misuse.
- Least-privilege source access: a read-only account scoped to only the fields and records the deployment needs, so even a full compromise is limited to what that account can read.
- One deployment per registry, in that registry’s own environment, so there is no central pool a single breach could drain.
- Defense in depth: authentication, authorization, predefined questions, and field limits are separate, checked layers, so one misconfiguration is less likely to expose everything.
- Network isolation, secret management, and off-host audit retention, run by the operator, keep the host’s reachable surface and its credentials contained.
- Fail-closed configuration: validation runs at startup, so a malformed grant or an invalid key usage fails loudly before serving, and scopes and field limits are explicit configuration a reviewer can read.
Threat model
Threats addressed by the controls, and risks that remain.
A useful threat model is explicit about both sides. The size of any exposure depends on how narrowly the source account is scoped and how well the host is run.
What the model defends against
- Eavesdropping or tampering in transit: requests and responses travel over operator-provided TLS, and Evidence Gateway assertions are signed for independent verification.
- A connected service reaching beyond its authority: each product checks its own configured authorization boundary on every request.
- A forged, altered, or stale assertion: verifiers check the signature, trusted issuer, audience, purpose, validity, and retained request expectations before use.
- A stolen service access token: short lifetimes, narrow authority, rate limits, and per-request checks reduce what it can reach, while the audit trail records its use.
- Misuse that has to be caught after the fact: hash-chained audit records show who asked what, and what was answered, when the operator retains them in protected storage.
What is out of scope
- A compromised connected service can still use the legitimate scope it was granted. If that grant is broad, it can collect many allowed answers, so grants need to stay narrow and revocable.
- An attacker with arbitrary, ongoing control of the host can reach the source data the deployment is configured to read, the credentials it holds, and its audit log. Least-privilege scoping bounds what that is, but cannot remove it.
- The security of the source system itself stays with the team that runs it.
- Establishing who a person is stays with the foundational identity layer.
- Whether a request is lawful stays an institutional and legal decision.
- Hardening the hosting environment stays with the operator who runs the deployment.
Shared responsibility
How security responsibilities are divided.
Registry Stack provides software controls and security documentation. The operator is responsible for the infrastructure, source permissions, secrets, monitoring, and institutional policy used in production.
Registry Stack provides
- Open-source software designed for read-only registry consultation and hardened deployment.
- Signed release assets with checksums, image digests, software bill of materials (SBOM) files, vulnerability scan reports, and a signed release capsule, plus published security and audit contracts and local validation tools.
- A hardening checklist in the docs and a coordinated-disclosure process.
You operate
- A least-privilege, read-only source account scoped to only what the service needs.
- Hosting hardening, network isolation, TLS termination, secret management, and patching.
- Monitoring, key rotation, audit-log protection, and incident response for the deployment.
- The legal authority and the policy for who may ask, and for what purpose.
Signed assertions
Authorization, signing, and limited validity.
Evidence Gateway returns one stateless assertion. The service checks authority before source access, signs the answer, and gives it an explicit validity window.
Authority is checked before source access
Evidence Gateway authenticates the requester and authorizes the complete predefined request before it acquires source credentials or reads the registry.
Signing keys rotate without invalidating current answers
The operator rotates the active signing key and keeps retired public keys available long enough for assertions that are still within their validity window.
Assertions expire rather than entering a lifecycle
An Evidence assertion is stateless and time-limited. There is no issuance session, status list, or revocation service; relying services reject it after its validity window.
Review the implementation
Review the software and release evidence before deployment.
The components are open source and self-hosted. Your team and auditors can inspect the source, verify a release, and test the deployment with synthetic data.
Try the live demo on synthetic data → Verify a release →- The products are open source, so your team and your auditors can review exactly what runs.
- Keyless cosign signatures, checksums, SBOM files, and release-level SLSA provenance (a supply-chain integrity attestation) for tag-triggered releases let you confirm what you deploy.
- Product-specific checks validate Relay projects and Evidence bundles before the service starts.
- You can run the whole flow in the hosted lab on synthetic data before any real record is touched.
- Security model
- Security self-assessment
- OpenSSF evidence
- GitHub releases
Coordinated disclosure
Found a security issue? Tell us privately first.
If you find a vulnerability, please report it through GitHub private vulnerability reporting so it can be fixed before it is public. Do not open a public issue for a security report. We will acknowledge your report and work with you on a coordinated disclosure.
Registry Stack’s security posture is verifiable rather than certified: releases ship signed, with checksums and SBOMs, the detailed threat model lives in the docs, and a pilot includes a security review against your own requirements. Audit-log retention periods and data-subject access or erasure over audit records are deployment policy decisions, set by the operating institution and reviewed during a pilot’s security review.