Watch for unexpected workflow file edits, unusual package publication, sudden repository write activity, atypical PAT use and secret-manager access spikes. Those signals show the campaign is moving from compromise into propagation. The key is to correlate developer identity events with CI/CD and cloud access patterns.
When identity boundaries start to fail in a supply-chain campaign
The crossing point is usually not a single event, but a cluster of identity and access anomalies that show the attacker has moved from tampering with code or packages into operating with legitimate developer, CI/CD, or cloud privileges. Once that happens, the campaign can propagate using trusted workflows, signed-in tooling, and automated release paths rather than noisy malware-style behaviour.
A useful way to read the signals is to ask whether the activity is still isolated to a package or repository, or whether it has begun to reuse credentials, tokens, and automation rights that belong to another boundary.
For a practical threat lens on how supply-chain abuse maps to adversary tradecraft, compare the observed behaviour with the MITRE ATT&CK Enterprise Matrix, especially where the activity shifts toward credential access, privilege escalation, and lateral movement.
The identity signals that matter most
The strongest signs are those that connect repository change activity to identity behaviour that should not normally co-move. Unexpected workflow file edits are especially important because they can change who gets secrets, which jobs run, and where output is published. Unusual package publication, sudden repository write activity, and atypical PAT use all point to the same thing: the attacker is trying to turn a compromised account into a propagation mechanism.
Secret-manager access spikes are another high-value indicator because they show the campaign is no longer just touching source control. It is now reaching into the systems that mint or broker access, which often means the attacker is preparing persistence, broadening blast radius, or harvesting more identities for the next hop.
For background on why these signs map so strongly to non-human identity misuse, the Ultimate Guide to NHIs, What are Non-Human Identities is useful because it frames the credentialed actors that often sit behind build, publish, and deployment automation. For lifecycle and ownership issues that make these signals easier to miss, the NHI Lifecycle Management Guide helps explain why stale access, weak rotation, and poor offboarding create propagation paths.
When the campaign is using package registries or developer tokens to spread, the pattern also aligns with the supply-chain controls discussed in AI Supply Chain Security and AI-BOM Guide, even if the immediate target is not an AI system. The underlying lesson is the same, provenance and credential containment matter once trust is being reused across environments.
What crossing the boundary looks like in practice
The boundary-crossing moment often appears when a legitimate identity starts performing actions that are technically valid but behaviourally wrong for that role. A developer PAT touching package publication, a CI token writing back to a repository, or a secret manager being queried by an unusual workflow is more meaningful than a generic scan alert. Those actions indicate the attacker is leveraging trust already granted to a person or automation account.
At that stage, the question is no longer only “was a package compromised?” It becomes “which identities now have authority to push the compromise into the next system?” That is why correlation matters: developer identity events, CI/CD events, and cloud access logs should be read together, not as separate queues. If the same actor is touching code, publishing artifacts, and requesting secrets, the campaign has probably crossed from compromise into propagation.
For a more concrete view of how stolen maintainer access turns into release abuse, see Solana web3.js npm compromise 2024. If you want an example of a token being used to turn an ordinary action into secret exposure, reviewdog Action compromise 2025 shows how one poisoned workflow can open the door to broader CI secret leakage.
Risk and Threat Considerations
Once propagation crosses identity boundaries, the main risk is that trusted automation becomes the delivery channel for wider compromise. That can move the incident from one repository or package to many downstream systems, especially when the same identity can publish artifacts, read secrets, and trigger deployments.
Failure mechanism: An attacker abuses a legitimate account, token, or workflow trust path to reuse permissions across repositories, build systems, and cloud services, turning normal automation into a propagation engine.
Impact: Blast radius expands quickly, because every trusted downstream system may accept the attacker’s actions as routine. That increases the chance of secret theft, persistence, malicious releases, and repeated compromise after cleanup.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078 — Valid Accounts | Cross-boundary propagation often uses stolen developer or CI identities. |
| T1552 — Unsecured Credentials | PATs, tokens, and secret-manager access spikes indicate credential abuse. | |
| Recommendation — Correlate valid-account use with repo and cloud activity to spot propagation. Hunt for exposed or misused credentials feeding supply-chain spread. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Correlation across developer, CI/CD, and cloud logs is central to detecting boundary crossing. |
| IA-5 — Authenticator Management | PAT use and secret handling depend on strong lifecycle control and rotation. | |
| AC-6 — Least Privilege | Propagation accelerates when one identity can write, publish, and read secrets. | |
| Recommendation — Review and correlate identity and pipeline logs for anomalous cross-boundary actions. Rotate and revoke tokens promptly when anomalous publish or write activity appears. Separate publish, write, and secret access rights to reduce blast radius. | ||
Practitioner Guidance
What to verify: Check whether the same identity can both change pipeline logic and reach publication or secret-handling paths. If it can, treat that as a propagation-ready boundary and review it before looking for deeper payload effects.
Decision rule: If the suspicious action involves a token, workflow, or service account that can write code, publish artifacts, or read secrets, prioritise containment and credential rotation over narrow package-level triage.
What good looks like: Repository write access, package publish rights, and secret-manager access should be separable enough that one compromised identity does not automatically unlock the next stage of propagation.
Practitioner takeaway: The crossing signal is not just malicious content, it is malicious authority. When identity events and CI/CD or cloud access move together, assume the attacker is already using legitimate trust to spread.
Related resources from NHI Mgmt Group
- How do attackers turn a supply-chain incident into wider NHI compromise?
- What are the signs that machine identity sprawl is becoming a supply chain risk?
- What are the signs that a software supply chain identity is being abused?
- What signs suggest a supply chain worm is using build identities for propagation?