Prohibited Hardcoded Credentials and Cryptographic Secrets

Prohibited Hardcoded Credentials and Cryptographic Secrets

Ghaf forbids hardcoded credentials and cryptographic secrets in code, configuration defaults, or build artifacts. Secrets must be supplied through controlled secret-management mechanisms rather than embedded in source files. This protects the integrity of the platform, the confidentiality of infrastructure credentials, and the ability to rotate keys safely.

Why hardcoded secrets are prohibited

Git history is forever

Hardcoded credentials leak easily and persist in version control history, forks, caches, and mirrors. Even if removed later, prior commits can still expose sensitive data. This makes revocation and incident response far more difficult and risky.

Secrets must be scoped and rotated

Hardcoded values tend to become shared and long-lived. They cannot be scoped to a host, service, or environment, and rotation becomes disruptive. Centralized secret management enables per-host scoping and controlled rotation without editing source code.

Reproducible builds should not embed private data

Ghaf relies on reproducible, declarative configuration. Embedding secrets in Nix expressions or source code breaks that model by baking private data into build outputs and undermines auditability.

Infrastructure is a high‑value target

CI/CD and deployment systems hold signing keys, host SSH keys, and admin credentials. Hardcoded secrets in these paths materially increase the risk of supply-chain compromise.

How the policy is implemented (ghaf‑infra)

Ghaf’s infrastructure repository uses an explicit secret‑management workflow designed to keep credentials out of code:

Encrypted secrets in version control

• Secrets are stored in secrets.yaml files per host and encrypted using sops.
• The repository documents that all configuration, including secrets, is version controlled and that secrets are encrypted rather than stored in plaintext.

SOPS + age key management

• .sops.yaml defines which age keys can decrypt specific secrets files and establishes creation rules per host.
• Admin users manage secrets with the sops CLI, ensuring edits are always encrypted before committing.

Secure deployment and activation

• During deployment or system activation, sops-nix decrypts secrets and places them at the configured filesystem paths for services to consume.
• Host SSH private keys and other credentials are stored as encrypted secrets and deployed during installation, avoiding hardcoded values in host configurations.

Controlled updates and rotation

• The update-sops-files task re-encrypts secrets according to .sops.yaml rules when hosts or admins change, which enables rotation without exposing secrets in code.

Repository checks and hooks (ghaf-infra)

The ghaf-infra repository includes security-oriented CI workflows that help reduce exposure risk, even though they are not dedicated secret scanners:

• GitHub Actions security analysis (.github/workflows/actions-security-analysis.yml): runs zizmor to audit GitHub Actions workflows and uploads SARIF results.
• CodeQL (.github/workflows/codeql.yml): static analysis of repository code (Python) with results published to code scanning.
• OpenSSF Scorecard (.github/workflows/scorecards.yml): supply-chain security posture checks, reported to code scanning.
• Dependency Review (.github/workflows/dependency-review.yml): blocks known-vulnerable dependency changes in PRs.
• Workflow change warning (.github/workflows/warn-on-workflow-changes.yml): alerts on workflow modifications to reduce CI abuse risk.
• Build/test pipeline (.github/workflows/test-ghaf-infra.yml): enforces authorization gates and hardened runner settings before executing builds.

Practical guidance for contributors

• Never place passwords, private keys, tokens, or signing keys directly in source files or Nix configs.
• Use per‑host secrets.yaml encrypted with sops and governed by .sops.yaml rules.
• Treat any new secret as a security‑review item: it must be scoped, encrypted, and deployable without code changes.

Summary

Hardcoded credentials and cryptographic secrets create permanent, high‑impact exposure in a Git‑based workflow. Ghaf avoids this by using encrypted secrets managed with sops-nix and age keys, with controlled decryption at deployment time. This keeps secrets out of code, preserves auditability, and enables safe rotation across the infrastructure.