What Happened
Cisco's development environment was compromised when attackers used credentials stolen from a supply chain attack on Trivy, an open-source vulnerability scanner. The threat group TeamPCP deployed a malicious GitHub Action plugin that allowed them to clone more than 300 GitHub repositories containing Cisco source code and exfiltrate AWS credentials.
The attack chain began outside Cisco's perimeter with compromised credentials from the Trivy ecosystem, then moved laterally through their CI/CD pipeline using automation tools that Cisco's developers trusted.
Timeline
The exact timeline remains limited to what Cisco has disclosed publicly, but the attack pattern follows a clear sequence:
- Initial compromise: Attackers obtained valid credentials through the Trivy supply chain breach.
- GitHub Action deployment: A malicious plugin was introduced into Cisco's CI/CD workflows.
- Credential harvesting: AWS keys were extracted from the compromised environment.
- Repository exfiltration: More than 300 GitHub repositories were cloned.
- Detection and response: Cisco identified the breach and began containment.
The gap between initial access and detection is not publicly known, but the scale of exfiltration suggests the attackers had sustained access to the environment.
Which Controls Failed or Were Missing
Supply chain validation: Cisco's environment executed third-party GitHub Actions without adequate verification. The malicious plugin from the Trivy compromise ran with sufficient privileges to access credentials and repository contents.
Credential management: AWS keys were accessible within the CI/CD environment in a way that allowed automated extraction. This suggests either hardcoded credentials, overly permissive environment variables, or inadequate secrets management.
Network segmentation: The development environment had broad access to production cloud resources. Once attackers obtained AWS credentials, they could move beyond the initial foothold.
Action monitoring: The mass cloning of 300+ repositories did not trigger alerts. This represents a gap in both activity monitoring and anomaly detection for repository access patterns.
Least privilege: The compromised credentials and GitHub Action had access to far more repositories than any single workflow would legitimately need.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software is developed securely and that bespoke and custom software are based on industry standards. This includes securing the development environment itself—not just the code it produces. The standard explicitly requires that development environments be separated from production and that access to source code is restricted.
Requirement 6.4.3 addresses scripts and custom code, requiring that changes are authorized and that all custom code is reviewed prior to release. While this focuses on the code itself, the underlying principle applies to the tools that touch that code. A malicious GitHub Action can inject code or exfiltrate it before any review occurs.
ISO/IEC 27001:2022 Control 5.19 (information security in supplier relationships) requires organizations to define and implement processes to manage information security risks associated with the use of supplier products or services. GitHub Actions from third-party authors are supplier code running in your environment.
Control 8.30 (outsourced development) requires that the organization supervises and monitors outsourced system development activities. When you run third-party automation in your CI/CD pipeline, you are effectively outsourcing part of your development process.
NIST 800-53 Rev 5 Control SA-12 (supply chain protection) requires organizations to protect against supply chain threats by employing multiple safeguards, including conducting supplier reviews, employing anti-counterfeit measures, and limiting harm from potential adversaries.
Control AC-6 (least privilege) mandates that users and processes operate with the minimum privileges necessary. The GitHub Action that compromised Cisco had access to AWS credentials and hundreds of repositories—almost certainly more than it needed for its stated function.
Lessons and Action Items for Your Team
Audit your GitHub Actions immediately. Review every third-party action in your workflows. Check the action's repository for recent updates, look at the commit history, and verify the maintainer's identity. If an action requests broad permissions, ask why. For critical workflows, consider forking actions into your own organization so you control updates.
Implement GitHub Action pinning. Reference actions by commit SHA, not by tag or branch. Tags can be moved; a SHA cannot. This prevents an attacker who compromises an action's repository from automatically pushing malicious code into your pipelines.
# Vulnerable
uses: actions/checkout@v3
# Pinned
uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
Move secrets out of the CI/CD environment. Use short-lived credentials from an identity provider instead of static AWS keys. GitHub supports OpenID Connect (OIDC) federation with AWS, Azure, and GCP. Configure your workflows to request temporary credentials with scoped permissions for each job.
Segment repository access. Create separate GitHub organizations or use repository-level permissions to ensure that a single compromised workflow cannot access your entire codebase. Consider: does your documentation build workflow really need access to your authentication service's repository?
Monitor repository activity. Set up alerts for bulk cloning, unusual access patterns, or repository access from unexpected IP ranges. GitHub's audit log can feed into your SIEM. A workflow that suddenly clones dozens of repositories should trigger investigation.
Require CODEOWNERS review for workflow changes. Treat .github/workflows/ as infrastructure code. Require review from a security-focused team before workflow modifications merge. This creates a checkpoint before malicious actions enter your pipeline.
Test your detection. Clone ten repositories in quick succession from a test account. Does your monitoring catch it? If not, you would not have caught this attack either.
The Cisco breach demonstrates that your CI/CD pipeline is not just infrastructure—it is an attack surface. Every third-party action is code running with your credentials in your environment. Treat it accordingly.
