A defence customer objects that Sigstore's public Rekor log exposes internal repository and staff names — how do you answer?

## Take the objection seriously first The wrong answer is to tell a security-conscious customer that a public append-only log of your signing activity leaks nothing. It leaks, permanently, and by design. What is published in each entry: - **The signing identity.** For workload signing this typically identifies the repository and the specific workflow that ran. For human signing it is an account identifier such as an email address. Either way, internal names become external names. - **The artifact digest.** A hash, not content — but a hash is a durable correlator. Anyone who ever obtains a copy of that artifact can prove you signed it. - **The time.** Precise, log-signed, and therefore reliable enough to chart cadence. What an analyst builds from that, with no privileged access at all: your internal project inventory, which projects are active and which have gone quiet, when releases happen and therefore when your engineers work, roughly how many distinct people or systems sign, and when a new product line started. For a defence supplier, the existence and codename of a project can itself be the sensitive fact. This is reconnaissance material about organisational structure and intellectual property, gathered by an anonymous observer at zero cost and zero risk. What is **not** published is equally worth stating plainly: no source, no binaries, no build logs, no dependency lists. The log holds hashes and signatures. ## The private-deployment option and its true cost Sigstore's components can be run privately: your own certificate authority issuing against your own identity provider, your own transparency log, your own trust root distributed to your own verifiers. Internal identities and digests then stay inside your boundary. Be honest about what that costs: - **You now operate the trust infrastructure.** The log's keys, its availability, its backups and its append-only guarantee become your responsibility. If the log is down, signing or verification stalls. If its key is lost, historical proofs lose their anchor. - **You must distribute the trust root.** Every verifier — every cluster, every developer machine, every partner — needs your roots, correctly and freshly. That distribution problem is the one the public good instance solves for free. - **External parties cannot verify.** If you ship anything to customers, they cannot check your signatures without adopting your trust root, which is a much harder sell than a public one. - **Transparency degrades toward an audit log.** The strength of a public log is that strangers, researchers and your own competitors can all watch it, so a fork or an omission is likely to be noticed. A log watched only by the organisation that runs it provides tamper-evidence against outsiders but far weaker assurance against a compromised insider or a compromise of the platform itself. That last point is the strategic one and the one worth making to the customer: **the value of transparency is proportional to the number of independent parties watching.** A private log is a real control, but it is a different, weaker control than a public one, and you should not sell it as equivalent. ## The answer I would actually give Split the estate by audience rather than choosing one policy for everything. - **Artifacts distributed outside the organisation** go to the public log. Their whole purpose is that a stranger can verify them, and the metadata exposed is metadata about products that are already public. The customer demanding verifiable releases is asking for exactly this. - **Internal-only artifacts** — internal services, tooling, anything never shipped — go to a private deployment, or are signed under a policy where the exposed identity is deliberately uninformative. - **Reduce what the identity reveals.** Sign from purpose-named workload identities rather than personal accounts. This removes staff names from the public record, narrows the identity set you have to monitor, and is better practice independently of privacy. - **Treat naming as a security decision.** If a repository name is classified, it must not become a signing identity in a public log. That is a constraint on naming and on where the build runs, decided before the pipeline is built, not a setting to change afterwards. ## What not to promise Do not promise removal. The log is append-only; entries published today are published for good, and a request to delete cannot be honoured without destroying the property that makes the log worth anything. If sensitive names are already in the log, the remedy is forward-looking — rename, re-scope identities, move future signing — plus an honest disclosure of what is already out there. Also do not offer to simply stop signing. Dropping signing to protect metadata trades a strong integrity guarantee for a weak confidentiality one, and it leaves your consumers unable to tell your artifacts from anyone else's. If confidentiality genuinely outranks external verifiability for a given artifact, the private deployment is the answer, not silence.