Notifications
Clear all
Topic starter
01/08/2026 10:51 pm
TL;DR: CI/CD supply-chain attacks are now being iterated by LLMs that can vary shells, paths, and C2 strings fast enough to evade static rules, while attackers still pivot from exposed secrets to monetisation in minutes, according to Mate. The defender problem is no longer rule volume but compressing time from compromise to containment.
NHIMG editorial — based on content published by Mate: LLMjacking and the rise of LLM-assisted CI/CD supply-chain attacks
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone
- 64% of valid secrets leaked in 2022 are still valid and exploitable today
Questions worth separating out
Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?
A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once.
Q: Why do leaked tokens and API keys create such a large blast radius in pipelines?
A: Leaked tokens and API keys are often privileged across build, publish, and cloud services, so one secret can open multiple control planes.
Q: How do teams know if agentic CI/CD controls are actually working?
A: Look for evidence that the agent cannot reach secrets, cannot mutate protected branches, and cannot execute shell commands outside its declared boundary.
Practitioner guidance
- Map pipeline identities and publishing privileges Document every service account, token, API key, and maintainer credential that can publish, deploy, or sign artifacts.
- Move secrets out of build-time files Eliminate secrets stored in .env files, image layers, and repository metadata.
- Correlate secret-use signals with CI/CD telemetry Send vendor secret-scanning alerts, package publishing events, and cloud audit logs into the same detection path so one compromise is linked to the next.
What's in the full article
Mate's full analysis covers the operational detail this post intentionally leaves for the source:
- Command-by-command comparisons of the original and retooled attack variants, useful for detection engineering and hunt tuning.
- Illustrative telemetry from Mate AI SOC agents showing how the same campaign was linked across multiple attempts and environments.
- Operational examples of agentic SOC workflow, including how the system triaged suspicious activity and correlated it to prior package abuse.
- Named indicators of compromise and package-specific artifacts that help practitioners validate their own detections.
👉 Read Mate's analysis of LLM-assisted CI/CD supply-chain attacks →
LLM-assisted CI/CD attacks: is your detection keeping up?
Explore further
01/08/2026 10:59 pm
LLM-assisted supply-chain abuse is turning CI/CD into an identity problem, not just a malware problem. The article shows that stolen tokens, build secrets, and maintainer access now function as the true attack surface. That means identity governance must extend into pipelines, package publishing, and runtime secret use, not stop at human accounts. Practitioners should treat CI/CD identities as first-class governance objects.
A question worth separating out:
Q: Who is accountable when a stolen maintainer account pushes malicious packages?
A: Accountability sits with both the project maintainers and the organisation operating the publishing identity. Teams should define who owns package release rights, who can revoke them, and how quickly compromised publisher access can be removed. That governance belongs in access review and offboarding processes.
👉 Read our full editorial: LLM-assisted CI/CD attacks are outpacing static detection
