Look for newly created workflow files, unexpected package version changes, suspicious repository visibility changes, and secrets that appear to have been accessed outside normal build or deployment activity. Abnormal automation is often the clearest sign because the attacker tries to blend into ordinary CI/CD behaviour.
What secrets-theft warning signs look like in a supply chain compromise
In a software supply chain attack, the earliest clue is often not an obvious alert, but a change in developer workflow, build behaviour, or repository state that should not be there. Secrets theft usually shows up as abnormal automation, altered package or action content, or evidence that credentials were touched outside the expected CI/CD path.
Watch for newly created workflow files, unexpected package version changes, repository visibility changes, and secret access patterns that do not line up with normal builds, releases, or deployment jobs. Those signals matter because supply chain intrusions are designed to blend into routine automation and look like ordinary maintenance.
A useful way to think about the warning signs is to separate them into three buckets: source control changes, pipeline behaviour, and secret usage. Source control changes include tampering with workflow definitions, release scripts, or package metadata. Pipeline behaviour includes unusual job triggers, new outbound connections, or logs that suddenly expose environment values. Secret usage includes keys, tokens, or credentials being used from unfamiliar runners, timestamps, or IP ranges.
Some of the strongest indicators are indirect. For example, if a package suddenly changes maintainers, an action tag is retagged, or a dependency update arrives with no corresponding release discipline, treat that as a potential access-path change rather than a normal software update. In many incidents, the attacker first compromises the build or publishing path, then uses that trust to reach secrets that were never meant to leave the pipeline.
Abnormal automation is especially important because it can be the attacker’s camouflage layer. A workflow that starts running at odd times, a CI job that did not previously need secret access, or a publishing step that appears after a seemingly harmless dependency change all deserve immediate review. The point is not just that automation changed, but that the change may have expanded the path to secrets without an explicit business reason.
Risk and Threat Considerations
Secrets theft in a supply chain attack is dangerous because the attacker often inherits trusted automation, not just a single credential. That can turn one compromise into code signing abuse, repository tampering, package poisoning, or access to downstream SaaS and cloud services that trust the stolen secret.
Failure mechanism: The attacker compromises a maintainer token, CI runner, action, package, or dependency path, then uses that trusted channel to read, print, or reuse secrets that were available to the build or release process. Because the activity occurs inside expected automation, it can bypass normal human review.
Impact: Once a secret is exposed, the blast radius depends on what it can reach, including source repositories, package registries, production systems, third-party services, and signing workflows. The result can be persistence, silent tampering, data exfiltration, or a second-stage supply chain compromise.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Covers compromise of software delivery paths that enables secret theft. |
| Recommendation — Map suspicious build or dependency changes to supply-chain compromise and hunt for exposed secrets. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Relevant because workflow, package, and CI/CD changes often reveal insecure software configuration and tampering. |
| Recommendation — Harden CI/CD and repository settings so unexpected workflow or package changes are blocked or alerted. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Supports detection of unusual secret use, workflow execution, and repository activity through log review. |
| CM-5 — Access Restrictions for Change | Applies because unauthorized workflow or package changes are a key supply-chain warning sign. | |
| IA-5 — Authenticator Management | Directly applies when stolen tokens, keys, or secrets are the abuse path in the attack. | |
| Recommendation — Review CI/CD and repository logs for anomalous secret access and automation changes. Restrict who can modify workflows, release paths, and package metadata. Rotate, revoke, and scope exposed secrets quickly when compromise is suspected. | ||
Practitioner Guidance
What to verify: Confirm whether the suspicious workflow, package update, or repository change had a documented release reason, a known owner, and an approved change path. If the answer is unclear, treat the event as a potential credential exposure rather than a simple CI anomaly.
Decision rule: If a secret could authenticate outside the build system, prioritise revocation, rotation, and blast-radius assessment before spending time on deep root-cause analysis. If the secret was only exposed in logs but can still be reused, handle it as compromised.
What to measure: Track whether secrets are being accessed only from expected runners, jobs, and time windows. The practical signal is not just volume, but whether use patterns match the normal software delivery path.
Practitioner takeaway: The most useful mindset is to treat unexpected automation as a possible secret-exfiltration path until proven otherwise, because supply chain attacks usually succeed by borrowing the legitimacy of the pipeline.
Related resources from NHI Mgmt Group
- What are the signs that a software supply chain attack through GitHub may already be in progress?
- What are the signs that a software supply chain attack may have gone undetected for too long?
- What are the signs that a package supply chain attack has reached credential theft stage?
- What are the signs that a package-based supply chain attack has moved from theft to persistence?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org