How do security teams detect malicious software delivery when the code looks legitimate?

By looking at identity behaviour and build artefacts together. Check for unusual Unicode, unexpected publishing patterns, token use from abnormal environments, and releases that do not match historical workflow behaviour. A clean diff is not enough if the underlying identity activity is anomalous.

Why This Matters for Security Teams

Malicious software delivery is hardest to spot when the package, commit, or release artifact appears legitimate. Attackers increasingly hide in the same places engineering teams trust most: source control, CI/CD, package registries, signing workflows, and automated publishing accounts. That means a clean diff or a familiar repository name is not enough. Security teams need to inspect identity behaviour, build provenance, and release timing together, because abuse often shows up as a workflow anomaly rather than obvious code tampering.

The risk is amplified by the fact that NHIs are routinely over-privileged and poorly rotated. NHIMG research shows 97% of NHIs carry excessive privileges, while 71% are not rotated within recommended time frames, making compromised publishing identities a reliable path to malicious delivery. That pattern is also visible in the Ultimate Guide to NHIs – Key Challenges and Risks and the CI/CD pipeline exploitation case study. Practitioners should treat the publisher, the pipeline, and the artifact as one security story, not three separate checks.

In practice, many security teams discover malicious delivery only after a trusted release has already reached production or downstream customers.

How It Works in Practice

Detection works best when it combines artifact inspection with identity telemetry and build-system provenance. Start by validating whether the publishing identity behaved normally: did the token originate from the expected environment, at the expected time, and with the expected build context? Did the release come from the usual runner, branch, and workflow path? These questions matter because attackers can make code look routine while using stolen credentials or hijacked automation to publish it.

Security teams should correlate four signals:

• Identity behaviour, including token use from new geographies, unusual user agents, or nonstandard CI runners.
• Build artefacts, including Unicode anomalies, unexpected dependency changes, altered signing metadata, and mismatched checksums.
• Release workflow patterns, including unusual publishing times, skipped approvals, or a branch-to-release path that differs from history.
• Provenance and attestations, including whether the artifact can be traced back to a known build recipe and trusted identity.

This maps well to current guidance in the NIST Cybersecurity Framework 2.0, especially when teams operationalize detection across asset visibility, anomaly monitoring, and response. It also aligns with the NHI Lifecycle Management Guide, because the same identity that publishes software must also be onboarded, monitored, and retired like any other privileged workload identity.

A useful operational pattern is to baseline the normal publishing rhythm for each maintainer, pipeline, and repository, then alert on deviations that combine identity drift with artifact drift. Single signals are noisy; the combination is what separates legitimate release variation from malicious delivery attempts. These controls tend to break down in highly decentralized open-source ecosystems because trusted maintainer workflows, mirrored repositories, and automated release bots create too many valid exceptions.

Common Variations and Edge Cases

Tighter release control often increases engineering overhead, requiring organisations to balance delivery speed against stronger verification. That tradeoff is real, especially when teams depend on frequent automation, ephemeral runners, or external contributors.

One common edge case is signed malware. A valid signature does not prove benign intent if the signer identity was compromised or if a legitimate maintainer account was abused. Another is dependency confusion or package squatting, where the artifact appears correct but the publishing identity is the real indicator of compromise. Guidance here is evolving, but current practice suggests that code scanning alone is insufficient without identity and provenance checks.

Teams should also be careful with false positives in high-velocity environments. Short-lived tokens, temporary branches, and automated release jobs can resemble attacker activity unless the baseline is tuned to each pipeline. The strongest programs use policy around Top 10 NHI Issues to ensure credentials are rotated, scoped tightly, and monitored continuously, while extending the same discipline to build identities and signing keys. For supply-chain focused teams, the right question is not only whether the code looks clean, but whether the identity and release path look normal for that artifact.

Related resources from NHI Mgmt Group

• How should security teams detect AI-generated social engineering that looks legitimate?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams reduce risk in software delivery pipelines with NHI controls?