Complete technique description
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 <b>Direct Pipeline Execution</b> 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.[Unit 42 Palo Alto GitHub Actions Supply Chain Attack 2025][OWASP CICD-SEC-4]
* In an <b>Indirect Pipeline Execution</b> scenario, the threat actor injects malicious code into files referenced by the CI configuration file. These may include makefiles, scripts, unit tests, and linters.[OWASP CICD-SEC-4]
* In a <b>Public Pipeline Execution</b> 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.[Unit 42 Palo Alto GitHub Actions Supply Chain Attack 2025][GitHub Security Lab GitHub Actions Security 2021] Similarly, threat actors may craft pull requests with malicious inputs (such as branch names) if the build pipeline treats those inputs as trusted.[Wiz Ultralytics AI Library Hijack 2024][Synactiv Hijacking GitHub Runners][GitHub Security Labs GitHub Actions Security Part 2 2021] 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.[John Stawinski PyTorch Supply Chain Attack 2024]
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).
Official technique definition · Open in the interactive matrix
Detection telemetry and configuration
These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.
Cloud Service Metadata · source-mapped
DC0070 collection page — Export service configuration with resource ID, region, status and enabled logging features using least-privileged read access.
Providers and collection configuration
- In the isolated account/project/subscription, route administrative audit logs to a protected destination with retention and access controls.
- Select the relevant service, regions and read/write operations. Confirm whether the API below is a management or data event in the provider documentation.
- Preserve actor/session, resource, request ID, service, operation, region and error details. Check delivery latency and avoid logging credentials or sensitive request bodies.
Required normalized fields: resource_id, service, enabled, retention_days.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0070",
"collector": "illustrative-lab-collector",
"observation": {
"resource_id": "lab-service-1",
"service": "lab-audit-service",
"enabled": true,
"retention_days": 30
}
}
Visibility limits: AWS, Azure and Google expose different APIs and event schemas. An accepted API request does not prove the final resource state; join asynchronous outcomes and inventory.
Cloud Service Modification · source-mapped
DC0069 collection page — Collect the service-specific update API and resulting configuration state; record account/project, actor and changed settings.
Providers and collection configuration
- In the isolated account/project/subscription, route administrative audit logs to a protected destination with retention and access controls.
- Select the relevant service, regions and read/write operations. Confirm whether the API below is a management or data event in the provider documentation.
- Preserve actor/session, resource, request ID, service, operation, region and error details. Check delivery latency and avoid logging credentials or sensitive request bodies.
Required normalized fields: service, resource_id, attribute, before, after.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0069",
"collector": "illustrative-lab-collector",
"observation": {
"service": "lab-audit-service",
"resource_id": "lab-service-1",
"attribute": "retention_days",
"before": 7,
"after": 30
}
}
Visibility limits: AWS, Azure and Google expose different APIs and event schemas. An accepted API request does not prove the final resource state; join asynchronous outcomes and inventory.
Cloud Storage Access · source-mapped
DC0025 collection page — Explicitly select relevant object-read data events; keep principal, key, request ID and result without object contents.
Providers and collection configuration
- Choose only the lab buckets/containers and prefixes. Enable read/write data-event collection when object access is needed; management events alone are insufficient.
- Keep administrative changes separately from object reads/writes. Set a cost budget and retention limit before enabling high-volume data logging.
- Preserve object version/key, requesting identity, action, source address, result and request ID. Verify the collector actually receives one benign read and one benign write.
Required normalized fields: action, bucket, key, actor, result.
[
{
"Name": "LabObjectReads",
"FieldSelectors": [
{
"Field": "eventCategory",
"Equals": [
"Data"
]
},
{
"Field": "resources.type",
"Equals": [
"AWS::S3::Object"
]
},
{
"Field": "resources.ARN",
"StartsWith": [
"arn:aws:s3:::lab-bucket/demo/"
]
},
{
"Field": "readOnly",
"Equals": [
"true"
]
}
]
}
]
Replace the placeholder with an owned lab bucket/prefix. Review costs and merge with required selectors; applying selectors can replace an existing selection. This does not enable management-event retention or object-write coverage.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0025",
"collector": "illustrative-lab-collector",
"observation": {
"action": "get_object",
"bucket": "lab-bucket",
"key": "demo.txt",
"actor": "lab-reader",
"result": "success"
}
}
Visibility limits: Storage metadata, listing, object access and bucket administration are different operations. Do not equate a successful request with proven exfiltration or complete content visibility.
Command Execution · source-mapped
DC0064 collection page — Collect process command lines and relevant shell/interpreter audit; shell history alone is neither complete nor tamper-resistant.
Providers and collection configuration
- Enable Script Block Logging through the policy/configuration for the installed edition. Forward Microsoft-Windows-PowerShell/Operational for Windows PowerShell, or PowerShellCore/Operational for PowerShell 7.
- Retain script-block ID and fragment ordering alongside process creation. Protect access to collected script text; secrets may be included.
- On Linux, use narrowly scoped Audit execution rules for the lab account and supported architectures, and retain joined SYSCALL/EXECVE/PATH records.
Required normalized fields: interpreter, command_line, actor_uid, session_id.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0064",
"collector": "illustrative-lab-collector",
"observation": {
"interpreter": "/bin/sh",
"command_line": "printf LAB_TELEMETRY_CHECK",
"actor_uid": 1000,
"session_id": "lab-session-1"
}
}
Visibility limits: Script content and process command lines are different signals. Logging may be partial, fragmented, filtered or disabled; never assume a command line reveals everything executed.
File Metadata · source-mapped
DC0059 collection page — Collect scoped file inventory/FIM metadata with hash algorithm and observation time; preserve original timestamps separately from collector time.
Providers and collection configuration
- osquery: Scheduled host-state queries; supported tables and privileges vary by OS. Select a table that actually exposes the required object.
- Linux Audit plus inventory snapshots: Events explain changes; snapshots describe state at collection time.
- Define the inventory query, allowed host set, interval and least-privileged reader. Store a stable asset ID, observation time and collector version.
- Keep successive snapshots and calculate additions, removals and changed attributes. Pair state changes with audit events when available.
- Export collector health and missed-poll counts so a missing snapshot is not misclassified as a missing asset.
Required normalized fields: path, size_bytes, sha256, owner_uid.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0059",
"collector": "illustrative-lab-collector",
"observation": {
"path": "/opt/lab/demo.txt",
"size_bytes": 64,
"sha256": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"owner_uid": 1000
}
}
Visibility limits: Snapshots miss short-lived objects and do not identify who caused a change. A generic inventory agent is not guaranteed to expose firmware or kernel-level details.