TeamPCP Hacks Checkmarx GitHub Actions Using Stolen CI Credentials

---

Author:
Morgan Drake, Principal Cloud Security Engineer (14 years DevSecOps, ex-Netflix, ex-AWS).

• LinkedIn
• GitHub
  Disclosure: The S3 anecdote is anonymized from a prior engagement; all sensitive details redacted.

---

Executive Summary

This deep-dive delivers an incident analysis and battle-tested remediation checklist stemming from the reported Checkmarx GitHub Actions supply-chain compromise (advisory, GitHub SA, security research).
Designed for DevSecOps engineers and security leads hunting actionable, non-fluffy fixes. If your CI pipeline touches production, grab these specifics.

---

What to Check Right Now: Quick Bullet List

• Revoke any suspect GitHub Actions tokens.
• Set workflow-level permissions to read for all workflows (docs).
• Review GitHub Organization Audit Logs for oidc_token_issued and unexpected workflow runs.
• Check CloudTrail for spikes in AssumeRoleWithWebIdentity and unfamiliar IAM role assumptions (AWS docs).
• Pin all third-party Actions by SHA.
• Disable or restrict Actions running by forks or untrusted contributors.

---

Technical Root Cause Analysis: GitHub Actions Compromise & CI Credentials Leaked

According to Checkmarx’s advisory, attackers leveraged exposed CI credentials in GitHub Actions to gain unauthorized lateral access.
The blast radius was amplified by:

• Default broad workflow permissions: Many Actions were running with permissions: write-all, against best practice (GitHub docs).
• Absence of OIDC integration: No ephemeral credentialing (OWASP on OIDC for CI), meaning static tokens stayed valid.
• Dependency chain risk: At least one compromised dependency, unpinned and not subject to required approval (Rezilion supply chain case study).
• Overprivileged IAM roles: Typical configuration allowed AssumeRoleWithWebIdentity on wildcard principals (CloudTrail events: AssumeRole, AssumeRoleWithWebIdentity).

---

The Real Anatomy of One-Click Disaster

Back in 2020, I triaged a breached S3 bucket linked to CI workflow sprawl.
Root cause: a GitHub Action referencing a third-party action with a wildcard IAM role.

• IAM policy looked like:

  {
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }
  

• No OIDC: Static AWS keys checked in, valid for months.
• Result: Leak chain—forked workflow ran in PR, attacker exfiltrated the keys, loaded them in another GitHub Action, dumped S3.

If you want specifics: search your Credentials tab for keys with wildcards, and your Org Audit log for external workflow runs.
Fixing this required nuking all tokens, hardening policies, and rebuilding workflows with signed commits and approvals.

---

Why CI Keeps Failing: Audit (and Build) Like Attackers

Supply-chain attacks thrive in chaos. Most shops “enable workflows” without reading the permission diff or the dependency tree.
Every third-party Action is a potential vector (github.com/actions/toolkit security advisories).
Permission creep is endemic.
Read the logs: most orgs have dozens of workflows running with contents: write, even when only read is needed.

Risk explodes when:

• Forked repos run Actions without approval.
• Unpinned or auto-updating dependencies get injected.
• No secrets scanning is enabled on workflow inputs.

---

Immediate Remediation Steps

1. Rotate all leaked or static CI credentials.
   • AWS: Invalidate access keys with aws iam delete-access-key or via AWS Console.
   • GitHub: Revoke any Personal Access Tokens (PAT), OAuth apps, or workflow tokens (docs).
2. Disable or restrict suspect workflows immediately.
3. Set workflow-level permissions to least privilege.

YAML Before (dangerous):

permissions: write-all

YAML After (least privilege):

permissions:
  contents: read
  id-token: write

See: GitHub Actions permissions reference

4. Configure OIDC for cloud deployments.

   • AWS OIDC setup guide
   • GCP Workload Identity
   • Ephemeral tokens reduce blast radius. Worth integrating but understand OIDC is not universal—older APIs need static creds.

5. Pin Actions by SHA, require approvals for first-time contributors.

   • Example YAML:

   uses: actions/checkout@e5b2bcd18a52818d9bcc3b9dde82233664cdcf10 # Pinned by SHA
   

   Pinning Actions guide

6. Enable secret scanning and automated dependency updates.

   • Enable secret scanning for Actions

---

Detection & Monitoring: Log Sources, KPIs, and Threat Intel

• GitHub Audit Log:
  • Find suspicious activity:
    • oidc_token_issued events
    • workflow_run by forks or new contributors
    • Unexpected increases in workflow runs (Audit Log docs)
• AWS CloudTrail / GCP Logs:
  • Look for unusual AssumeRole or AssumeRoleWithWebIdentity.
  • Filter for new roles/assume events from CI providers.

Command for AWS CloudTrail:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity

• KPIs to track:
  • Workflows with write permissions (permissions: write-all, contents: write)
  • Number of unpinned third-party Actions
  • Mean time to rotate CI credentials after incident
  • % of workflows with OIDC, ephemeral creds

---

Long-Term Supply-Chain Hardening & Policy Enforcement

• Enforce “allow specified Actions only” at org level (GitHub org settings).
• Require workflow approvals from forks and first-time contributors.
• Enable organization-wide 2FA and SAML/SSO.
• Enable Dependabot for Actions and dependencies.
• Adopt supply chain controls:
  • SLSA (level 2+) (SLSA guide)
  • Sigstore for signed Action provenance (Sigstore docs)
  • Note: Sigstore and SLSA bring friction; plan for gradual adoption.

Legal/Comms Checklist:

• Start timeline collection—incident start, detection, mitigation steps.
• Review applicable disclosure requirements (NIST IR 7298).
• Prepare comms for regulatory reporting if PII/customer data touched.
• Refer: GitHub incident response guidance.

---

Remediation Checklist: Short, Medium, Long-Term

Short-term

• Nuke/revoke any exposed credentials, stop affected workflows, restrict Actions to trusted list.

Medium-term

• Enforce least-privilege in all workflow YAML, migrate to OIDC, pin Actions by SHA, enable secret scanning.

Long-term

• Implement supply-chain controls (SLSA, Sigstore), run regular dependency audits, enforce org-wide security policies, review all external Action usage.

---

Trade-offs and Limitations

OIDC: Fewer moving parts than static keys, but legacy APIs and non-cloud providers often lack support.
SLSA/Sigstore: Require upstream and downstream adoption; expect friction if dependencies aren’t broadly signed or attested.
Least privilege: Granular workflow permissions demand ongoing review. One missed permission could break valid releases.

---

References & Further Reading

• Checkmarx advisory
• GitHub Security Advisories
• GitHub Actions permissions guide
• OWASP CI/CD Security Project
• SLSA framework
• Sigstore
• GitHub Org Action Policies
• Rezilion supply chain attacks
• Enable Dependabot

---

No More Excuses: Next Compromise Is Already Scheduled

You know how this ends. Your pipeline isn’t “secure”—it's just