How do security teams know whether a package compromise has become CI/CD persistence?

Why This Matters for Security Teams

A package compromise becomes CI/CD persistence when the attacker stops at stealing secrets and starts using the build system as a repeatable execution path. That shift matters because CI/CD runners, workflow tokens, and automation hooks can outlive the initial compromise, letting an intruder return even after a password reset or package rollback. NHI Management Group’s CI/CD pipeline exploitation case study shows why pipeline abuse is rarely a one-time event once execution is anchored in automation.

The practical mistake is assuming detection ends with secret discovery. In reality, persistence often shows up through new GitHub workflows, modified repository automation, or a freshly registered self-hosted runner that can keep executing attacker-controlled jobs. That is a governance problem as much as a detection problem, because automation identity becomes the durable foothold. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here, but teams still need pipeline-specific telemetry to tell transient compromise from operational persistence. In practice, many security teams encounter CI/CD persistence only after the attacker has already chained workflow access into repeated deployments.

How It Works in Practice

The clearest sign of CI/CD persistence is that the attacker has moved from a package artifact into the repository and runner control plane. A compromised dependency can drop a payload during install, but persistence requires a reusable execution mechanism: a workflow file that runs on every push, a repository dispatch trigger, a scheduled job, or a self-hosted runner enrolled into the attacker's loop. Once that happens, the attacker no longer needs the original package access every time.

Security teams should look for a sequence, not a single indicator. First, suspicious package behavior or dependency takeover. Then, an abnormal change in repository automation. Finally, evidence that the attacker can re-enter without re-exploiting the package. Useful signals include:

• New or altered GitHub Actions workflows with broad triggers or hidden scripts.
• New repositories created for staging, relay, or tool hosting.
• Unfamiliar runner registrations, especially self-hosted runners with long-lived network reach.
• Audit-log entries for workflow edits, token creation, or repository administration outside normal change windows.
• Secrets exposure followed by new automation that can read those secrets on demand.

That distinction matters because a stolen token that is immediately revoked is not persistence, but a workflow that can mint fresh credentials or invoke a runner again is. The operational question is whether the attacker can still execute after the original compromise is remediated. NHI Management Group’s Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack both illustrate how secrets and automation can be turned into repeatable access. Current guidance suggests treating workflow mutation, runner enrollment, and unexpected automation privileges as persistence indicators, not just hygiene issues. These controls tend to break down in self-hosted runner fleets with weak inventory, because the attacker can blend into legitimate build capacity and retain access through normal job scheduling.

Common Variations and Edge Cases

Tighter CI/CD monitoring often increases operational overhead, requiring organisations to balance early persistence detection against developer velocity and noisy automation alerts. Not every anomalous workflow is malicious, and not every secret leak creates persistence. The tradeoff is deciding when the evidence crosses from exposed credential to durable foothold.

There is no universal standard for this yet, but current guidance suggests treating the following as higher-risk edge cases:

• Reusable workflows that call remote actions from unpinned or attacker-influenced references.
• Compromised packages that only become persistent after a maintainer approves a poisoned workflow change.
• Private repositories that are assumed safe even though internal repos can still carry hidden secrets and automation risk.
• Runner fleets that are ephemeral in theory but effectively persistent because registration, teardown, or image hygiene is inconsistent.

Vendor research from the The State of Secrets Sprawl 2026 report found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which reinforces a simple point: the attacker may prefer the pipeline because it is both trusted and reusable. For deeper threat context, Anthropic’s first AI-orchestrated cyber espionage campaign report is a reminder that automated abuse increasingly targets the systems that can keep acting on behalf of an adversary.

Related resources from NHI Mgmt Group

• How do security teams know whether a web server compromise is likely to become a major incident?
• How do security teams know whether a package advisory has created real identity exposure?
• How do security teams know whether Linux post-compromise controls are actually working?
• How do security teams know whether WSUS exploitation is progressing to full compromise?