What do teams get wrong about software visibility in CI/CD pipelines?

Why This Matters for Security Teams

Software visibility in CI/CD is often mistaken for dashboard coverage: more logs, more scans, more status pages. That misses the real control point. In a release pipeline, visibility only reduces risk when it changes who can approve, sign, promote, or revoke an artifact, and when it creates defensible evidence for each trust decision. NIST’s Cybersecurity Framework 2.0 frames this as governance, not observation.

That distinction matters because CI/CD systems concentrate secrets, signing keys, build permissions, and deployment authority in a small number of automated paths. NHIMG’s CI/CD pipeline exploitation case study shows how attackers target those paths directly, not just source code. Once a pipeline can move software into production without binding each step to policy, visibility becomes retrospective theater. In practice, many security teams discover pipeline abuse only after a release artifact has already been trusted, distributed, or executed.

How It Works in Practice

Effective pipeline visibility starts with knowing which identity signed what, which runner built it, which secrets were available, and which controls were enforced at each stage. That is closer to non-human identity governance than traditional appsec reporting. The Guide to the Secret Sprawl Challenge is useful here because CI/CD visibility fails fast when secrets are embedded in build logs, environment variables, commit history, or shared automation accounts.

Practitioners usually need four linked layers:

• Build provenance that ties an artifact to a specific source revision, runner, and job execution.
• Policy enforcement that blocks unapproved dependencies, unsigned artifacts, or untrusted promotions.
• Secret hygiene that removes long-lived credentials from runners, scripts, and deployment jobs.
• Event evidence that records who approved, signed, or overrode a release decision.

That is why current guidance increasingly treats pipeline telemetry as an enforcement signal rather than a reporting feed. The Top 10 NHI Issues highlights that machine identities in automation often outlive the workflows they support, which makes stale permissions and forgotten tokens a recurring release risk. The practical goal is not to watch every job; it is to ensure no job can proceed unless its identity, inputs, and approvals satisfy policy at runtime. The 2026 State of Secrets Sprawl report found 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why detection without automated revocation leaves visibility incomplete. These controls tend to break down in fast-moving monorepos with shared runners and weak signing discipline because too many releases inherit the same trust path.

Common Variations and Edge Cases

Tighter pipeline control often increases build friction, requiring organisations to balance developer speed against the need for trustworthy release evidence. Best practice is evolving, but there is no universal standard for how much visibility is enough when release frequency is high and teams depend on ephemeral infrastructure.

One common edge case is a partially centralised CI/CD model, where a platform team owns runners but product teams own workflows. In that setup, visibility gaps often appear at handoff points: secrets injection, privileged deployment steps, and manual approvals that are recorded in one system but enforced in another. Another common failure mode is assuming private repositories are safer than public ones; the current evidence says otherwise, and the problem is usually credential reuse, not repository openness alone.

For high-risk release paths, current guidance suggests treating visibility as a release gate that feeds policy-as-code, not a post-release audit trail. That means using signed attestations, short-lived credentials, and explicit approval records for changes that can affect production trust. Where teams rely on ad hoc scripts, long-lived service accounts, or shared release bots, visibility quickly becomes noisy and incomplete. The Reviewdog GitHub Action supply chain attack is a reminder that third-party automation can expand the blast radius when pipeline trust is not tightly bounded.

Related resources from NHI Mgmt Group

• What do security teams get wrong about workload identity in cloud and CI/CD environments?
• What do teams get wrong about secret scanning in CI pipelines?
• What do security teams get wrong about persona-based identity reporting?
• What do security teams get wrong about third-party access in CJIS environments?