Secrets

What they are

A secret is any value where someone other than the intended holder gaining knowledge of it would cause material harm. An attacker uses it to log in as you, a competitor learns something privileged, a customer's data is exposed, or regulators issue a fine.

In practice secrets are the credentials, keys, and tokens that systems use to authenticate to each other and to encrypt things. Their defining property is asymmetry. The value is small (often 16-64 bytes), the consequence of leaking it is large, and there's no recovery once the value is out in the world. Detection and rotation are the only mitigations.

Common kinds

• Passwords and API keys. Human or machine credentials, typically long-lived bearer tokens.
• Private keys. The half of a public-private keypair that proves identity (SSH, TLS certs, code signing, JWT signing).
• Symmetric keys. Used to encrypt data at rest or in transit (database encryption keys, session keys).
• OAuth tokens. Short-lived access tokens and longer-lived refresh tokens delegating access on a user's behalf.
• Database connection strings. Usually carry an embedded password and are themselves a secret.
• Webhook signing secrets. Used to prove a webhook request actually came from the upstream service.
• Encryption-at-rest master keys. Keys that wrap every other key in a vault, HSM, or KMS.

How to tell whether a value is a secret

Apply three tests:

1. The leak test. If this value showed up in a public GitHub repo, would you have to rotate it, notify someone, or accept material risk? If yes, it's a secret.
2. The audit test. Are you required (by policy, contract, or regulation) to know who read this value and when? If yes, it's a secret.
3. The shape test. Does it look like one? Bearer eyJ..., sk_live_..., -----BEGIN PRIVATE KEY-----, AKIA.... These formats exist because they identify high-value credentials.

A database hostname, a feature flag, or an S3 bucket name fails all three. They're configuration. A database password, a service account JSON, or a session-signing key passes all three. They're secrets.

How they're handled

The lifecycle of a secret is short on paper and messy in practice. It's created (often by the system that owns it, like a cloud provider issuing an API key), distributed to every consumer that needs it, used continuously, rotated on a schedule (or after suspected compromise), and eventually revoked when the consumer stops needing it.

The hard parts are distribution and rotation. Distribution is hard because every laptop, container, CI runner, and serverless function that needs the secret has to receive it without that distribution creating its own leak surface. Rotation is hard because the new value has to reach every consumer before the old value is revoked, and "every consumer" turns out to be a moving target.

A secrets manager exists to handle both. It centralizes the value, exposes it to authenticated consumers at runtime, logs every read, and lets a single update propagate to every consumer instead of being applied N times across a fleet.

How SikkerKey handles yours

Your secrets are encrypted in layers. Each value sits under a key generated just for that secret. That key sits under a master key generated for your project. The project master keys sit under a key that only exists in memory and is never written to disk. If somebody walked off with the database alone, they'd have opaque ciphertext at every layer and no key to decrypt it with.

Reads require a signed request from the machine that owns the identity. Copying credentials off a laptop doesn't grant access by itself, and every read appears in your audit log under the identity that asked for it.

For PostgreSQL, MySQL, MongoDB, Redis, or MSSQL credentials, you can schedule automatic rotations. SikkerKey generates a new value on your interval, a local agent applies it to the database, and a leaked credential becomes useless within hours.