Logs of Duty: Zero Trust (except for the CI)

Lock down your engineers. Leave the pipeline wide open.

Rule #1: Enforce MFA everywhere, except for CI service accounts. Humans must rotate passwords every 30 days. Meanwhile, your CI pipeline logs in as root using an unencrypted secret last updated five years ago.

Rule #2: Don’t give developers prod access. They can’t SSH into production. But their YAML files on their CIs can still delete all your VMs. That’s just automation.

Rule #3: Encrypt everything at rest. Leave secrets in environment variables.
Your data is encrypted at rest, per policy. Except for your CI jobs, which export JSON keys as plaintext. In every run.

Rule #4: Use fine-grained IAM roles. Each engineer has tightly scoped permissions. But the CI pipelines? Full access to everything. No one remembers why, and no one is brave enough to change it.

Rule #5: Run security scans on your containers. It’s a good security practice. But don’t forget to update your CI to run these jobs before the deployment. Not as a postmortem.

Rule #6: Allow anyone to merge to main, but require approvals for critical files.
Updating a README? At least two reviewers. Updating firewall rules? Auto-merge. Efficiency first.

Rule #7: Zero Trust for users, devices, and networks. But the CI pipelines can be considered as a trusted entity. Full admin, no audit logs, and run every 5 minutes. Don’t overthink it.

Rule #8: Put secrets in a vault. Then echo them in CI logs. It’s essential to maintain a robust security posture. Until something breaks, then “echo ${PROD_DB_PASSWORD}” in logs. Because debugging is hard.

Rule #9: Let every team manage its own pipelines. Consistency is a bottleneck. Let teams duplicate secrets, reinvent deployment flows, and write custom bash scripts. Security will love the surprise.

Rule #10: Celebrate your Zero Trust policy in the next security audit. Just don’t mention CI/CD. If the auditors don’t ask, you don’t have to lie. Technically.