Why do published packages and CI/CD telemetry need to be hunted together?

Why hunt package telemetry and CI/CD telemetry as one trail?

Published package activity and CI/CD activity describe the same trust chain from different angles. Package telemetry shows what was released, signed, or swapped; pipeline telemetry shows who or what could publish it, when the artefact moved, and where it was deployed. Hunting them together closes the gap between identity abuse, release tampering, and downstream execution.

That matters because a package compromise is often only obvious once a build, install, or deploy event appears in the pipeline. A version bump without the matching publishing event, or a build from an unexpected runner or account, is often the first reliable sign that a trusted artefact has been abused.

What each telemetry stream contributes to the hunt

Published package telemetry answers artefact questions: which version exists, when it changed, whether metadata or maintainers changed, and whether the release path looks legitimate. CI/CD telemetry answers control-path questions: which identity published, which job signed or uploaded, which token was used, and whether the pipeline that handled the release followed the expected workflow. Used together, they let you connect package integrity to operational identity and execution evidence.

The joint view is especially useful when the compromise is subtle. An attacker may never touch the endpoint you monitor, but they can still steal a publishing token, alter a package version, or inject a malicious workflow step. One dataset alone may show an anomaly; the pair shows whether the anomaly is benign drift, credential abuse, or a real supply-chain intrusion.

For this reason, teams should treat package registry logs, build logs, signing events, and deployment telemetry as one investigative set. A package that appears trustworthy in the registry but arrives through an abnormal pipeline path is materially different from a package that was both published and deployed through known-good controls.

How to correlate the signals without overcalling noise

Good correlation starts with three joins: artefact identity, publishing identity, and deployment identity. When those three do not line up, the hunt should ask whether the mismatch reflects a legitimate release process, a delegated automation account, or a compromised publishing path. That triage is stronger than either feed on its own.

• Match version, checksum, and signing metadata from the package source to the build artefact seen in CI/CD.
• Compare the publishing account, token, or runner identity with the identity normally used for releases.
• Check whether the first install or deployment of the artefact came from the expected pipeline, branch, or environment.

When package telemetry and pipeline telemetry disagree, the disagreement itself is often the signal. A release that exists in the registry but has no corresponding approved pipeline event, or a pipeline that published an unexpected version, deserves immediate review.

Risk and Threat Considerations

Published packages and CI/CD systems are attractive because they combine trust, reach, and speed. If an attacker steals a publishing credential or poisons a pipeline, one action can turn into widespread downstream installation or deployment across many environments.

Failure mechanism: The attacker abuses a publishing identity, release token, or pipeline secret to swap a trusted artefact or push a malicious one, while the endpoint remains clean enough to avoid simple host-based detection.

Impact: Defenders miss the change until the artefact is installed, signed, or deployed, which increases blast radius, delays containment, and can put production systems, secrets, and dependent customers at risk.

Practitioner Guidance

What to verify: Treat package publication and CI/CD execution as one control surface. Before trusting a release, verify that the publishing identity, the build runner, the artefact hash, and the deployment event all line up with the expected release path.

Decision rule: If you can prove the package changed but cannot prove the publishing path, assume the investigation is incomplete. If the pipeline shows suspicious publishing activity, prioritise artefact lineage and credential review before endpoint searching.

What good looks like: A defensible hunt can answer, from telemetry alone, who published the package, how it was built, which pipeline moved it, and where it was installed. If any of those answers depend on guesswork, the trust chain is still open.

Practitioner takeaway: The strongest supply-chain hunts do not ask whether the package or the pipeline is suspicious in isolation, they test whether the artefact, the identity, and the deployment path agree.

Related resources from NHI Mgmt Group

• How should teams respond when CI or developer secrets are exposed?
• What breaks when malicious npm packages execute during CI/CD installs?
• What breaks when a CI/CD workflow can publish packages and access secrets at the same time?
• Who is accountable when a CI/CD token is used to publish poisoned packages?