Detecting GitHub Actions Supply Chain Attack: Sentinel and GuardDuty Detections

Retrospective: this article looks back at events from March 2025, written in 2026 with the benefit of hindsight.

Supply-chain attacks on CI/CD dependencies often reveal themselves in workflow behavior and logs. These detections help spot compromised actions and secret leakage.

Signals worth watching

• Workflow logs containing base64-encoded blobs or unexpected memory dumps.
• Actions referenced by tags that changed to point to new commits.
• Workflows making outbound network connections to unfamiliar domains during runs.
• New or modified workflow files in repositories without review.
• Use of cloud credentials from IPs outside CI runner ranges shortly after a workflow run.
• GitHub security advisories and CISA alerts for actions you use.

Where the data lives

• GitHub audit log (streamed to your SIEM) for workflow changes and action usage.
• Workflow run logs.
• Runner network telemetry (self-hosted runners with EDR, or network monitoring tools for hosted runners such as StepSecurity Harden-Runner).
• Cloud logs (CloudTrail, Entra ID service principal sign-ins) for credential use.

A starting approach

1. Maintain a list of third-party actions in use (search uses: across repositories).
2. Subscribe to advisories for those actions.
3. Scan workflow logs for patterns of secret exposure (for example, double-encoded base64 strings).
4. Correlate CI identity use in cloud logs with known runner IP ranges or OIDC subject claims.

Example for AWS roles assumed through GitHub OIDC from unexpected repositories:

AWSCloudTrail
| where EventName == "AssumeRoleWithWebIdentity"
| extend Sub = tostring(parse_json(RequestParameters).roleSessionName)
| project TimeGenerated, UserIdentityArn, SourceIpAddress, RequestParameters

Response

1. Identify workflows that ran the compromised version.
2. Rotate every secret available to those workflows.
3. Review logs for exposed values.
4. Pin actions to SHAs and restrict allowed actions.