---
title: 'CICD-SEC-8: Ungoverned Usage of 3rd Party Services'
description: OWASP CI/CD Top 10 reference for ungoverned third-party service usage including excessive permissions and unaudited integrations
---

# 08 Ungoverned Usage of 3rd Party Services

Identifier: CICD-SEC-8:2025
Category: Third-Party Governance

## Description

The CI/CD attack surface consists of an organization's organic assets, such as the SCM or CI, and
the third-party services which are granted access to those organic assets. Risks having to do with
ungoverned usage of third-party services rely on the extreme ease with which a third-party service
can be granted access to resources in CI/CD systems, effectively expanding the attack surface of the
organization.

Third-party applications can be connected through many methods depending on the platform, including
marketplace applications, OAuth applications, provisioned access tokens, provisioned SSH keys, and
webhook events. Each method takes seconds to minutes to implement and can grant third parties
numerous capabilities, ranging from reading code in a single repository to fully administering the
organization. In many cases no special permissions or approvals are required by the organization
prior to implementation.

Build systems also allow easy integration of third parties by adding one or two lines of code to
the pipeline configuration file or installing a plugin from a marketplace. The third-party
functionality is imported and executed as part of the build process with full access to whatever
resources are available from the pipeline stage.

Organizations face significant challenges in obtaining full visibility around which third parties
have access to different systems, what methods of access they have, what level of permissions they
have been granted, and what level of permissions they actually use.

## Risk

* Organizations are only as secure as the third parties they implement.
* Insufficient RBAC and least privilege around third parties, coupled with minimal governance and
  diligence, significantly increase the organization's attack surface.
* Compromise of a single third party can cause damage far outside the scope of the system the
  third party is connected to.
* Third parties with write permissions on a repository can be leveraged to push code that
  triggers a build and runs malicious code on the build system.
* Third parties integrated into build processes execute with full access to pipeline stage
  resources including secrets.
* Lack of visibility over the actual permissions used by third parties versus permissions granted
  prevents effective access control.

## Vulnerability checklist

* Third-party services are granted access to CI/CD systems without a formal approval or vetting
  process.
* Third-party permissions exceed the minimum required for their function.
* No comprehensive inventory exists of all third parties integrated with CI/CD systems.
* Third-party integrations are not reviewed for all methods of access (marketplace apps, OAuth,
  tokens, SSH keys, webhooks).
* Third parties integrated into build processes run without scoped access to secrets and code.
* No ingress or egress filters exist for third-party components executing within pipelines.
* Unused or redundant third-party integrations are not periodically removed.
* Third-party integrations lack predetermined expiry or review dates.

## Prevention controls

1. Establish vetting procedures to ensure third parties are approved prior to being granted
   access and that their permissions align with the principle of least privilege.
2. Introduce controls and procedures to maintain continuous visibility over all third parties
   integrated to CI/CD systems, including method of integration, permissions granted, and
   permissions actually used.
3. Limit and scope each third party to the specific resources it requires access to.
4. Ensure third parties executing as part of the build process run inside a scoped context with
   limited access to secrets and code, and with strict ingress and egress filters.
5. Remove unused and redundant third-party permissions.
6. Periodically review all third-party integrations and deprovision those no longer in use.
7. Require predetermined expiry dates for third-party access grants.

## Example attack scenarios

### Scenario A — Compromised code coverage tool

A popular code coverage tool is integrated into the CI pipeline through a marketplace application.
The tool's infrastructure is compromised by an attacker, who modifies the tool's script to
exfiltrate environment variables from builds. Since the tool executes within the build context with
access to all pipeline secrets, the attacker steals credentials for cloud providers, artifact
registries, and the SCM from every organization using the compromised tool.

### Scenario B — OAuth token theft from analytics platform

A git analytics platform is granted OAuth access to the organization's GitHub repositories for
code analysis. An attacker gains access to the analytics platform's database and steals the stored
OAuth tokens for all customers. The attacker uses the tokens to access and modify source code in
production repositories, inject backdoors, and trigger deployment pipelines.

## Detection guidance

* Enumerate all third-party integrations across CI/CD systems, covering all methods of access
  (marketplace apps, OAuth applications, access tokens, SSH keys, webhooks).
* Compare permissions granted to each third party against permissions actually used.
* Monitor third-party activity logs for unexpected access patterns.
* Alert on new third-party integrations being added without going through the approval process.
* Audit pipeline configurations for third-party components that execute with pipeline-level
  credentials.
* Review webhook configurations for endpoints that are no longer maintained or recognized.

## Remediation

* Conduct a comprehensive inventory of all third-party integrations across every CI/CD system.
* Remove all third-party integrations that are unused, redundant, or unrecognized.
* Reduce permissions of remaining third-party integrations to the minimum required.
* Implement an approval workflow for new third-party integrations with mandatory security review.
* Scope third-party components in build pipelines to isolated contexts with restricted secret
  access and network filtering.
* Establish expiry dates on all third-party access grants and implement periodic re-certification.
* Rotate all credentials that third-party services have had access to after removing unnecessary
  integrations.
