CI/CD security: who can ship to production unseen?

Start with the path that can change production

Picture a team of five engineers. Every change to the main branch needs a review, so the process looks safe. The deploy workflow lives in the same repository, though, and a workflow edited in a branch can run before anyone reviews it. If that run can read the production deploy key, the review step never comes into it.

So before anything else, we’d map who can change what. That means every account and token that can change the code, the workflow files, the secrets or the deploy settings. Emergency fix routes belong on the map too. They tend to carry the widest permissions and the least review.

Repository and workflow authority

Branch protection only helps if admins can’t quietly bypass it and workflow files get the same review as application code. Admin rights handed out during setup and never taken back can undo it. So can workflows that run code from an outside pull request with the pipeline’s own permissions.

Secrets and build machines

A deploy key shared by every repository is the classic problem. A self-hosted build machine that can reach the production network is another. In both cases one compromised job is enough, and nobody’s password is needed.

Short-lived credentials issued to the pipeline beat stored keys. The trust rule behind them still matters. A rule that accepts any branch of any repository in your organisation brings the old risk back.

Questions for your engineering lead

For each answer, ask to see the setting itself. A policy document tells you what was intended.

• Who holds admin rights on our code host, and when did each of them last need them?
• Can one person change the deploy workflow and approve their own release?
• Which secrets can a pull request from outside the team reach?
• Could we show a customer which reviewed change produced the build running now?