Most engineering teams can tell you exactly how their application handles authentication, encrypts data at rest, or validates user input. Far fewer can tell you, with the same confidence, who has push access to their production deployment pipeline — or what happens if one of those credentials is compromised.
That gap matters. A CI/CD pipeline can read your source code, pull your secrets, and push directly to production. It is, functionally, one of the most privileged systems in your entire environment, and it is often secured with far less scrutiny than the application it deploys.
Here are five signs it is time for a proper review.
1. Your pipeline permissions have never been audited
If nobody on your team can answer "who can approve a production deploy, and why do they have that access" without checking three different systems, that is a sign the permission model grew organically rather than by design.
2. Secrets live in plaintext environment variables
Long-lived, unrotated credentials sitting in a CI/CD variable panel are a common target. If a secret has been in place longer than anyone can remember rotating it, treat that as a finding, not a formality.
3. Build plugins and actions are unreviewed
Every third-party action or plugin in your pipeline is code that runs with your pipeline's privileges. If your team pulls community actions without pinning versions or reviewing changes, you have an open supply chain risk.
4. Security scanning happens after merge, not before
SAST and dependency scanning that run on a schedule — rather than on every pull request — mean vulnerable code can sit in your main branch for days before anyone notices.
5. There is no signed artifact trail
If you cannot trace a running production binary back to the exact commit, build, and approval that produced it, you have no way to answer "was this build tampered with" during an incident.
None of these are exotic problems. They are the default state of a pipeline that has never been the subject of a dedicated security review — which describes most pipelines we see on day one of an engagement.
The fix is rarely a rewrite. It is usually a sequence of scoped changes: least-privilege permissions, secret scanning, policy-based build gates, and a signed artifact workflow, rolled out without stopping releases in the process.