Use Case: Code & Supply Chain
CI/CD pipeline abuse
A modified GitHub Actions workflow was uploaded that exfiltrated AWS_SECRET_ACCESS_KEY to an external endpoint during the build step. ManySignal flagged the new exfiltration step before the next pipeline run triggered.
The build step that calls home
CI/CD pipelines have become one of the richest targets in modern infrastructure. A typical pipeline has: access to cloud deployment credentials (AWS, GCP, Azure), secrets for SaaS integrations (database passwords, API keys), write access to production infrastructure via Terraform or Kubernetes, and the trust of every engineer in the organization who sees a green build status.
An attacker who can modify a workflow YAML file — by compromising a developer account, exploiting a dependency, or gaining write access to the repository — can insert a step that exfiltrates every secret the pipeline has access to. This runs on every subsequent pipeline trigger, silently, in the middle of what appears to be a normal build.
rule: cicd_pipeline_abuse
type: workflow_diff + behavioral
sources:
- github_actions_audit
- github_webhook_workflow_events
- gitlab_ci_audit
trigger:
- event: workflow_file.modified
- condition: |
new_steps.contains(external_network_call)
OR new_steps.contains(env_secret_access_pattern)
AND workflow_modifier NOT IN [approved_maintainers]
- OR:
- condition: |
pipeline_run.secret_access_event
AND outbound_connection.domain NOT IN approved_destinations
enrichments:
- workflow_diff: new_steps vs historical_baseline
- secret_scope: secrets accessible in this pipeline context
- actor_authorization: committer_permissions, code_owners
mitre: T1195.002 (Supply Chain Compromise), T1552.001 (Credentials in Files)MITRE ATT&CK mapping
CI/CD pipeline abuse FAQ
What CI/CD pipeline actions constitute abuse?
Modifying workflow YAML files to add secrets exfiltration steps, using pipeline access to make unauthorized commits to protected branches, accessing secrets (AWS_SECRET_ACCESS_KEY, etc.) from pipeline contexts and transmitting them externally, injecting steps that download and execute external payloads, and creating pipeline triggers that execute on external events without review.
Does ManySignal monitor GitHub Actions, GitLab CI, Jenkins, and CircleCI?
Yes. ManySignal integrates with GitHub Actions (via audit log and webhook), GitLab CI (via audit events API), Jenkins (via audit log plugin), CircleCI, Buildkite, and ArgoCD. The detection logic normalizes across all platforms.
How does ManySignal detect exfiltration steps injected into pipeline YAML?
The pipeline workflow analysis compares each run's executed steps against the repository's historical workflow configurations. New steps that weren't present in the previous workflow version are flagged, especially steps that make outbound network calls (curl, wget, aws s3 cp to external accounts) or access environment secrets.
Can attackers abuse GitHub Actions via the GITHUB_TOKEN?
Yes. The GITHUB_TOKEN grants write access to the repository in most default configurations. Actions that use this token to force-push commits, modify branch protection settings, or create releases are detected as pipeline abuse. ManySignal correlates the token usage against the workflow's declared required permissions.
Detect malicious pipeline changes before the next build runs
Workflow YAML diff analysis and runtime secret access monitoring for GitHub Actions, GitLab CI, and Jenkins.