Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/llms.txt
Full corpus: https://docs.registrystack.org/llms-full.txt

# Report a vulnerability

> How to report a suspected Registry Stack vulnerability privately, what is in scope, and how to verify a release you downloaded.

Report a suspected Registry Stack vulnerability privately. Never open a public issue or pull
request for a suspected credential disclosure, auth bypass, audit redaction failure, connector
data leakage, or signing-key handling bug.

## When to use this

Use the private disclosure channel for anything in scope below. For a known, documented pilot
limitation that does not create an exploitable issue beyond what is already documented, file a
regular product-gap issue instead; see [Known limitations and non-guarantees](../../explanation/known-limitations/).

## Before you start

Gather what the report needs before you open the channel:

- The affected commit or release tag.
- The config shape involved (redact secret values before you paste anything).
- Reproduction steps.
- The impact you observed or expect.

Do not include live credentials, bearer tokens, API keys, private keys, or raw registry records in
the report.

## Steps

1. Report privately through GitHub Security Advisories at
   `https://github.com/registrystack/registry-stack/security/advisories/new`.
2. If GitHub Security Advisories is unavailable, contact the maintainer through an existing
   private project channel instead of opening a public issue or pull request.
3. Include the affected commit, config shape, reproduction steps, and impact from the checklist
   above.

Registry Stack aims to acknowledge private reports within 5 business days.

## What is in scope

Authentication bypass, credential disclosure, audit redaction failure, audit integrity failure,
signing-key handling bugs, source connector data leakage, and privacy regressions that expose raw
subject identifiers.

Known pilot limitations, such as no revocation service, no `/.well-known/jwt-vc-issuer` endpoint,
and no built-in data-subject erasure workflow, are product gaps, not vulnerabilities, unless they
create an exploitable security or privacy issue beyond the documented limitation. The source
adapter sidecar also relies on deployment-network egress controls for outbound source traffic; see
the sidecar's README at `crates/registry-notary-source-adapter-sidecar/README.md` in the
repository.

## Verify a release signature

For checking what you actually downloaded: Registry Stack release assets are signed by the release
workflow with keyless Sigstore cosign, and tag-triggered releases also publish SLSA provenance.
For each signed release asset, download the asset, its `.sig` signature, and its `.pem`
certificate from the GitHub Release, then verify:

```bash
asset=registryctl-v0.8.4-linux-amd64   # replace with the asset you downloaded

cosign verify-blob \
  --certificate "${asset}.pem" \
  --signature "${asset}.sig" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/registrystack/registry-stack/.github/workflows/release.yml@refs/tags/v[0-9]+[.][0-9]+[.][0-9]+.*$' \
  "${asset}"
```

A successful check prints `Verified OK`.

If a release asset has no matching `.sig` and `.pem` files, treat it as unsigned; the `v0.8.0`
prerelease predates release-asset signing. Git version tags are not yet cryptographically signed.
The full verification steps, including SLSA provenance, are in `SECURITY.md` and
`release/VERIFY.md` in the repository.

## Next

- [Security overview](../)
- [Harden a production deployment](../hardening-checklist/)
- [OpenSSF and release trust](../openssf-evidence/)