"Zero-trust" has been stretched by marketing to the point of meaninglessness. Underneath the term is a genuinely useful and quite narrow idea: stop treating network position as authentication. Being inside a VPN, a private subnet, or a corporate office proves nothing about who is making a request. Applied to a deployment pipeline, that idea produces a handful of concrete decisions.
Every request carries identity
Services authenticate to each other with short-lived, verifiable credentials, not shared secrets that live in configuration forever. Your build system should not hold a permanent cloud key; it should exchange a workload identity for a token that expires in minutes. The practical effect is that a leaked credential has a useful lifetime measured in minutes rather than years.
Secrets are never in the repository, and rarely in the environment
Committed secrets are still one of the most common findings in the reviews we run, and rotating them is harder than teams expect because nobody knows the full list of consumers. Use a managed secret store, inject at runtime, scope each secret to one service, and make rotation a routine operation rather than an incident response.
Deployments are authorised, not just triggered
Anyone able to push to main can usually ship to production, which makes a compromised developer account equivalent to production access. Require review on protected branches, separate the ability to merge from the ability to promote to production, and log who authorised each release. Signed commits and build provenance make it possible to answer "what exactly is running, and where did it come from" — a question that is deeply uncomfortable during an incident if you cannot.
Blast radius is a design decision
Assume any single component will be compromised eventually, and ask what that compromise reaches. A service that only needs to read one bucket should not hold credentials that can write to all of them. Least privilege is unglamorous work that pays out precisely once, when it converts a serious incident into a contained one.
Third-party dependencies are part of your pipeline
A build that pulls unpinned dependencies at deploy time grants every one of those maintainers a path into your production artefact. Pin versions, use a lockfile, review what your CI actions and plugins can access, and prefer fewer dependencies with narrower permissions over convenience.
Where to start if none of this exists yet
In order, and each is independently worth doing: remove long-lived cloud keys in favour of short-lived workload identity, move committed secrets into a managed store, require review before production promotion, then work through least privilege service by service. The first two typically take an afternoon each and remove the most commonly exploited weaknesses.