What are the signs that a malicious package has persisted in CI/CD workflows?

How a malicious package can stay active after the package is removed

A package compromise does not always end when the artifact is deleted or replaced. In CI/CD, the attacker can leave behind workflow edits, trigger changes, or secret-exfiltration logic that keeps firing every time the pipeline runs. The key question is whether the malicious behaviour has moved from the package itself into the automation around it.

That persistence usually means the package was only the entry point. Once the workflow, runner, or build configuration is altered, later builds can keep executing attacker-controlled steps even after maintainers believe the dependency issue has been fixed.

Workflow changes that outlive the compromised package

The clearest sign is an unexpected change to the pipeline definition itself. Look for new jobs, altered steps, modified action references, or extra commands that were not part of the normal release process. If the malicious activity reappears after a package rollback, the attacker likely established a second foothold in the workflow layer.

This is especially concerning when the change does not obviously break the build. Attackers often add small, plausible edits that preserve functionality while introducing covert behaviour, such as downloading a payload, echoing environment data, or invoking an external endpoint during routine automation.

Repeated secret access, new triggers, and lingering abuse

Another strong indicator is secret access that does not match the pipeline’s normal purpose. If a job that should only test or package code begins reading deployment credentials, cloud keys, signing material, or token stores, treat that as post-compromise persistence rather than normal pipeline variation. In practice, the malicious logic may also be tied to a new trigger, so the workflow runs on events it never previously handled.

It is also a bad sign when the same suspicious behaviour appears across multiple runs after the package has been replaced. That pattern suggests the attacker planted logic in workflow files, reusable actions, runner state, or another automation dependency that still executes on schedule or on push.

Risk and Threat Considerations

A malicious package that persists in CI/CD is dangerous because the compromise can survive ordinary remediation. Removing the package may stop one infected artifact, but it does not neutralise a poisoned workflow, stolen token, or altered trigger that keeps granting access to secrets and build context.

Failure mechanism: The attacker uses package execution to modify pipeline code, runner state, or automation permissions, then relies on normal CI/CD runs to keep reactivating the payload after the original package is gone.

Impact: Teams can keep rebuilding a compromised trust path, which can expose secrets, contaminate signed artifacts, and create repeated opportunities for lateral movement or downstream supply-chain abuse.

Practitioner Guidance

What to verify: Compare the current workflow files, reusable actions, branch protections, and trigger rules against a known-good baseline. If a malicious package was involved, verify whether the attacker changed only the dependency or also touched pipeline logic, secrets scope, or runner configuration.

What to prioritise: Treat repeated secret access or repeatable malicious behaviour as a persistence problem, not a one-off package incident. Rotate any exposed credentials first, then inspect how those credentials were available to the pipeline in the first place.

What good looks like: The pipeline should execute only the approved steps, with no unexplained triggers, no unexpected secret reads, and no artefacts of attacker-controlled logic surviving after dependency replacement.

Practitioner takeaway: In CI/CD, persistence is often visible as a control-plane change, so the right response is to hunt the workflow and runner state, not just the package version.

Related resources from NHI Mgmt Group

• How should teams reduce risk from malicious npm package installs?
• What breaks when malicious workflows can read repository secrets in CI/CD pipelines?
• What should teams do after a malicious npm package has run in CI/CD?
• How should security teams reduce malicious package risk in CI/CD pipelines?