Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1677: Poisoned Pipeline Execution

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: * In a Direct Pipeline Execution scenario, the threat actor directly modifies the CI configuration file (e.g., `gitlab-ci.yml` in GitLab). They may include a command to exfiltrate credentials leveraged in the build process to a remote server, or to export them as a workflow artifact.[1][2] * In an Indirect Pipeline Execution scenario, the threat actor injects malicious code into files referenced by the CI configuration file. These may include makefiles, scripts, unit tests, and linters.[2] * In a Public Pipeline Execution scenario, the threat actor does not have direct access to the repository but instead creates a malicious pull request from a fork that triggers a part of the CI/CD pipeline. For example, in GitHub Actions, the `pull_request_target` trigger allows workflows running from forked repositories to access secrets. If this trigger is combined with an explicit pull request checkout and a location for a threat actor to insert malicious code (e.g., an `npm build` command), a threat actor may be able to leak pipeline credentials.[1][3] Similarly, threat actors may craft pull requests with malicious inputs (such as branch names) if the build pipeline treats those inputs as trusted.[4][5][6] Finally, if a pipeline leverages a self-hosted runner, a threat actor may be able to execute arbitrary code on a host inside the organization’s network.[7] By poisoning CI/CD pipelines, threat actors may be able to gain access to credentials, laterally move to additional hosts, or input malicious components to be shipped further down the pipeline (i.e., Supply Chain Compromise).
EnterpriseT1677TechniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Poisoned Pipeline Execution matters because CI/CD systems often sit at the point where source code, secrets, build artifacts, and deployment authority converge. If an adversary can influence a SaaS build workflow through direct CI configuration changes, referenced scripts/tests, or unsafe pull request behavior, the incident may become more than a code issue: it can expose credentials, affect release integrity, and create downstream supply-chain risk.

Executive priority

Treat this as a software delivery and identity-risk control area, not only an application security concern. Leaders should ask whether CI/CD secrets, workflow triggers, pull request handling, and self-hosted runner exposure are governed with the same rigor as production access. This technique supports prioritizing controls that protect business continuity, audit evidence for secure release processes, and incident response readiness when build pipelines or artifacts are suspected of compromise.

Technical view

The ATT&CK object is an Enterprise execution technique on SaaS platforms. With no official MITRE detection text provided, SOC and detection teams should validate coverage around CI/CD workflow changes, pull request-triggered builds, use of untrusted inputs in workflow commands, access to pipeline secrets, artifact creation, and runner behavior. Relationship context identifies DET0533 as a detection strategy for poisoned pipeline execution via SaaS CI/CD workflows, and mitigations M1018 User Account Management and M1054 Software Configuration as relevant control areas. ATT&CK also links software S9008 Shai-Hulud as using this technique in supply-chain repository and package contexts.

Likely telemetry

  • SaaS CI/CD audit logs for workflow creation, modification, approval, and execution
  • Repository events for pull requests, forks, branch names, workflow files, scripts, tests, linters, and makefiles
  • Pipeline job logs, command output, artifact publication, and secret-access events
  • Identity and access logs for repository accounts, service accounts, tokens, and credential use
  • Runner telemetry, especially for self-hosted runners, including job execution context and network access

Detection direction

  • Confirm that monitoring covers both direct CI configuration edits and indirect changes to files invoked by the pipeline.
  • Review workflows triggered by pull requests from forks, especially patterns where untrusted code or inputs can run with access to secrets.
  • Tune detections for suspicious secret exposure paths such as unexpected artifact creation, unusual environment variable handling, or outbound credential use from build jobs.
  • Correlate repository events with pipeline execution and identity logs; isolated code-change alerts may miss the execution context.
  • Account for false positives from legitimate workflow refactoring, new release automation, and dependency maintenance by requiring review context, actor history, and approval state where available.

Mitigation priorities

  • Apply least privilege to repository users, service accounts, and pipeline tokens in line with M1018 User Account Management.
  • Harden CI/CD software configuration in line with M1054, including safer workflow triggers, secret exposure limits, and reviewed application settings.
  • Require review and approval for workflow-file changes and sensitive pipeline behavior changes.
  • Reduce trust in pull request inputs and fork-originated code before granting access to secrets or privileged runners.
  • Assess self-hosted runner placement and permissions because pipeline execution may provide access to internal hosts if runners are exposed.
Analyst notes and limits

The highest-value validation is whether the organization can reconstruct who changed pipeline-relevant files, what workflow ran, what secrets or artifacts were touched, and whether any runner executed untrusted code. This technique is especially material for organizations where CI/CD systems can publish packages, deploy software, or access production-adjacent credentials.

MITRE provides no official detection text for this technique in the supplied fields, so detection guidance is derived from the official description, external references, and the DET0533 relationship context. Local CI/CD platform configuration, repository policy, runner architecture, and secret-management design are required to determine actual exposure or coverage.

Official MITRE ATT&CK definition

Poisoned Pipeline Execution

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: * In a Direct Pipeline Execution scenario, the threat actor directly modifies the CI configuration file (e.g., `gitlab-ci.yml` in GitLab). They may include a command to exfiltrate credentials leveraged in the build process to a remote server, or to export them as a workflow artifact.[1][2] * In an Indirect Pipeline Execution scenario, the threat actor injects malicious code into files referenced by the CI configuration file. These may include makefiles, scripts, unit tests, and linters.[2] * In a Public Pipeline Execution scenario, the threat actor does not have direct access to the repository but instead creates a malicious pull request from a fork that triggers a part of the CI/CD pipeline. For example, in GitHub Actions, the `pull_request_target` trigger allows workflows running from forked repositories to access secrets. If this trigger is combined with an explicit pull request checkout and a location for a threat actor to insert malicious code (e.g., an `npm build` command), a threat actor may be able to leak pipeline credentials.[1][3] Similarly, threat actors may craft pull requests with malicious inputs (such as branch names) if the build pipeline treats those inputs as trusted.[4][5][6] Finally, if a pipeline leverages a self-hosted runner, a threat actor may be able to execute arbitrary code on a host inside the organization’s network.[7] By poisoning CI/CD pipelines, threat actors may be able to gain access to credentials, laterally move to additional hosts, or input malicious components to be shipped further down the pipeline (i.e., Supply Chain Compromise).

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Associated objects

Groups, software, and campaigns

Malware Enterprise

S9008: Shai-Hulud

Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]

LinuxSaaSWindows
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1018: User Account Management Enterprise uses · Malware S9008: Shai-Hulud Enterprise mitigates · Mitigation M1054: Software Configuration Enterprise detects · Detection Strategy DET0533: Detection Strategy for Poisoned Pipeline Execution via SaaS CI/CD Workflows Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Mitigation Enterprise

M1054: Software Configuration

Software configuration refers to making security-focused adjustments to the settings of applications, middleware, databases, or other software to mitigate potential threats. These changes help reduce the attack surface, enforce best practices, and protect sensitive data. This mitigation can be implemented through the following measures:

Conduct a Security Review of Application Settings:

- Review the software documentation to identify recommended security configurations. - Compare default settings against organizational policies and compliance requirements.

Implement Access Controls and Permissions:

- Restrict access to sensitive features or data within the software. - Enforce least privilege principles for all roles and accounts interacting with the software.

Enable Logging and Monitoring:

- Configure detailed logging for key application events such as authentication failures, configuration changes, or unusual activity. - Integrate logs with a centralized monitoring solution, such as a SIEM.

Update and Patch Software Regularly:

- Ensure the software is kept up-to-date with the latest security patches to address known vulnerabilities. - Use automated patch management tools to streamline the update process.

Disable Unnecessary Features or Services:

- Turn off unused functionality or components that could introduce vulnerabilities, such as debugging interfaces or deprecated APIs.

Test Configuration Changes:

- Perform configuration changes in a staging environment before applying them in production. - Conduct regular audits to ensure that settings remain aligned with security policies.

*Tools for Implementation*

Configuration Management Tools:

- Ansible: Automates configuration changes across multiple applications and environments. - Chef: Ensures consistent application settings through code-based configuration management. - Puppet: Automates software configurations and audits changes for compliance.

Security Benchmarking Tools:

- CIS-CAT: Provides benchmarks and audits for secure software configurations. - Aqua Security Trivy: Scans containerized applications for configuration issues.

Vulnerability Management Solutions:

- Nessus: Identifies misconfigurations and suggests corrective actions.

Logging and Monitoring Tools:

- Splunk: Aggregates and analyzes application logs to detect suspicious activity.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
ae1c3d3184a4a00c...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle ae1c3d3184a4…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Unit 42 Palo Alto GitHub Actions Supply Chain Attack 2025

    Omer Gilm Aviad Hahami, Asi Greenholts, and Yaron Avital. (2025, March 20). GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident: Threat Assessment . Retrieved May 22, 2025.

    Open source URL
  2. [2]
    OWASP CICD-SEC-4

    OWASP. (n.d.). CICD-SEC-4: Poisoned Pipeline Execution (PPE). Retrieved May 22, 2025.

    Open source URL
  3. [3]
    GitHub Security Lab GitHub Actions Security 2021

    Jaroslav Lobačevski. (2021, August 3). Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests. Retrieved May 22, 2025.

    Open source URL
  4. [4]
    Wiz Ultralytics AI Library Hijack 2024

    Wiz Threat Research. (2024, December 9). Ultralytics AI Library Hacked via GitHub for Cryptomining. Retrieved May 22, 2025.

    Open source URL
  5. [5]
    Synactiv Hijacking GitHub Runners

    Hugo Vincent. (2024, May 22). Hijacking GitHub runners to compromise the organization. Retrieved May 22, 2025.

    Open source URL
  6. [6]
    GitHub Security Labs GitHub Actions Security Part 2 2021

    Jaroslav Lobačevski. (2021, August 4). Keeping your GitHub Actions and workflows secure Part 2: Untrusted input. Retrieved May 22, 2025.

    Open source URL
  7. [7]
    John Stawinski PyTorch Supply Chain Attack 2024

    John Stawinski IV. (2024, January 11). Playing with Fire – How We Executed a Critical Supply Chain Attack on PyTorch. Retrieved May 22, 2025.

    Open source URL
  8. [8]
    mitre-attack T1677
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use