A pipeline is often described as automation, but security should also see an identity. It reads source, creates artifacts, retrieves dependencies, assumes cloud roles, and changes running systems. Its effective privilege may exceed that of most human administrators.
Protect what can trigger authority
Production deployment should depend on a protected, reviewed state. Restrict who can change workflow definitions, branch protections, build dependencies, and reusable actions. Treat a change to pipeline code with the same care as a change to the application it deploys.
Pull requests from untrusted contexts should not receive production secrets or execute on persistent privileged runners. Separate build and deploy stages so code compilation does not automatically inherit release authority.
Use short-lived, specific credentials
Prefer federation from the pipeline to the target platform. Bind access to repository, branch or environment, workflow, and audience. Issue a credential only for the duration of the job and grant it the operations that deployment actually requires.
The pipeline should prove which trusted workflow it is, not present a shared secret that any copied process can reuse.
Make artifacts immutable and traceable
Build once, record provenance, scan, sign, and promote the same digest. A release should connect back to a reviewed commit and a specific workflow run. Protect the registry from tag replacement and limit which identity can publish to trusted locations.
Runner isolation matters too. Ephemeral workers reduce persistence between jobs, while network boundaries limit which internal services a compromised build can reach. Keep deployment workers separate from jobs that execute less-trusted code, and destroy job state instead of relying on cleanup to find everything.
Observe the deployment identity
Log role assumptions, target environments, artifact digests, approvals, and infrastructure changes. Alert when the pipeline acts outside its normal repository, time, region, or operation pattern. Keep an emergency disable path that does not rely on the pipeline itself.
CI/CD is a powerful production principal with software attached. Designing it that way makes source review, artifact integrity, and cloud permissions part of one coherent trust path.