Per-Secret Encryption Makes Git Reviews Safer

The one-line change that rewrote the vault

A reviewer expects a pull request to rotate STRIPE_API_KEY. Instead, the encrypted file is one large changed blob. Git can prove that bytes changed, but not whether one value or every production credential was replaced. Encryption preserved confidentiality and discarded useful review semantics.

OWASP’s Secrets Management Cheat Sheet explicitly recognizes encrypted secrets in git as an architectural pattern, while requiring separation between environments and designated decrypting consumers. The security question is therefore not only “is it encrypted?” but “what is the unit of encryption and authorization?”

Granularity creates reviewable invariants

With per-entry encryption, a reviewer can establish that the intended variable changed, an unrelated production credential did not change, and the encrypted artifact was committed in the same pull request as the code that consumes it. The plaintext remains unavailable.

That does not make ciphertext self-authenticating in every design. The implementation still needs authenticated encryption, safe recipient handling, and a format that resists swapping or mislabeling entries. Reviewability is an additional control, not a cryptographic primitive.

envseal uses age-based encryption and encrypts values independently. Its repository documents X25519 identities and runtime injection; team members receive their own keypairs, so access can be granted or revoked per recipient rather than by redistributing one shared decryption password. A one-value update produces a one-value vault diff.

What the diff should and should not reveal

A useful encrypted format can expose variable names, recipients, format version, and ciphertext changes. It must not expose plaintext, reusable key material, or secrets embedded in commit messages. Some organizations consider even variable names sensitive; they should choose a more opaque format and accept the review trade-off consciously.

Use pull-request policy to verify intent:

• the changed encrypted keys match the deployment change;
• recipient changes have an approved identity owner;
• removal of a recipient is not mistaken for rotation of the upstream credential;
• no plaintext .env or command output appears elsewhere in the patch.

Git is only one surface

An encrypted vault does not prevent someone from pasting a decrypted value into a Jira rollout ticket or Confluence runbook. Secret Sentinel provides the adjacent control: detection and redaction on the collaboration surface. Per-secret encryption makes the intentional path safer; content scanning catches the accidental path around it.