Confidentiality
A caller receives the minimum that answers its question, a fact, a status, or a credential, never a bulk export and never fields outside the scope you grant it.
Security
What Registry Stack protects, and what it cannot.
To answer a question, a deployment reads from your source, within the scope you configure. That makes it a sensitive part of your infrastructure, not a neutral pipe. This is the security model: the properties it protects, what a deployment can reach, the threat model in scope and out, and how security is shared with your team.
What the model protects
Four properties, and the mechanism behind each.
A security model is clearest when it says what it is protecting and how. These are the four properties a deployment is built to hold, with the mechanism that delivers each.
Integrity
Configured credential and signed-response surfaces are time-bounded, so a verifier can detect a forged, altered, or stale proof. The consultation path is read-only, so the source is never changed.
Availability
Each registry runs its own deployment in its own environment, with no dependency on the project to serve a request, so there is no shared service whose outage takes everyone down.
Auditability
Trust-critical requests are written as hash-chained audit records, so retained logs can reconstruct what was asked and what was answered. Stronger integrity depends on operator-owned append-only storage or anchoring.
A deployment holds two secrets: the read-only credential it uses to reach the source, and the key used for configured signed-response or credential surfaces. Both live in your secret management, never with the project. Traffic is protected by TLS that you terminate, and the source records at rest stay in the systems you already run.
The trust boundary
Where Registry Stack sits, and what it can touch.
A deployment is a trusted intermediary between a caller and a source. It has to read the source to produce an answer, so the security work is to keep what it can reach narrow, and to run it where it can be defended.
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 caller than the configured scope allows.
- Write back to, or change, the source system; the consultation path is read-only.
- Send records or audit logs to the project: you self-host, and those data stay in your environment.
Bounding the blast radius
The controls that limit what a flaw or a breach can reach.
No control makes a breach impossible. Together they keep the reachable surface small, contain a compromise to a single registry, and make misuse detectable after the fact.
- Least-privilege source access: a read-only account scoped to only the fields and records the deployment needs, so even a full compromise is bounded by 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, scopes, and field limits are separate, checked layers, so one misconfiguration is less likely to expose everything.
- Network isolation and secret management, run by the operator, keep the host’s reachable surface and its credentials contained.
Threat model
What the model defends against, and what it does not.
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 with a proof in transit: configured signed-response and credential surfaces are verifiable and carried over TLS.
- A caller reaching beyond its granted scope: authentication, scopes, and field limits are checked on every request.
- A forged or replayed proof: signed-response and credential surfaces use signatures and short lifetimes to make a fake or stale proof fail verification.
- A stolen credential used from outside: scoped, rotatable credentials and per-request checks limit it, and 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 caller 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
Security is a job we split with your team.
The project ships software that can be operated securely. Running it safely in production depends on the deployment, the same way it would for any infrastructure you self-host.
The project provides
- Open-source, hardenable software with read-only consultation as the default path.
- Published posture and audit schemas, a local self-check, and release workflow support for checksums, image digests, SBOMs, vulnerability scans, and capsules once the first capsule-producing release runs.
- 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.
Verify it yourself
You can inspect everything you run.
Everything a single registry needs is open source and self-hosted, so your team and your auditors can review exactly what runs before trusting it.
Try the live demo on synthetic data →- The products are open source, so your team and your auditors can review exactly what runs.
- The release workflow is being prepared to publish binary checksums, image digests, image SBOMs, vulnerability scan reports, and release capsules.
- A local self-check validates a deployment against the expected posture.
- 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 privately 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 does not currently hold a formal security certification. The detailed threat model and the current security posture live in the docs, and a pilot includes a security review against your own requirements.