What Is Insufficient Pipeline-Based Access Controls?

Insufficient pipeline-based access controls, listed as an OWASP Top 10 CI/CD security risk, involves pipeline execution nodes with excessive access to resources and systems within and outside the execution environment. The attacker running malicious code within a pipeline can exploit insufficient pipeline-based access controls to move laterally within or outside the CI/CD system, ultimately increasing the blast radius of the initial attack.

CICD-SEC-5: Insufficient Pipeline-Based Access Controls Explained

Insufficient pipeline-based access controls represent a significant security risk within CI/CD pipelines. When access controls for pipeline execution lack necessary granularity, potentially granting a pipeline stage more permissions than required, an attacker who has infiltrated the pipeline can exploit these excessive permissions to move laterally within the pipeline.

Pipeline execution nodes have access to myriad resources and systems within and beyond the execution environment. These nodes execute the commands specified in the pipeline configuration, conducting a range of sensitive activities that involve:

• Accessing source code, as well as building and testing it
• Obtaining secrets from various locations, such as environment variables, vaults, dedicated cloud-based identity services, and other locations
• Creating modifying, and deploying artifacts

Pipeline-Based Access Controls Defined

Pipeline-based access controls refer to the context in which each pipeline — and each step within that pipeline — runs. Given the highly sensitive and critical nature of pipelines, it’s imperative to limit a pipeline’s access to the set of data and resources it requires to operate. Ideally, each pipeline and step should be restricted in a manner that limits potential damage resulting from malicious code executed within the context of the pipeline.

Pipeline-based access controls include controls relating to numerous elements associated with the pipeline execution environment. These include:

• Access within the pipeline execution environment to code, secrets, environment variables, and other pipelines
• Permissions to the underlying host and other pipeline nodes
• Ingress and egress filters to the internet

How Exploitation of CICD-SEC-5 Happens

When harmful software infiltrates a stage of the pipeline, it acquires the same level of access to resources and systems as that stage. If a stage is granted excessive permissions, it presents an opportunity for an intruder to obtain access to confidential information or establish connections to resources accessible by the pipeline. When an intruder successfully breaches the pipeline, they can manipulate these permissions in an advanced persistent threat (ADT) with compounding repercussions.

A Hypothetical Scenario

A malicious script infiltrates an early stage of the pipeline, perhaps a development environment. In possession of the same access as the development environment, the malicious script inherits permissions that allow it to access and modify a shared code repository. It injects code designed to exfiltrate sensitive data into the application's source code.

The application moves through the pipeline and, carrying the injected code, is deployed to the production environment. The code now can access whatever resources the production environment can access. It begins exfiltrating customer data, payment information, intellectual property. But it doesn’t stop there.

The production environment has access to a centralized logging system. Gaining access to it, the malicious script deletes logs to hide its activities and then uses the logging system to access other systems within the organization.

Importance of Pipeline-Based Access Controls in CI/CD

In the event of a compromise, the malicious code running in the context of the pipeline execution node has the full permissions of the pipeline stage in which it’s running. The code can access secrets, access the underlying host, and connect to systems the pipeline has access to. This can lead to exposure of confidential data, lateral movement within the CI environment — potentially accessing servers and systems outside the CI environment — and deployment of malicious artifacts down the pipeline, including to production.

The extent of the potential damage of a scenario in which an attacker can compromise pipeline execution nodes or inject malicious code into the build process is determined by the granularity of the pipeline-based access controls in the environment.

Risks Associated with Insufficient Pipeline-Based Access Controls

Insufficient pipeline-based access controls expose organizations to significant risks, from unauthorized alterations in code or pipeline configurations to a complete pipeline takeover or the exponential blast radius of supply chain poisoning.

Case Study 1: Lateral Movement Via Insufficient Pipeline-Based Access Controls

Threat actors have exploited a dependency confusion vulnerability in NodeJS apps belonging to Amazon, Zillow, Lyft, and Slack, marking a new form of cyberattack. The attackers created packages that mirror the names of the companies' internal repositories. When hosted on public repositories, these malicious packages replaced the internal ones during application building. The strategy enabled the injection of harmful code, the theft of Linux/Unix password files, and the opening of reverse shells.

Organizations attacked via dependency confusion had malicious code executed on CI nodes, allowing the adversary to move laterally within the environment and abuse insufficient pipeline-based access controls. The discovery of these malicious packages by security firm Sonatype emphasizes the need for application developers to enhance their pipeline-based access controls and secure their configuration files against supply chain attacks.

Case Study 2: How a Data Breach Occurred Due to Inadequate Pipeline-Based Access Controls

In April 2021, Teleport discovered a vulnerability that could allow a malicious pull request to gain access to their production environment. The attack could pivot from a Kubernetes worker pod to the node and exfiltrate credentials from the CI/CD system. This vulnerability exposed production AWS credentials, potentially allowing alteration of release artifacts and access to production cloud services.

Preventing Insufficiency in Pipeline-Based Access Controls

Despite their importance, pipeline-based access controls are often inadequately implemented in CI/CD pipelines, exposing organizations to unnecessary risks. This deficiency might stem from a lack of awareness about the significance of pipeline-based access controls or from the complexity involved in implementing them across the stages of the pipeline. Organizations, however, can transform their risk profiles by adopting these all-important recommendations:

1. Do not use a shared node for pipelines with different levels of sensitivity / that require access to different resources. Shared nodes should be used only for pipelines with identical levels of confidentiality.
2. Ensure secrets that are used in CI/CD systems are scoped in a manner that allows each pipeline and step to have access to only the secrets it requires.
3. Revert the execution node to its pristine state after each pipeline execution.
4. Grant the OS user running the pipeline job OS permissions on the execution node according to the principle of least privilege.
5. Limit permissions of CI and CD pipeline jobs on the controller node. Where applicable, run pipeline jobs on a separate, dedicated node.
6. Ensure the execution node is appropriately patched.
7. Configure network segmentation in the environment the job is running on to allow the execution node to access only the resources it requires within the network. Refrain from granting unlimited access toward the internet to build nodes.
8. When executing installation scripts as part of the package installation, ensure a separate context exists for those scripts, which does not have access to secrets and other sensitive resources available in other stages in the build process.

Industry Standards for Pipeline-Based Access Controls

Applying industry standards — the principle of least privilege (PoLP), regular access reviews, separation of duties — lay the foundation for effective pipeline-based access controls and CI/CD security.

Do your DevOps processes align with best practices?

Employ a Centralized Pipeline-Based Access Controls System

Your teams can’t adhere to least privilege without a centralized platform to calculate effective permissions granted to users. Cloud identity and entitlement management (CIEM), as part of a comprehensive CNAPP, plays a vital role in managing pipeline-based access controls, particularly across multicloud environments. The centralized CIEM offers full visibility into net permissions, allowing organizations to manage and control access rights consistently across all stages of the CI/CD pipeline.

Regularly Rotate Access Tokens and Secrets

Access tokens and secrets used within the CI/CD pipeline should be rotated regularly. By setting a regular rotation schedule, organizations can ensure that even if a token or secret is compromised, the window of opportunity for an attacker is limited.

Monitoring Pipeline Execution

Monitoring the execution of the CI/CD pipeline can prevent the exploitation of insufficient access controls. Automated monitoring and alerting systems can provide real-time notifications of anomalies, such as unexpected access and suspicious actions potentially indicating a breach of access controls.

Related: Protecting Your Delivery Pipeline: Extensive CI/CD Security

Insufficient Pipeline-Based Access Controls FAQs