SOPS and Secret Management: English for GitOps Security Workflows

Security discussions in DevOps teams carry their own layer of specialized vocabulary. When your team reviews how secrets are managed, debates GitOps security posture, or runs an incident retrospective about a leaked credential, engineers use precise English terminology that can be hard to follow if you only know the technology but not the language. This post teaches you the English vocabulary and communication patterns around SOPS, envelope encryption, and GitOps secret management — so you can follow security reviews and speak up confidently.

Key Vocabulary

SOPS (Secrets OPerationS) — A tool that encrypts secret files (YAML, JSON, ENV, etc.) so they can be safely committed to a Git repository. Engineers refer to it simply as “SOPS” (pronounced like the word “sops”) and say “we encrypt with SOPS” or “the file is SOPS-encrypted.”

“We store all our Kubernetes secrets in SOPS-encrypted YAML files in the repo. Anyone with the right KMS key can decrypt locally, but GitHub just sees ciphertext.”

Envelope encryption — A two-layer encryption pattern where your actual secret is encrypted with a data encryption key (DEK), and that DEK is then encrypted with a key management key (KEK). SOPS uses this approach. Engineers say “SOPS uses envelope encryption” or “the data key is wrapped by the master key.”

“Envelope encryption means you never expose the master key to the application — you use it to unwrap the data key, and the data key does the actual decryption. It’s a clean separation of concerns.”

Key Management Service (KMS) — A managed service (AWS KMS, GCP KMS, Azure Key Vault) that stores and controls cryptographic keys. Engineers say “we use KMS to back SOPS” or “the master key lives in KMS.” Often used as an adjective: “KMS-backed encryption.”

“We configured SOPS to use AWS KMS as the root of trust — the encryption key never leaves KMS, so even if the repo is leaked, the attacker still needs AWS access to decrypt.”

age encryption — A modern, simple encryption tool (pronounced like the English word “age”) often used with SOPS as an alternative to PGP. Engineers say “we’re using age keys” or “the team moved from PGP to age.” Note the lowercase — it is the tool’s actual name.

“We switched from PGP to age for local developer keys because the key management is so much simpler — no keyring, no gpg-agent issues, just a keypair file.”

PGP keys — Pretty Good Privacy keys, an older encryption standard still used with SOPS. You’ll hear “PGP-encrypted,” “sign with your PGP key,” or “the SOPS config lists PGP recipients.” Pronounced by spelling out the letters: “P-G-P.”

“The legacy secrets files still reference PGP fingerprints — we’re gradually migrating those to age as developers rotate their credentials.”

Secret rotation — The practice of regularly replacing secrets (passwords, API keys, tokens) with new values to limit the impact of potential exposure. Engineers say “we rotate secrets,” “enforce rotation,” or “the secret is overdue for rotation.”

“After the breach, we immediately rotated all secrets that were in scope — database passwords, API keys, the works. The SOPS setup made that straightforward because we just re-encrypt with new values.”

Audit trail — A log of who accessed or modified something and when. In secrets management, this is critical. Engineers say “we need an audit trail,” “KMS provides an audit trail,” or “check the audit logs.”

“One advantage of KMS-backed SOPS is that every decryption call shows up in CloudTrail — you have a complete audit trail of who decrypted what secret and when.”

In-repo encrypted secrets — The GitOps pattern of storing encrypted secrets directly in the Git repository. Engineers describe this as “secrets in the repo” or “in-repo secrets management,” contrasting it with external secrets stores.

“The whole point of in-repo encrypted secrets is that the secrets lifecycle is managed through pull requests — you get code review, history, and rollback for free.”

Least privilege — The security principle of giving any identity only the permissions it actually needs, and no more. Engineers say “we apply least privilege,” “the role has least-privilege access,” or use it as an adjective: “a least-privilege policy.”

“Each environment has its own KMS key, and the CI/CD roles only have decrypt access to the key for their environment — that’s the least-privilege approach.”

Secret sprawl — The problem of secrets being scattered across many places (local files, CI/CD settings, Slack messages, hardcoded in code) making them hard to track and rotate. Engineers say “we have secret sprawl” or “SOPS helps us address sprawl.”

“Before we adopted SOPS, we had terrible secret sprawl — some things were in Vault, some in GitHub Actions secrets, some in a shared LastPass folder. It was impossible to audit.”

Decryption context — Additional metadata passed to KMS during encryption and decryption that must match, adding an extra layer of protection against key misuse. Engineers say “we include a decryption context” or “the context must match.”

“We pass the environment name as a decryption context — even if someone gets the ciphertext from staging, they can’t decrypt it using the production key because the context wouldn’t match.”

Phrases in Context

Explaining the SOPS setup in an onboarding or review:

“The way we handle secrets is: everything lives in the repo as SOPS-encrypted files. You’ll need to have your age key added to the .sops.yaml config by another engineer, and then sops -d will decrypt locally for you. In CI, the KMS role handles decryption automatically.”

Flagging a security concern in a PR review:

“I see this PR is adding an API key directly in the ConfigMap. Can we move that to a SOPS-encrypted secrets file instead? Plaintext credentials in the repo is a hard blocker for us — even in internal repos.”

Discussing secret rotation in a retrospective:

“As a follow-up action from this incident, I’d suggest we document a runbook for secret rotation and set calendar reminders for any credential that doesn’t auto-rotate. The audit trail in CloudTrail will tell us when each key was last rotated.”

Raising least privilege in an architecture discussion:

“The service account here has admin access to the whole KMS key ring, which is wider than it needs to be. Can we scope it down to just the two keys this service actually uses? We want to apply least privilege consistently across all our service accounts.”

Key Collocations

• commit encrypted secrets to a repo (not “push secrets”)
• rotate a secret / trigger a rotation (not “change a secret”)
• audit trail (almost always these two words together, not “audit log” in compliance contexts — though both exist)
• root of trust — the ultimate authority in a key hierarchy: “KMS is the root of trust”
• plaintext secret — an unencrypted credential: “no plaintext secrets in the repo”
• widen / scope down permissions — grant more or fewer rights: “scope down the IAM role”
• in scope — affected by a security incident: “all credentials in scope were rotated”
• hard blocker — something that must be fixed before merging/shipping: “plaintext credentials is a hard blocker”

Practice

Find a public repository that uses SOPS — search GitHub for .sops.yaml to find examples. Read the README and any related documentation about how the team configures secrets. Then write a short (five to eight sentence) onboarding explanation, as if you were explaining the secrets workflow to a new team member in a Slack message. Use at least five vocabulary terms from this post. Pay attention to whether you write “we rotate secrets” or “we change secrets” — these small word choices signal fluency to native speakers and tell them whether you really know the domain.