Look beyond the approval button
On 22 September 2026, Google Cloud announced additional pipeline access controls and more detailed ownership rules for approving changes. It is a useful prompt to examine a wider question: who actually has the authority to release your software?
My view is that release authority belongs in an architecture and security review. A documented approval process is useful only if the systems enforce it. A person may be unable to approve a release directly, yet still be able to change the script or permission that makes approval unnecessary.
Separate building from permission to deploy
The automated process that builds and tests software runs code, including installation scripts and other tools. Consider a simple hypothetical case: a changed build script runs inside an environment that also has access to production. The script's permissions matter even if the intended deployment step is never reached. An approval later in the process may not protect access already available earlier.
I recommend a clear boundary between building a candidate release and authorizing its deployment. GitHub's guidance warns against executing untrusted code in privileged workflows. Ask whether the build environment needs production access at all, and whether the deployment stage can accept only the intended, reviewed output.
Protect the rules as well as the application
Start with the files and settings that control releases: build scripts, deployment definitions, permissions and approval requirements. Assign an appropriate reviewer to changes in those controls. Check who can alter the reviewer requirement itself and who can bypass it in an emergency.
For a business-critical service, I want the technical configuration to reflect the agreed responsibility. That includes a usable urgent-release procedure: a named decision-maker, a defined reason for the exception and a record of what was changed. Urgency should change the response time without silently removing accountability.
Limit access and examine what crosses the boundary
Keep each stage's permissions narrow. Examine shared build caches and files passed between stages, especially when contributions from outside the trusted release process are involved. A later approval does not establish that every earlier input is trustworthy.
For teams publishing npm packages, trusted publishing can replace stored, long-lived publishing tokens with short-lived credentials tied to an approved workflow. That reduces one form of credential exposure. My assessment is that it still leaves a separate question: is the authorized workflow running the code and publishing the package you intended?
Trace one release before redesigning everything
Take one recent release and follow it from the reviewed change to the deployed result. Ask five concrete questions. Who changed the release controls? Who approved the deployment? Which exact build output was used? What access did each stage receive? Who could stop the release or revoke that access?
Then check rejected cases in a safe test environment: a failed check, an unauthorized source branch and an unexpected build output. Confirm that each is actually stopped. Record gaps and assign responsibility before changing tools. I would start with this trace because it turns a broad concern about software supply-chain security into specific decisions about your own delivery process.