Has compromised trusted CI/CD pipelines by injecting credential-stealing payloads into legitimate workflows and software packages including open-source security tools Trivy and KICS, and AI gateway LiteLLM.122345677891011121314
Poisoned Pipeline Execution T1677
- Tactic
- Execution
- Platform
- SaaS
- Version
- 1.0
- Created
- 22 May 2025
- Last modified
- 12 May 2026
- Contributor
- Arun Seelagan, CISA
Adversaries may manipulate continuous integration / continuous development (CI/CD) processes by injecting malicious code into the build process. There are several mechanisms for poisoning pipelines:
Poisoned Pipeline Execution MITRE reference T1677
1 group has been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
All 1 groups for this technique
3 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Has utilized Github Actions to propagate through the use of triggered workflows.123
Has leveraged stolen tokens from Trivy users to publish itself across over 46 npm packages.12
Has also leveraged GitHub actions from stolen accounts in order to create a malicious Github workflow within .github/workflows/discussion.yaml.1234
All 3 software entries for this technique
Offense vs defense T1677
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
Poisoned Pipeline Execution detection strategy DET0533
MITRE names one behaviour worth catching for this technique and breaks it into 1 analytic, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Poisoned Pipeline Execution via SaaS CI/CD Workflows
AN1473 · SaaS
Detects anomalous CI/CD workflow execution originating from forked repositories, with pull request (PR) metadata or commit messages containing suspicious patterns (e.g., encoded payloads), coupled with the use of insecure pipeline triggers like pull_request_target or excessive API usage of CI/CD secrets. Correlation with unusual artifact generation or secret exfiltration via encoded or external network destination URLs confirms suspicious behavior.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Cloud Storage AccessDC0025 | saas:github | Artifact generated includes base64/encoded exfil payload or URL |
| File MetadataDC0059 | saas:RepoEvents | New file added or modified in PR targeting CI/CD or build config (e.g., `gitlab-ci.yml`, `build.gradle`, `pom.xml`, `.github/workflows/*.yml`) |
| Command ExecutionDC0064 | saas:PRMetadata | Commit message or branch name contains encoded strings or payload indicators |
| Cloud Service ModificationDC0069 | saas:github | Workflow triggered via pull_request_target from forked repo |
| Cloud Service MetadataDC0070 | saas:github | CI/CD secret accessed or exported |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TimeWindow | Time delta between PR creation and workflow execution to flag rapid attempts |
| UserContext | Forked or external user accounts triggering workflows; may differ across orgs |
| TriggerTypeAllowlist | CI trigger types (e.g., pull_request_target) that should or shouldn't be used for forks |
| ArtifactEntropyThreshold | Entropy threshold for detecting encoded payloads in artifacts |
| SecretAccessRateThreshold | Rate of secret access in a single workflow run that might indicate abuse |
Where possible, avoid allowing pipelines to run unreviewed code. Where this is necessary, ensure that these pipelines are executed on isolated nodes without access to secrets. In GitHub, avoid using the pull_request_target trigger if possible, do not treat user-controlled inputs (such as branch names) as trusted, and do not use self-hosted runners on public repositories.
Ensure that CI/CD pipelines only have permissions they require to complete their operations. Additionally, limit the number of users who have write access to internal repositories to only those necessary.