Topic starter
30/09/2026 7:10 pm
TL;DR: P0 Security shows a GitLab CI/CD pipeline using a GCP service account that starts read-only, fails on a write step, then succeeds after a five-minute just-in-time elevation to storage.objectCreator, illustrating how standing machine privilege turns routine builds into escalation paths. The real issue is persistent access, not pipeline automation.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “How to elevate machine identity permissions in GitLab Pipelines”.
Key questions
Q: What breaks when CI/CD service accounts do not use just-in-time access?
A: Standing access turns build automation into a persistent privilege path.
Q: Why do time-bound permissions reduce risk for GitLab pipelines?
A: Time-bound permissions reduce risk because they align access with a single build step instead of with the lifetime of the service account.
Q: How do security teams know when CI/CD access is too broad?
A: CI/CD access is too broad when routine build identities can reach signing, publishing, or repository-modification functions.
Practitioner guidance
- Define pipeline-specific privilege baselines Map each GitLab job to the minimum role required for read, write, deploy, or artifact operations, and remove any persistent write grant that is not job-specific.
- Require approval before elevation Use a just-in-time request flow so the service account only receives write-capable access when a specific build step needs it and an approver has validated the request.
- Automate expiry and reversion Set elevated permissions to expire automatically at the end of the approved window, and verify the identity returns to its original role without manual cleanup.
Bottom line: GitLab service accounts become materially safer when write access is issued only for the specific build step that needs it.
What's in the full article
P0 Security's full video covers the operational detail this post intentionally leaves for the source:
- The exact GitLab pipeline sequence from read-only access to failed write and successful rerun.
- The temporary permission change from storage.objectViewer to storage.objectCreator in a GCP service account.
- The approval and expiry flow that automatically removes elevated access after five minutes.
- The live demonstration of how the same pipeline behaves again once access returns to baseline.
👉 Read P0 Security's video on just-in-time elevation for GitLab service accounts →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/09/2026 7:11 pm
Standing privilege is the real CI/CD governance failure, not automation itself. A GitLab pipeline that can write whenever it runs is not just efficient delivery, it is persistent authority wrapped in automation. The article makes the control boundary clear: if a build step does not need write access from the outset, it should not inherit it. Practitioners should treat standing service account access as the exception, not the default.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern service account elevation in pipelines?
A: Teams should govern elevation as a temporary entitlement with approval, scope, and expiry, not as a permanent role change. The practical test is whether the identity returns to its baseline automatically after the job completes. If not, the programme is still relying on standing privilege with a shorter leash.
👉 Read our full editorial: Just-in-time elevation for GitLab service accounts reduces CI/CD risk