Rotate credentials and revoke tokens — what the malicious code touched

A malicious install hook reads every secret the build holds. The hook runs in the build’s process, with the build’s filesystem, network, and secret access. The inventory cannot be read from the lockfile alone.

The four credential classes

A build environment that resolved the malicious version exposes credentials from four sources:

flowchart LR
    A["malicious hook runs in build"] --> B["build secrets"]
    A --> C["cloud access keys"]
    A --> D["registry tokens"]
    A --> E["deploy tokens"]
    B --> F["build scope"]
    C --> G["cloud scope"]
    D --> H["registry scope"]
    E --> I["deploy target scope"]

• Build secrets. GITHUB_TOKEN, repository secrets referenced by ${ secrets.NAME }, environment-level secrets.
• Cloud access keys. AWS_ACCESS_KEY_ID, GOOGLE_APPLICATION_CREDENTIALS, AZURE_CLIENT_SECRET.
• Registry tokens. REGISTRY_TOKEN, Docker config JSON, GitHub Packages token.
• Deploy tokens. SSH deploy keys, deploy API tokens, Helm chart registry credentials.

Building the inventory

The inventory is built from the workflow definition, the secret manager, and the live build environment:

grep -E 'secrets\.[A-Z_]+' .github/workflows/*.yml \
  > workflow-secrets-$(date -u +%FT%TZ).txt
gh secret list --repo "$ORG/$REPO" \
  > repo-secrets-$(date -u +%FT%TZ).json
kubectl get deployment "$DEPLOYMENT" \
  --namespace "$NAMESPACE" \
  -o jsonpath='{.spec.template.spec.containers[*].env[*].valueFrom}' \
  > deployment-secrets-$(date -u +%FT%TZ).json

Each entry is a credential to disable, rotate, or revoke.

The disable-rotate-revoke sequence per class

The sequence from XCIV applies to each credential class. The class determines the specific command:

The GITHUB_TOKEN special case

The GITHUB_TOKEN auto-injected by the platform is short-lived: it expires when the job ends. Once the workflow is paused, no live token exists. The credential to rotate is not the token; it is the workflow’s permissions: block. A workflow with permissions: write-all must be tightened to read-all before re-enabling.

Vault token revocation

Vault tokens can be revoked by the token holder or by an operator with the right policy. On a compromised build the operator cannot trust the build’s output:

vault token revoke "$BUILD_VAULT_TOKEN"
vault lease revoke -prefix "auth/token/create/"

Documenting the revocation

Each revocation is documented with five fields: class, identifier, action with timestamp, operator, and verification API call. The log is the artefact.

Production discipline

1. Build the inventory from both environments.
2. Disable before revoke. Disable is reversible.
3. Consumers before revoke. Every consumer must hold the new credential before the old one is revoked.
4. Document every revocation. A revocation that is not documented did not happen.

Cross-course references

• Git, CI/CD & GitOps — Part XCIV-02 (Revoke or Rotate First) covers the disable-rotate-revoke sequence.
• Linux for Production Sysadmins — Part XXXIV (KeyMgmt) covers the SSH key rotation patterns.
• Kubernetes for Production Sysadmins — Part XXII (ServiceAccounts) covers the runtime service account patterns.

Quiz