Your CI/CD Pipelines: The Largest Unmonitored Attack Surface

In the fast-paced world of software development, automation through Continuous Integration and Continuous Deployment (CI/CD) pipelines is essential. However, every time a team deploys code to the cloud, such as AWS, they use credentials that grant access to production infrastructure. The problem is that, in most organizations, these credentials have excessive permissions, are shared across environments, and are rarely reviewed. A breach in a single pipeline can mean total account takeover.

This is not a hypothetical scenario. Recent incidents, such as the attack on the security scanning tool Trivy in March 2026, where attacks forced malicious code into their GitHub actions, demonstrated how stolen secrets can propagate through open source ecosystems like PyPI. Another alarming example was an AI-driven campaign in April 2026, which opened hundreds of malicious pull requests in a matter of hours, exfiltrating credentials from multiple organizations.

Structural Issues in Pipeline Security

There are three fundamental weaknesses that increase this attack surface:

1. Long-Lived Credentials: Most pipelines use static access keys stored as CI/CD variables. These keys do not expire, have no specific scope for concrete actions, and persist even after employees leave the company. A single leaked key provides an attacker with continuous access.
2. Shared Permissions: It is common for the same AWS Identity and Access Management (IAM) role to be used to deploy to development, staging, and production environments. This means a compromised feature branch could access production data, as the permission model does not distinguish between these environments.
3. Lack of Visibility and Scope: Teams often request broad permissions because defining granular permissions is a slow process. Over time, roles accumulate access that no one remembers granting, and the actual use of credentials is rarely audited against what they could potentially do.

Towards Secure CI/CD Pipelines with Least Privilege

AWS proposes a reference architecture to implement the principle of least privilege in CI/CD pipelines. Key ideas include:

• Eliminate Long-Lived Credentials: Use federated authentication (OpenID Connect or OIDC) with AWS, supported by platforms like GitHub and GitLab. Pipelines obtain short-lived tokens (approximately 1 hour) without the need to store secrets. If a pipeline is compromised, the token expires before an attacker can establish persistence.
• One Role per Environment and Pipeline: The production deployment role should only accept requests from the main branch of a specific repository. This ensures that a developer on a feature branch cannot access production credentials, even if they modify the pipeline configuration. Security is defined in IAM, not just in the pipeline file.

Four Layers of Defense and Separation of Duties

No single control is sufficient. The recommended pattern stacks several security layers:

• Organization-Level Guardrails: Service Control Policies that prevent disabling audit logging or moving outside of approved regions.
• Permission Boundaries: Restrictions on each pipeline role to prevent privilege escalation.
• Specific Grants: Granting only the actions necessary for each pipeline.
• Resource-Level Policies: For cross-account access.

A crucial architectural decision is to separate who creates permissions from who uses them. This is achieved through two types of pipelines:

1. Platform Pipeline: Creates and manages IAM roles. It runs from a dedicated repository, requires human approval, and is managed by the platform/security team. It can modify permissions but cannot deploy applications.
2. Service Pipelines: Deploy application code. They assume pre-created roles with fixed, scoped permissions. They cannot modify their own permissions or those of others. A compromised service pipeline cannot auto-escalate its privileges.

Automated Refinement and Risk Reduction

Instead of guessing the necessary permissions, you can run a pipeline with broad but limited access in a development environment for 90 days. AWS CloudTrail logs every API call, and IAM Access Analyzer generates a least-privilege policy based on actual usage. This policy is integrated into the code review process, similar to application code. This approach, which touches on aspects of modern programming, helps align security practices with standards like SOC 2 and ISO 27001.

The initial investment to implement this pattern may vary, but the benefits are immediate. The first step of implementing OIDC and permission boundaries can be done in an afternoon per pipeline, eliminating the most dangerous risk: long-lived credentials with unlimited scope. Adopting these practices is crucial, especially with the rise of AI coding assistants, which also operate with pipeline credentials and could become vectors for privilege escalation if not managed properly.

It is vital to ask:

• How many pipelines use long-lived access keys?
• Do production roles accept requests only from the main branch?
• When was the last permission usage audit?
• What would the impact of a credential leak be?

The key question is whether your organization treats pipeline credentials with the same rigor as access to production databases. Unfortunately, recent incidents suggest that most still do not.

Sources:

• Dev.to (https://dev.to/aws-builders/your-cicd-pipelines-are-your-largest-unmonitored-attack-surface-59ck)