What signs suggest a supply chain worm is using build identities for propagation?

How Build Identities Become a Propagation Path

A supply chain worm does not need to break every control at once. It often starts by abusing build identities, the credentials and trust granted to CI systems, runners, publish jobs, or automation accounts, then uses that trust to publish, commit, or distribute the next malicious step. The key question is whether the build path is acting like a normal delivery pipeline or an automated propagation channel.

Watch for changes that are operationally “plausible” but behaviorally wrong, especially when they occur from build infrastructure rather than a human maintainer workstation. Unexpected package publication, repository creation, dependency edits, or branch activity can all be legitimate in isolation, but together they can indicate that a build identity has been turned into a replication mechanism.

• Unexpected package publication from a CI job or release runner is a strong propagation signal when it does not line up with a normal release process.
• Unauthorized repository creation or new branches appearing from automation accounts can indicate the worm is staging its next hop.
• Suspicious dependency updates that introduce new install-time behavior, scripts, or hidden fetches often show the payload is being propagated through ordinary development workflows.

Signals get stronger when the activity appears across multiple projects, package namespaces, or build environments. A single unusual commit may be noise; repeated publication and secret access from the same build context is more consistent with an automated spread pattern.

Why the Build Identity Trail Matters

Build identities are attractive because they sit at a high-trust junction: they can read source, produce artifacts, access publishing systems, and often reach secrets that developers never see directly. That makes them ideal for a worm that wants both execution and distribution. When the build system itself starts making the change set, the attacker has moved from theft into replication.

Compare the source of the action with the expected actor. If a release should come from a human-reviewed tag or a protected pipeline and instead appears from a transient runner, a service principal, or another automation context, the provenance is suspicious. In this setting, provenance and trust boundaries matter as much as the content of the payload.

Repeated secret access from build environments is especially important because it suggests the worm is not just stealing one token and leaving. It may be harvesting additional credentials to keep moving, widening its reach, or refreshing access after revocation. That pattern is a propagation clue, not just a compromise clue.

What Distinguishes Propagation from a One-Off Theft

A one-off theft usually focuses on extracting value quietly. A worm that uses build identities tends to leave a broader operational footprint because it must keep moving through the software delivery chain. The compromise may show maintenance-like noise, such as small commits, branch churn, dependency bumps, or release artifacts that look routine but arrive on an abnormal cadence.

Look for combinations, not isolated events. Unexpected publication plus secret reads plus repository activity is more telling than any one item on its own. If the same automation path is generating new releases while also touching credentials or dependencies it should not need, the better assumption is propagation until proven otherwise.

That distinction affects triage. Treat the build identity as the likely blast-radius center and ask whether it can reach signing keys, package registries, source repositories, or downstream deploy systems. If yes, the risk is not confined to one repository; it may already span the software supply chain.

Risk and Threat Considerations

A build identity that can publish code and access secrets can turn a single compromise into wide distribution. The main risk is that trusted automation carries malicious changes farther and faster than a human attacker could, while appearing operationally normal to routine monitoring.

Failure mechanism: The worm abuses CI or release credentials to publish tampered artifacts, open or alter repositories, and reuse secret-bearing build contexts to keep propagating through the supply chain.

Impact: Downstream consumers may ingest malicious packages, build outputs, or dependency updates before the compromise is recognized, expanding exposure across projects and environments.

Practitioner Guidance

What to verify: Correlate package publication, repository creation, commit history, and secret-access logs against the expected release process. If build identities are performing actions that should be reserved for maintainers, treat the pipeline as suspect.

Decision rule: If the same automation context is both changing artifacts and reading sensitive material, prioritize containment of the build identity and revocation of its reach before deciding whether the payload was only a single malicious release.

What good looks like: Releases are attributable to a bounded, reviewed workflow, and build accounts have only the minimum access needed to publish artifacts, not broad reuse across repositories or environments.

Practitioner takeaway: The most important signal is not just that something was published, but that automation was able to propagate it using the same trust path that normally delivers legitimate software.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why do automated build identities increase supply chain compromise risk?
• How can security teams reduce risk from supply-chain identities and build tokens?
• What signs suggest a supply chain attack is moving faster than detection tools?