What Is Insufficient Pipeline-Based Access Controls?

5 min. read

Table of Contents

CICD-SEC-5: Insufficient Pipeline-Based Access Controls Explained
Importance of Pipeline-Based Access Controls in CI/CD
Preventing Insufficiency in Pipeline-Based Access Controls
Industry Standards for Pipeline-Based Access Controls
Insufficient Pipeline-Based Access Controls FAQs

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:

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.
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.
Revert the execution node to its pristine state after each pipeline execution.
Grant the OS user running the pipeline job OS permissions on the execution node according to the principle of least privilege.
Limit permissions of CI and CD pipeline jobs on the controller node. Where applicable, run pipeline jobs on a separate, dedicated node.
Ensure the execution node is appropriately patched.
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.
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.

Insufficient Pipeline-Based Access Controls FAQs

A service account is a type of account used by an application or service rather than a human. Service accounts have permissions and can authenticate to systems or services to perform certain tasks. Unlike user accounts, passwords to service accounts aren’t regularly rotated. This, coupled with broad permissions, makes service accounts potential security risks.

A pipeline execution node is a server or a virtual machine in a CI/CD environment where pipeline jobs — code compilation, testing, or software deployment — are executed. Each node possesses a distinct set of resources and permissions, which can be configured to handle certain jobs based on the computational power or security levels needed.

Root privilege refers to administrator rights, the highest level of access granted to a process or job running within the pipeline. The job with root privileges has unrestricted access to all resources and commands in the environment where the pipeline is running. It can read, write, or delete a file, alter the system configuration, install software, and perform any operation that the system allows.

An access control list is a list of permissions attached to an object. It specifies which users or system processes are granted access to objects, and what operations are allowed on given objects.

Often used in DevOps to give temporary access to perform specific tasks, just-in-time access is an access control model that grants privileges just at the moment of need. By reducing the window of opportunity for an attacker to exploit these permissions, JIT access minimizes the risk of unauthorized access or privilege escalation. It’s an element of the principle of least privilege (PoLP), a widely accepted best practice in information security.

The principle of least privilege is a computer security concept in which a user — human or machine — is given the minimum levels of access necessary to complete their job. This principle applies to control access in pipeline stages.

Role-based access control is a method of managing users' access to a system or network resources based on their roles within an organization. It helps manage permissions across a CI/CD pipeline.

An access token is a digital key that allows software to access and use an API, a system, or a service. It’s issued after successful authentication of a user or a system and carries information about the user's identity, the scope of permissions, and the token's validity period. In CI/CD pipelines, access tokens can be used to authenticate and authorize requests.

Signing keys form part of a cryptographic system used to verify the authenticity and integrity of data, such as digital messages or software packages. A signing key is used to create a digital signature for a piece of data. Anyone with the corresponding public key can verify this signature, proving that the data has not been tampered with and originates from the claimed source. Signing keys play a vital role in ensuring the security and trustworthiness of digital communications and transactions.

Multifactor authentication is a security mechanism that requires users to provide two or more verification factors to gain access to a resource. It can be used in CI/CD pipelines to enhance security.

Secrets management refers to the tools and methods for managing secrets — or digital authentication credentials — such as passwords, tokens, and API keys.

Identity federation is a trust and interoperability mechanism where identities are managed across multiple security domains, which enables a user to use the same credentials to access resources across these domains. Interoperability through standards such as Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) facilitates secure, seamless authentication and authorization.

Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties. It’s often used to enable single-sign-on (SSO) solutions, which can simplify access control in CI/CD pipelines.