How poisoned pipeline execution hides inside trusted build jobs
For an attacker, T1677 Poisoned pipeline execution means running instructions through a build or deployment pipeline that the organization already trusts. The malicious work inherits the pipeline's identity, secrets, network reach and deployment rights, so it can look like the release team's normal output. ATT&CK places the technique under the Execution tactic (TA0002), where the adversary is trying to run malicious code or instructions on a system, and this page maps the technique to Enterprise ATT&CK 20.0. In intrusions, the activity usually follows an attacker gaining write access to something the pipeline reads, such as source code, pipeline definitions or shared build settings, and the execution happens later when a trusted job runs on its normal schedule.
The reason this hides well is that build systems run with privileged credentials, and their configuration changes often look like routine maintenance. A pipeline edit that adds one step to a job that already publishes artifacts can pass review because the diff is small and familiar. For the SOC lead, the first questions are organizational: who can edit pipeline definitions, whether those edits require an independent reviewer, and whether build jobs can reach production secrets or deployment targets at all. Confirm with the platform owners which SaaS CI/CD service is in use, whether its audit log records configuration changes with the actor's identity, and how long those audit events are retained.
Before any detection is written, decide what normal looks like for each pipeline. Record the owners, the expected triggers, the expected outbound destinations and the list of people allowed to approve changes to pipeline configuration. That baseline is what later detection work compares against, and it is also what an auditor will ask to see. Ask the platform team to confirm that pipeline audit events are exported to the central log store, not only kept inside the vendor console, so the SOC can correlate a configuration change with the build that ran afterward.
Which SaaS telemetry reveals a poisoned pipeline
This table maps the telemetry types named for T1677 to the signal defenders should look for and the open-source collector that gathers it. Read each row as a question to answer about your CI/CD and SaaS audit sources, and confirm with your platform team which audit logs each SaaS product exposes before writing rules. The main takeaway is that no single log source is enough, so pair pipeline run records with change and artifact evidence.
| Telemetry type | Signal to look for | Open-source collector |
|---|---|---|
| Command Execution (DC0064) | Pipeline job steps that run commands not present in the reviewed pipeline definition, or steps that differ between runs of the same workflow | Wazuh log collection from runner hosts, or syslog forwarding from self-hosted build agents |
| Cloud Service Modification | Edits to pipeline definitions, workflow files, or job configuration made outside the normal review path, including changes to trigger conditions | Wazuh or a SIEM ingest of SaaS admin audit logs, where the vendor exposes them |
| File Metadata | Pipeline artifacts or workflow files with unexpected modification times, authors, or signing state compared with the approved commit | Velociraptor file collection on build hosts, or Wazuh file integrity monitoring on runner workspaces |
| Application Log Content (DC0038) | Build log entries showing unexpected environment variable access, secret retrieval, or outbound calls from a job | Wazuh log decoders, or Security Onion ingest of SaaS application logs |
| File Creation (DC0039) | New script, binary, or configuration files written into a workspace during a pipeline run that were not produced by the build | Wazuh FIM or Velociraptor artifact collection on self-hosted runners |
| Process Creation (DC0032) | Child processes launched by the build agent that do not match the expected toolchain for that job | Wazuh and Sysmon-based endpoint telemetry on Windows runners, or auditd on Linux runners |
| Network Connection Creation (DC0082) | Runner egress to destinations not on the approved list for that pipeline, especially during secret-using steps | Zeek connection logs, monitored by Security Onion |
Detection logic for T1677 on SaaS build platforms
The cards below describe detection ideas for T1677 Poisoned pipeline execution on SaaS build platforms. Each idea watches a different point where an attacker's change could enter a build: the pipeline definition, the runner or job configuration, the secrets a job reads, and the artifacts it produces. Thresholds and baselines should be set per organization and tested against the platform's own audit logs before any alert is trusted.
Pipeline changes by unexpected identities
Alert when a pipeline definition, workflow file or build template is created or modified by an identity that has not previously changed it, or that falls outside the team that owns the repository. Learn a baseline of normal editors over 30 to 90 days, then flag first-time editors and changes merged without a reviewed pull request. Expect false positives from planned migrations, bulk refactors by platform teams and new service onboarding, so keep a dated change calendar that the rule can reference. Confirm with the vendor which audit events record definition edits and whether they include the actor and the source branch.
New or modified runner configuration
Watch for new self-hosted runners, changed runner labels, altered runner group access and jobs that start targeting a runner pool they never used before. A poisoned pipeline often moves work onto a runner that holds more network reach or credentials. Baseline the runner inventory and the job-to-runner mapping for each project, then alert on any new pairing. Tune the rule so that scheduled capacity changes from your infrastructure team are suppressed by ticket reference. Confirm which runner events each platform exposes in its audit log.
Secrets read by jobs that never used them
Track which jobs request each secret, variable group or cloud credential. Alert when a job that has not previously referenced a given secret requests it, especially when the request comes from a branch or fork that is not protected. Build the baseline from at least one full release cycle so that quarterly or seasonal jobs are included. Common false positives include onboarding of a new service, rotation jobs and shared deployment templates that were updated on purpose. Ask the platform team which secret access events are logged and whether they record the job and branch context.
Build outputs that differ from reviewed source
Compare the file metadata and hashes of produced artifacts with the reviewed source and with the previous build of the same version. Flag artifacts whose modification times, embedded build paths, signing identity or dependency lists change without a matching source change. Set a tolerance for reproducible-build noise such as timestamps and compiler versions, and record which fields are expected to vary. False positives come from toolchain upgrades and new base images, so tie those events to a change record. Confirm how your artifact registry stores provenance and whether file metadata is retained long enough to investigate.
How to prove the T1677 detections fire before an incident
This sequence turns T1677 detections from assumptions into recorded evidence by running a scoped, controlled pipeline change in a lab or cyber range and confirming each alert fires. The output is a dated test record that shows what was detected, what was missed and what must be re-tested after an ATT&CK version change.
Agree the emulation scenario with the platform owner
The security lead and the owner of the SaaS build or delivery platform agree in writing which pipeline, repository and service account the test will touch, and which expected behaviors count as a pass. The scenario should describe a conceptual change to a non-production pipeline definition, with no attack steps written out. The step is done when both parties sign the scope and name the people who can stop the test. Confirm that the platform's audit log and its pipeline change history are enabled in the lab tenant before work begins, since the test depends on them.
Map each expected signal to a data component
Before the test runs, the detection engineer lists each expected detection against the ATT&CK version the team targets, along with the data components it relies on, such as Command Execution, Cloud Service Modification and File Metadata. Each row names the log source, the Wazuh, Security Onion or Sigma rule that should fire and the analyst who will review it. The step is complete when every expected detection has a row and a named owner. Check the technique and detection strategy IDs against the current ATT&CK release, because detection mappings can change between versions.
Stage a controlled change in the lab tenant
In the lab or range, the platform owner makes a small, pre-approved change to a non-production pipeline definition, using the agreed service account and a labeled change request. The change is performed in the lab only, with no production secrets or live deployment targets involved. The step closes when the change is logged by the platform and the test start time is written into the test record. If the change reaches a system outside the agreed scope, the test stops and the scenario is reviewed before any retry.
Confirm each detection alerts and record evidence
The detection engineer checks the SIEM for each expected alert and records its timestamp, alert ID, rule name, the log events that triggered it and the analyst who triaged it. Time offsets between the platform event and the alert are noted so response timing can be measured later. An expected detection that does not fire is logged as a gap, not quietly re-run until it passes. The step is done when every row in the mapping has either an alert record or a documented gap.
Record data component coverage and gaps
The team compares the data components the test actually produced against the list drafted earlier, noting which components were present, missing or incomplete, such as a log source that did not forward metadata. Each gap receives an owner, a remediation note and a retest status. The output is a coverage table that the compliance lead can file with the test record. The step is complete when the table has no unexplained blanks and every gap has a named owner.
Revert the lab change and confirm cleanup
The platform owner reverts the pipeline change and removes any temporary tokens, test artifacts or lab-only credentials created during the exercise. The security lead checks the platform's change history to confirm the revert is recorded and that no unexpected changes remain. The step is done when the cleanup is signed off and the lab tenant matches its pre-test baseline. Document any residue found, as it may point to a control gap in the platform.
Store the evidence pack for audit
The team packages the scope agreement, the detection mapping, timestamps, alert IDs, screenshots or exports from the SIEM, the coverage table and the gap log into one versioned evidence pack. The pack names the ATT&CK version tested, the lab environment and the people who reviewed the results. Confirm with the internal auditor or assessor which format they accept, because DeployOpen prepares evidence but does not issue audit opinions. The step closes when the pack is stored in a controlled repository with access limited to the review group.
Re-run the test after each ATT&CK version change
When MITRE publishes a new Enterprise ATT&CK version, the detection engineer reviews the release notes for changes to T1677 and its related detection strategies, data components or mitigations. If the technique, its detection strategies or its data components changed, the team repeats the emulation and compares the new evidence pack with the previous one. The step is complete when the team records whether the detections still fire, and the comparison is filed with the version change note. Ask the platform vendor to confirm which of its logs cover the updated data components before the retest.
Which ATT&CK mitigations reduce T1677 exposure
Poisoned pipeline execution depends on who can change pipeline definitions, which identities those pipelines run as, and whether build platform settings drift without anyone noticing. The mitigations below address those three conditions, and each one should be confirmed against the documentation of your own SaaS vendor before you rely on it.
Control who edits pipeline definitions
Pipeline definitions are code, so a change to them is a change to what runs with your build credentials. Map which roles can create, edit or approve pipeline files, branch protection rules and pipeline-as-code settings, and remove any broad write access that is not needed for the work. Confirm in your vendor documentation whether protected branches, required reviews and approval gates can be enforced for pipeline files specifically, since some platforms apply them only to application code. Review this access list on a fixed schedule and after any organizational change.
Scope service accounts and tokens
A pipeline that runs with a broad service account turns one poisoned job into access to every connected system. Give each pipeline its own identity with only the permissions its stage needs, and avoid sharing one token across projects. Ask your vendor which token types are available, how long they last, and whether they can be bound to a specific repository or pipeline. Record the owner of every non-human identity so that a suspicious run can be traced to an accountable team.
Rotate and revoke pipeline secrets
Secrets stored for pipelines are useful to an attacker for as long as they remain valid and unchanged. Define a rotation period for each secret and token, and rehearse revoking one in full, including the downstream systems that depend on it. Confirm whether your platform supports short-lived or federated credentials for cloud deployments, and whether secret values can be masked in logs. Treat any secret that was visible to an untrusted pipeline run as compromised and rotate it.
Baseline build platform configuration
Software configuration changes, such as enabling a new runner, adding an integration or relaxing a branch rule, can make a poisoned pipeline easier to run. Record a known-good baseline of organization and project settings, export it on a schedule, and alert when it changes. Compare the baseline against the configuration guidance your vendor publishes, and confirm which settings can be exported through an API or audit log. Store the baseline outside the platform so that an attacker with platform administrator access cannot quietly edit both.
Audit pipeline and administrative events
Audit logs support T1677 detection only if they record who changed a pipeline, who approved it, which identity ran it and which settings changed. Confirm that your platform's audit log covers pipeline definition edits, secret access, token creation and administrative changes, and that the logs are forwarded to your monitoring stack with retention that matches your investigation needs. Test that a change to a pipeline file produces an event you can search for. Without this evidence, the other controls cannot be verified after an incident.
Triage and response when a pipeline change alert fires
When a T1677 alert fires on a pipeline change, the first decision is whether the change is a real threat or a legitimate but unreviewed edit. Start by confirming the change author, the approval path and the commit or configuration revision that introduced the alteration. Compare the author identity against the SaaS account that made the change, check whether a second reviewer approved it, and confirm that the change came through the normal merge or review route rather than a direct edit to the pipeline definition. Record the answers in the incident ticket before anyone changes anything, because later steps depend on them. Confirm these facts with your platform owner and the source control administrators, since the exact audit fields differ between SaaS products and your team needs to know which ones your tenant actually records.
Next, contain the pipeline without destroying evidence. Freeze the affected pipelines and revoke or rotate the tokens, deploy keys and service credentials that the pipeline uses to reach source control, artifact stores and deployment targets. Disabling a scheduled trigger or pausing a runner pool is usually safer than deleting a job, because deleted runs can take their logs with them. Then review every build artifact and downstream deployment produced since the suspect change: which images, packages or configuration bundles were published, which environments received them and which other pipelines consumed them. Preserve SaaS audit logs and pipeline run history by exporting them to write-once storage before retention windows or tenant administrators can rotate them. Confirm your tenant's log retention period in writing with the vendor.
The final decision is whether to roll back or rebuild from a reviewed commit. Rolling back is faster when the last known good revision is clearly identified and the artifacts it produced are unaffected. Rebuilding from a reviewed commit is the better path when any artifact built since the change may contain altered content, because a rollback alone does not remove code already deployed. Notify the platform owner, security lead and the owners of the downstream systems early, state what is frozen, what is known and what is still unverified, and agree who signs off the restored pipeline. Record the decision, its rationale and the evidence it relied on, so the post-incident review and any compliance assessor can follow the reasoning.
Rehearsing T1677 detection and response in a private cyber range
The range is a private environment, separate from production, built to mirror the SaaS build tenant your teams actually use. It holds test repositories, pipeline definitions, service accounts and runners that resemble your own, but contain no client data or live credentials. Logs from the tenant's audit and activity feeds are forwarded into Wazuh or Security Onion so analysts see the same telemetry they would see in production, including Command Execution, Cloud Service Modification and File Metadata events where the platform provides them.
- Mirrored tenant: Match pipeline configuration, branch protection, runner types and role assignments to production as closely as the written scope allows.
- Log forwarding: Confirm the SaaS audit feed reaches the SIEM with correct timestamps, actor identities and repository context before the exercise starts.
- Test repositories: Seed repositories with realistic but synthetic pipeline files, so changes to build definitions can be reviewed and attributed.
- Isolation controls: Keep range identities, tokens and network paths separate from production, and record who holds administrative access.
- Sizing and schedule: Range size, number of repositories and exercise windows are agreed in the written scope with DeployOpen.
Before the first inject, confirm with your platform team which events are logged, at what detail, and how long they are retained.
The red team plays a set of injects that model how an attacker could alter a build definition or pipeline runner to execute unreviewed code during a run. Each inject is written in advance with an expected detection signal, so the blue team's alerts can be compared against what was actually planted. Injects are described at the level of observable change, not as working techniques, and they run only inside the private range.
- Pipeline definition change: A modification to a build file made outside the normal review path, expected to produce a Cloud Service Modification event and a Command Execution record for the job that follows.
- Unreviewed branch activity: A change pushed to a branch without the required approval, expected to show in repository audit records and in File Metadata for the changed file.
- Runner context change: A job executed under a different service identity than its usual owner, expected to surface as an identity mismatch in the SIEM.
- Secret access attempt: A job that requests protected variables outside its declared scope, expected to appear in platform audit logs.
- Timing and volume: Variants that run outside normal working hours or at high frequency, to test whether thresholds are tuned.
Record the time each inject runs so the detection timeline can be reconstructed afterward.
Good detection for T1677 means an analyst can see a pipeline change, identify who made it, link it to the job that ran, and decide whether it was authorized, all within the response window your runbook sets. Success is measured against criteria written before the exercise, not judged afterward. Map each inject to the ATT&CK version your detection content targets, so results stay comparable when technique mappings change in later releases.
- Alert coverage: Every planted inject produces at least one alert or a documented reason it did not, such as a log field that the platform does not expose.
- Attribution: The alert identifies the actor, repository, branch and pipeline run, without manual lookups across several consoles.
- Triage quality: Analysts classify each alert as authorized, unauthorized or unknown, and record the evidence used.
- Response execution: The team freezes the affected pipeline, rotates any exposed credentials in the range, and documents the containment steps against the runbook.
- Mitigation review: Confirm that User Account Management and Software Configuration controls, such as role scoping and protected branch rules, limited what the injects could change.
After the debrief, tune rules, close the logging gaps found, and retest the same injects to confirm the fixes.
Keeping T1677 detections aligned with ATT&CK releases
Every T1677 detection should name the ATT&CK version it targets. ATT&CK releases can rename, deprecate or revoke techniques, and the recent cadence is v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. A rule written against one version can silently point at a technique ID or sub-technique that has changed by the time it is reviewed. Record the version in the rule metadata, in the Wazuh or Security Onion rule repository, and in the coverage matrix your SOC reports from, so an auditor or a new analyst can see which ATT&CK state the detection was built on. Confirm the exact version labels and change notes in the official ATT&CK updates page before you publish a mapping, rather than relying on memory or secondhand summaries.
Build the mapping from the enterprise-attack 20.0 STIX bundle, which MITRE publishes in the attack-stix-data repository. For T1677, record the technique object, its detection strategy (DET) references and the data components (DC IDs) those strategies cite, such as Command Execution (DC0064) and Cloud Service Modification, and check that each data component matches a log source you actually collect from your SaaS pipeline platform. Keep the mapping in version control as a small table keyed by ATT&CK ID and version. At each new release, diff the bundle against the prior version, flag any change to T1677, its sub-technique or its cited data components, and assign a named owner to re-test the affected rules in the cyber range before the change is accepted. Ask your managed or implementation partner to include this diff step in the written scope, since it recurs with every release.
Questions SOC leads ask about detecting T1677
Which logs should a SOC forward first for poisoned pipeline detection?
Start with the audit and activity logs from the source control platform and the CI/CD service, because they record who changed pipeline definitions, who approved those changes, and which jobs ran. Next, add cloud service modification events from the admin consoles of the SaaS tools in the chain, since token, integration and secret changes often accompany a pipeline change. Then add command execution records from build runners, including self-hosted runners, and file metadata for pipeline definition files and build scripts. Confirm with each vendor which audit events exist, how long they are retained and whether they can be streamed. Normalize timestamps and identities so a commit author can be correlated with a job run.
How do you separate planned pipeline changes from malicious ones?
Check whether each change to a pipeline definition followed an expected path: a reviewed merge request, an approved author and a linked work item. Flag changes pushed directly to protected branches, changes made by identities that do not normally edit pipeline files, and changes that add outbound network calls, new secret references or new third-party actions. Treat pipeline definitions as code under your change management process. Illustrative example: a commit adds a step that downloads an unfamiliar script, and the author is a service account with no linked ticket. That alert should go to a human reviewer for triage. Build a baseline of normal behavior for each repository before tuning thresholds.
Can Sigma rules express poisoned pipeline detection logic?
Partly. Sigma works well for events that map to fields such as process creation or command execution, so you can express rules for a runner starting unexpected binaries or making unexpected network connections. SaaS audit events are often JSON records that need a custom log source mapping in your SIEM before Sigma fields apply, so rule logic depends on how each platform's logs are normalized. Use Sigma for event-level logic, then correlate across sources in your SIEM, for example a pipeline file change followed by a job run from the same identity within a short window. Validate every rule against sample events from your own environment, because field names differ between products.
How can you test pipeline detections without touching production builds?
Build a copy of the pipeline platform in a private cyber range or a separate non-production organization, with synthetic repositories, runners and identities. Replay recorded audit events from that environment into your SIEM, then run scripted scenarios: a benign pipeline edit, an unexpected edit from a test identity and an edit that adds a new runner step. Confirm that each expected alert fires, reaches the right queue and triggers the response runbook. Keep test tokens scoped and short-lived, and never reuse production secrets in the range. DeployOpen builds private cyber ranges as part of its security training and testing work, and the range scope is agreed in writing before work starts.
How do you know your poisoned pipeline coverage is adequate?
Adequate coverage means you can show, for each in-scope repository and pipeline platform, that the expected telemetry arrives, that detections fire on test scenarios and that a responder can act on the alert within your documented process. Map each detection to MITRE ATT&CK and name the version you target, because technique content and mitigations can change between releases. Use ATT&CK version 20.0 as a documented baseline if that matches your mapping. Track gaps explicitly: sources not forwarded, identities without audit visibility and runners without command logging. Re-run the scenarios after each platform upgrade. Ask any provider for test results and the gap list in writing, and treat a single summary score as a weak signal.
Which mitigations apply to T1677, and who owns them?
MITRE ATT&CK maps User Account Management and Software Configuration to this technique. User Account Management covers who can change pipeline definitions, approve merges and hold tokens. Enforce least privilege, separate the duties of authors and approvers, and remove stale service accounts. Software Configuration covers how the platform itself is set up, including branch protection, required reviews, restrictions on which runners can execute protected jobs and controls over third-party integrations. Ownership usually sits with the platform or DevOps team for configuration and identity, with security reviewing settings and monitoring changes to them. Confirm each control in your own environment, because product settings and names vary.
Can our own team run this detection work without an outside partner?
Often yes for the monitoring side, if your team already runs a SIEM and administers the CI/CD platform. The work has several parts: log onboarding, custom parsing, rule tuning, a test range and a response runbook. Effort depends on how many repositories, pipeline platforms and runners you operate and how mature your logging already is. One-time work includes onboarding sources and building test scenarios. Recurring work includes tuning alerts, reviewing gaps and retesting after platform upgrades. If you bring in a partner, ask for scope, deliverables and acceptance criteria in writing before work starts. DeployOpen plans, implements and supports open-source platforms inside client infrastructure and runs security testing and cyber ranges.
How DeployOpen builds T1677 detections and cyber range exercises
DeployOpen approaches T1677 Poisoned pipeline execution as an implementation and testing engagement inside the client's own environment, not as a generic rule set. Work starts with a written scope that names the SaaS pipeline platforms, telemetry sources and detection targets, then moves through build, validation and documentation.
How we scope
- Engagements are fixed-scope, with the T1677 telemetry sources, SaaS platforms and deliverables agreed in writing first.
- We confirm which CI/CD audit logs, repository events and cloud service modification records the client can actually export.
- We record the ATT&CK version each detection targets, since releases can rename or deprecate techniques.
How we build
- We implement open-source collection and detection logic in the client's own stack, such as Wazuh or Security Onion, as agreed in scope.
- We write Sigma-style detection logic for pipeline configuration changes, unexpected job definitions and new build secrets access.
- We test each detection against a private cyber range, including benign pipeline changes, to measure false positives before handover.
How we hand over
- Deliverables include detection logic, data source mappings, validation results and runbooks for responding to suspect pipeline runs.
- We document which mitigations, such as User Account Management and Software Configuration, the client owns and must maintain.
- Walkthroughs with the SOC and platform engineering teams cover how alerts are triaged and escalated.
How we support
- Ongoing support, upgrades and continuous testing of T1677 detections are available as retainers.
- Retainers can include re-validating detections after ATT&CK releases and after changes to the CI/CD platform.
- Compliance evidence is prepared for independent auditors to assess, since DeployOpen does not issue audit reports or certifications.
