Owasp Cicd

OWASP® CI/CD Top 10 — Skill Entry

This SKILL.md is the entrypoint for the OWASP CI/CD Top 10 skill.

The skill encodes the OWASP Top 10 CI/CD Security Risks as structured, machine-readable references that an agent can query to identify, assess, and remediate CI/CD pipeline security risks.

Normative references (CI/CD Top 10)

1. 00 Vulnerability Index 2. 01 Insufficient Flow Control Mechanisms 3. 02 Inadequate Identity and Access Management 4. 03 Dependency Chain Abuse 5. 04 Poisoned Pipeline Execution 6. 05 Insufficient PBAC 7. 06 Insufficient Credential Hygiene 8. 07 Insecure System Configuration 9. 08 Ungoverned Usage of 3rd Party Services 10. 09 Improper Artifact Integrity Validation 11. 10 Insufficient Logging and Visibility

Skill layout

• SKILL.md — this file (skill entrypoint).
• references/ — the CI/CD Top 10 normative documents.
• 00-vulnerability-index.md — index of all vulnerability identifiers, categories, and cross-references.
• 01 through 10 — one document per vulnerability aligned with OWASP CI/CD Security numbering.

Third-Party Attribution

Copyright © OWASP Foundation. OWASP® Top 10 CI/CD Security Risks content is derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Source: <https://owasp.org/www-project-top-10-ci-cd-security-risks/> Modifications: Vulnerability descriptions restructured into agent-consumable reference documents with added detection and remediation guidance. OWASP® is a registered trademark of the OWASP Foundation. Use does not imply endorsement.

00 Vulnerability Index

This document provides the index for the OWASP CI/CD Security Top 10 vulnerabilities. Each entry includes its identifier, title, and primary category.

Vulnerability catalog

Cross-reference matrix

Each vulnerability document follows a consistent structure:

1. Description — what the vulnerability is and how it manifests in CI/CD environments. 2. Risk — concrete consequences of exploitation and business impact. 3. Vulnerability checklist — indicators that the environment is exposed. 4. Prevention controls — defensive measures and rectification steps. 5. Example attack scenarios — realistic exploitation narratives. 6. Detection guidance — signals and methods to identify exposure. 7. Remediation — immediate and long-term actions to contain and resolve.

Category groupings

Flow Control

• CICD-SEC-1:2025 Insufficient Flow Control Mechanisms

Identity Management

• CICD-SEC-2:2025 Inadequate Identity and Access Management

Supply Chain

• CICD-SEC-3:2025 Dependency Chain Abuse

Pipeline Security

• CICD-SEC-4:2025 Poisoned Pipeline Execution

Access Controls

• CICD-SEC-5:2025 Insufficient PBAC

Credential Management

• CICD-SEC-6:2025 Insufficient Credential Hygiene

Configuration Management

• CICD-SEC-7:2025 Insecure System Configuration

Third-Party Governance

• CICD-SEC-8:2025 Ungoverned Usage of 3rd Party Services

Artifact Integrity

• CICD-SEC-9:2025 Improper Artifact Integrity Validation

Logging and Visibility

• CICD-SEC-10:2025 Insufficient Logging and Visibility

01 Insufficient Flow Control Mechanisms

Identifier: CICD-SEC-1:2025 Category: Flow Control

Description

Insufficient flow control mechanisms refer to the ability of an attacker that has obtained permissions to a system within the CI/CD process (SCM, CI, artifact repository) to single-handedly push malicious code or artifacts down the pipeline, due to a lack of mechanisms that enforce additional approval or review.

CI/CD flows are designed for speed. New code can be created on a developer's machine and reach production within minutes, often with full reliance on automation and minimal human involvement. Since CI/CD processes are the highway to highly gated and secured production environments, organizations must introduce measures and controls to ensure that no single entity (human or application) can push code or artifacts through the pipeline without undergoing a strict set of reviews and approvals.

Risk

• An attacker with access to the SCM, CI, or downstream systems can deploy malicious artifacts

potentially all the way to production without any approval or review.

• Pushing code to a repository branch that is automatically deployed through the pipeline to

production.

• Abusing auto-merge rules that automatically merge pull requests meeting a predefined set of

requirements, pushing malicious unreviewed code.

• Abusing insufficient branch protection rules, such as excluding specific users or branches, to

bypass protections and push malicious unreviewed code.

• Uploading artifacts to a repository in the guise of a legitimate artifact created by the build

environment, which may be picked up by a deploy pipeline and deployed to production.

• Directly changing application code or infrastructure in production without additional verification.

Vulnerability checklist

• Repository branches hosting production code lack branch protection rules.
• Users or branches are excluded from branch protection rules.
• Auto-merge rules exist that can be bypassed or manipulated.
• Pipeline triggers do not require additional approval for production deployments.
• Artifacts uploaded by non-CI service accounts are not blocked or reviewed before flowing through

the pipeline.

• No drift detection exists between code running in production and its CI/CD origin.
• Single accounts have both push-to-repository and trigger-deployment permissions.

Prevention controls

1. Configure branch protection rules on branches hosting code used in production and other sensitive systems. 2. Avoid excluding user accounts or branches from branch protection rules. 3. Ensure accounts with permission to push unreviewed code do not also have permission to trigger deployment pipelines connected to the repository. 4. Limit auto-merge rule usage and ensure they apply to the minimal number of contexts. 5. Review auto-merge rule code thoroughly to prevent bypass and avoid importing third-party code in the auto-merge process. 6. Prevent accounts from triggering production build and deployment pipelines without additional approval or review. 7. Allow artifacts to flow through the pipeline only when created by a pre-approved CI service account. 8. Detect and prevent drifts between code running in production and its CI/CD origin, and modify any resource that contains a drift.

Example attack scenarios

Scenario A — Unprotected branch deployment

An attacker gains access to a developer account on the SCM. The main branch lacks branch protection rules. The attacker pushes malicious code directly to the main branch, triggering an automated pipeline that deploys the code to production without any review or approval gate.

Scenario B — Auto-merge rule bypass

An organization uses auto-merge rules to merge pull requests that pass automated checks. An attacker crafts a pull request that satisfies the auto-merge criteria while containing a malicious payload hidden in an overlooked file type. The PR is automatically merged and deployed to production without human review.

Detection guidance

• Audit branch protection rule configurations across all repositories hosting production code.
• Review auto-merge rule logic and history of auto-merged pull requests for anomalies.
• Monitor pipeline triggers and correlate them with code review and approval records.
• Detect configuration drifts between deployed resources and their CI/CD source definitions.
• Alert on artifacts flowing through deployment pipelines that were not produced by approved CI

service accounts.

Remediation

• Enable and enforce branch protection rules on all branches linked to production deployments.
• Remove all user and branch exclusions from branch protection rules.
• Separate push-to-repository and trigger-deployment permissions across distinct accounts.
• Audit and harden all auto-merge rules, removing those that are overly permissive.
• Implement artifact provenance validation to ensure only CI-produced artifacts enter deploy

pipelines.

• Deploy drift detection tooling to identify and alert on unauthorized production changes.

02 Inadequate Identity and Access Management

Identifier: CICD-SEC-2:2025 Category: Identity Management

Description

Inadequate identity and access management risks stem from the difficulties in managing the vast amount of identities spread across the different systems in the engineering ecosystem, from source control to deployment. The existence of poorly managed identities, both human and programmatic accounts, increases the potential and the extent of damage of their compromise.

Software delivery processes consist of multiple systems connected together with the aim of moving code and artifacts from development to production. Each system provides multiple methods of access and integration (username and password, personal access tokens, marketplace applications, OAuth applications, plugins, SSH keys). The different types of accounts and methods of access can potentially have their own unique provisioning method, set of security policies, and authorization model. This complexity creates challenges in managing identities throughout the entire identity lifecycle and ensuring their permissions are aligned with the principle of least privilege.

Major concerns include overly permissive identities, stale identities that are no longer active, local identities not federated with a centralized identity provider, external identities registered with unmanaged email domains or belonging to external collaborators, self-registered identities with overly broad default permissions, and shared identities used across multiple humans or applications.

Risk

• Compromising nearly any user account on any CI/CD system could grant powerful capabilities to

the environment and serve as a path into the production environment.

• Hundreds or thousands of identities across the ecosystem, paired with a lack of strong IAM

practices and overly permissive accounts, drastically expand the attack surface.

• Stale accounts remain valid entry points for attackers long after the original user has departed.
• Local accounts bypass centralized security policies including MFA enforcement and lockout rules.
• External collaborator accounts reduce overall security to the level of the external party's

environment.

• Shared identities eliminate accountability and expand credential exposure footprint.

Vulnerability checklist

• Human or programmatic accounts have permissions beyond what is required for their role.
• Inactive accounts exist that have not been disabled or removed within the acceptable period.
• Local user accounts exist on CI/CD systems that are not federated with a centralized IdP.
• Employees use personal email addresses or domains not owned by the organization.
• External collaborators have access without predetermined expiry dates.
• Self-registration is enabled on CI/CD systems with non-zero default permissions.
• Shared accounts are in use across multiple humans or applications.
• No periodic review process exists for identity permissions across the ecosystem.

Prevention controls

1. Conduct continuous analysis and mapping of all identities across all systems within the engineering ecosystem, covering all methods of programmatic access. 2. Remove permissions not necessary for the ongoing work of each identity across all systems. 3. Determine an acceptable period for disabling or removing stale accounts and enforce it. 4. Avoid creating local user accounts; manage identities using a centralized identity provider. 5. Continuously map all external collaborators and ensure their identities follow least privilege, with predetermined expiry dates for both human and programmatic accounts. 6. Prevent employees from using personal email addresses or non-organization-owned domains on CI/CD platforms. 7. Disable self-registration on CI/CD systems and grant permissions on an as-needed basis. 8. Avoid granting base permissions to all users or large automatically-assigned groups. 9. Avoid using shared accounts; create dedicated accounts for each specific context with exact required permissions.

Example attack scenarios

Scenario A — Stale account compromise

An engineer leaves the organization but their accounts on the SCM and CI system are not deprovisioned. An attacker compromises the former engineer's credentials through a credential stuffing attack. The stale account still has write access to production repositories, allowing the attacker to push malicious code through the pipeline.

Scenario B — Overly permissive self-registration

A self-managed CI system allows self-registration. New accounts are assigned a base set of permissions that includes access to pipeline configurations and build logs. An attacker self-registers, gains access to the system, and discovers secrets exposed in build logs, which they use to access production cloud environments.

Detection guidance

• Periodically enumerate all identities across SCM, CI, artifact repositories, and deployment

systems, checking for stale, overly permissive, or shared accounts.

• Monitor for logins from non-organization-owned email domains.
• Audit self-registration settings and default permission assignments.
• Alert on identity creation events and permission escalation events across CI/CD systems.
• Review external collaborator access lists and expiration dates.

Remediation

• Deprovision all stale accounts across every CI/CD system.
• Federate all local accounts to the centralized identity provider.
• Enforce MFA on all human accounts across all CI/CD systems.
• Remove base permissions from self-registered or automatically-assigned groups.
• Replace all shared accounts with dedicated, individually-scoped accounts.
• Establish automated workflows to disable external collaborator access upon contract expiry.
• Implement periodic access reviews with mandatory re-certification of identity permissions.

03 Dependency Chain Abuse

Identifier: CICD-SEC-3:2025 Category: Supply Chain

Description

Dependency chain abuse risks refer to an attacker's ability to abuse flaws relating to how engineering workstations and build environments fetch code dependencies. Dependency chain abuse results in a malicious package inadvertently being fetched and executed locally when pulled.

Managing dependencies and external packages is increasingly complex given the total number of systems involved across all development contexts. Packages are fetched using dedicated clients per programming language, typically from a combination of self-managed package repositories and language-specific SaaS repositories. Inadequate configurations may cause an engineer or the build system to download a malicious package instead of the intended one, and in many cases the package is immediately executed after download due to pre-install scripts.

The main attack vectors are dependency confusion (publishing malicious packages in public repositories with the same name as internal packages), dependency hijacking (compromising a package maintainer's account to upload malicious versions), typosquatting (publishing packages with names similar to popular packages), and brandjacking (publishing packages that mimic a trusted brand's naming conventions).

Risk

• Malicious code executes on developer workstations or build servers when a poisoned package is

pulled.

• Credential theft and lateral movement within the environment where the malicious code executes.
• Malicious code can make its way to production from the build server, potentially maintaining

the original safe functionality to reduce probability of discovery.

• Internal package names leaked to public repositories enable dependency confusion attacks.
• Build environments fetching packages directly from the internet without proxy controls are

exposed to all dependency chain attack vectors.

Vulnerability checklist

• Clients fetch packages directly from external repositories without routing through an internal

proxy.

• Internal package names are not registered under the organization's scope.
• No checksum or signature verification is configured for pulled packages.
• Clients are configured to pull the latest version of a package rather than a pinned version.
• Package manager configuration files (such as .npmrc) are absent from project repositories.
• Pre-install scripts execute in a context with access to secrets and sensitive resources.
• Names of internal projects are published or discoverable in public repositories.
• No controls exist to prevent dependency confusion between internal and external registries.

Prevention controls

1. Route all package fetches through an internal proxy rather than directly from the internet. 2. Where applicable, configure all clients to pull packages only from internal repositories containing pre-vetted packages, and enforce this client configuration. 3. Enable checksum verification and signature verification for all pulled packages. 4. Pin package versions to pre-vetted versions or ranges and use framework-specific lock files. 5. Register all private packages under the organization's scope. 6. Ensure all code referencing a private package uses the package's scope. 7. Force clients to fetch scoped packages solely from the internal registry. 8. Run pre-install scripts in a separate context without access to secrets or other sensitive resources. 9. Include package manager configuration files in every project repository to override insecure default client configurations. 10. Avoid publishing names of internal projects in public repositories.

Example attack scenarios

Scenario A — Dependency confusion

An attacker discovers the name of an internal NPM package used by the organization by finding references in a public repository. The attacker publishes a package with the same name on the public NPM registry with a higher version number. The build system, configured to check both internal and public registries, pulls the higher-versioned malicious package. The pre-install script executes, exfiltrating environment variables containing cloud credentials.

Scenario B — Dependency hijacking

An attacker compromises the account of a maintainer of a widely-used Python package on PyPI. They upload a new version containing a backdoor that executes during installation. Organizations configured to pull the latest version of the package automatically fetch and execute the compromised version on their build servers, granting the attacker access to build secrets and deployment credentials.

Detection guidance

• Monitor package manager audit logs for unexpected package sources or version changes.
• Compare checksums of fetched packages against known-good values.
• Alert on packages pulled from public registries that share names with internal packages.
• Audit package manager client configurations across build environments and developer

workstations.

• Scan dependency lock files for unexpected version changes or new dependencies.
• Monitor outbound network connections from build nodes during dependency installation.

Remediation

• Configure internal proxies as the sole package source for all build environments and developer

workstations.

• Register all internal package names under the organization's scope on relevant public

registries to prevent namespace squatting.

• Pin all dependency versions and enforce lock file usage.
• Enable checksum and signature verification across all package manager configurations.
• Isolate pre-install script execution from secrets and sensitive build resources.
• Remove any references to internal package names from public repositories.
• Harden all build environments according to the guidelines under CICD-SEC-7.

04 Poisoned Pipeline Execution

Identifier: CICD-SEC-4:2025 Category: Pipeline Security

Description

Poisoned Pipeline Execution (PPE) risks refer to the ability of an attacker with access to source control systems, and without access to the build environment, to manipulate the build process by injecting malicious code or commands into the build pipeline configuration, essentially poisoning the pipeline and running malicious code as part of the build process.

The PPE vector abuses permissions against an SCM repository in a way that causes a CI pipeline to execute malicious commands. Users that have permissions to manipulate CI configuration files, or other files which the CI pipeline job relies on, can modify them to contain malicious commands. Pipelines executing unreviewed code, such as those triggered directly from pull requests or commits to arbitrary repository branches, are more susceptible to PPE.

There are three types of PPE:

Direct PPE (D-PPE) occurs when the attacker modifies the CI configuration file in a repository they have access to, either by pushing directly to an unprotected branch or by submitting a pull request. The pipeline execution is defined by the commands in the modified configuration file.

Indirect PPE (I-PPE) occurs when the pipeline configuration file is protected but the attacker injects malicious code into files referenced by the configuration, such as Makefiles, test frameworks, linter configurations, or scripts called from the pipeline.

Public PPE (3PE) targets public repositories that allow contributions from anonymous users. If the CI pipeline of a public repository runs unreviewed code suggested by anonymous users, it is susceptible to this attack, potentially exposing internal assets including secrets from private projects sharing the same CI instance.

Risk

• Access to any secret available to the CI job, including secrets injected as environment variables

and credentials for cloud providers, artifact registries, and the SCM itself.

• Access to external assets the job node has permissions to, such as files on the node's filesystem

or credentials to cloud environments accessible through the underlying host.

• Ability to ship malicious code and artifacts further down the pipeline in the guise of legitimate

build output.

• Ability to access additional hosts and assets in the network or environment of the job node.
• Lateral movement from the CI environment to production systems using stolen credentials.

Vulnerability checklist

• Pipelines execute code from unreviewed pull requests or commits to arbitrary branches.
• CI configuration files can be modified by contributors without review.
• Pipeline configuration files are stored in the same repository as source code without protection.
• Files referenced by the pipeline configuration (Makefiles, scripts, test files, linter configs)

can be modified without triggering a separate review process.

• Public repositories run CI pipelines on code submitted by anonymous contributors.
• Pipeline execution nodes have access to secrets beyond what is needed for the specific job.
• No isolation exists between pipeline nodes handling public and private repositories.
• Branch protection rules do not have correlating CI trigger restrictions.

Prevention controls

1. Ensure pipelines running unreviewed code execute on isolated nodes not exposed to secrets and sensitive environments. 2. Evaluate the need for triggering pipelines on public repositories from external contributors. Where possible, refrain from running pipelines originating from forks and consider requiring manual approval for pipeline execution. 3. For sensitive pipelines exposed to secrets, ensure each branch configured to trigger a pipeline has a correlating branch protection rule in the SCM. 4. Require review of CI configuration file changes before the pipeline runs, or manage the CI configuration file in a separate protected branch. 5. Remove unnecessary SCM repository permissions from users. 6. Scope each pipeline to only the credentials it needs with minimum required privileges. 7. Review and restrict which files referenced by the pipeline configuration can be modified without additional approval.

Example attack scenarios

Scenario A — Direct PPE credential theft

A GitHub Actions workflow is configured to trigger on push events. An attacker creates a new remote branch and modifies the workflow file to exfiltrate AWS credentials stored as repository secrets. The modified workflow loads the secrets into environment variables and sends them to an attacker-controlled server. The push triggers the pipeline, which executes the poisoned configuration and leaks the credentials.

Scenario B — Indirect PPE via Makefile

A Jenkins pipeline fetches its Jenkinsfile from a protected main branch, but the build stage runs a Makefile stored in the repository. An attacker creates a pull request modifying the Makefile to replace the build target with a command that exfiltrates all environment variables. Since the pipeline triggers on pull requests, the malicious Makefile content executes during the build stage where AWS credentials are loaded, sending them to the attacker.

Scenario C — Public PPE on open source project

An open source project runs CI on all pull requests. An attacker submits a pull request modifying the test suite to include malicious code. The CI pipeline executes the tests, running the attacker's code on the build node. Because the same CI instance services private repositories, the attacker accesses secrets belonging to private projects.

Detection guidance

• Monitor for modifications to CI configuration files in pull requests and pushes.
• Alert on pipeline executions triggered by unreviewed code from forks or external contributors.
• Audit which files referenced by pipeline configurations have been modified in recent commits.
• Monitor outbound network connections from build nodes for unexpected destinations.
• Review pipeline logs for unusual secret access patterns or commands.
• Compare pipeline configuration files against their protected branch versions before execution.

Remediation

• Isolate pipeline execution nodes that process unreviewed code from those handling sensitive

workloads.

• Move CI configuration files to protected branches and require review for all changes.
• Implement manual approval gates for pipelines triggered by external contributors.
• Restrict pipeline credentials using fine-grained scoping aligned with each job's requirements.
• Separate CI infrastructure for public and private repositories.
• Audit and lock down all files referenced by pipeline configurations (Makefiles, scripts, test

configurations, linter configurations).

• Enable and enforce branch protection rules with correlating pipeline trigger restrictions.

05 Insufficient PBAC

Identifier: CICD-SEC-5:2025 Category: Access Controls

Description

Pipeline-Based Access Controls (PBAC) refer to the context in which each pipeline, and each step within that pipeline, is running. Given the highly sensitive and critical nature of each pipeline, it is imperative to limit each pipeline to the exact set of data and resources it needs access to.

Pipeline execution nodes carry out commands specified in the pipeline configuration, performing sensitive activities including accessing source code, obtaining secrets from vaults and cloud identity services, creating and deploying artifacts, and connecting to production systems. When running malicious code within a pipeline, adversaries leverage insufficient PBAC to abuse the permissions granted to the pipeline for lateral movement within or outside the CI/CD system.

PBAC includes controls relating to access within the pipeline execution environment (code, secrets, environment variables, other pipelines), permissions to the underlying host and other pipeline nodes, and ingress and egress network filters.

Risk

• Malicious code running in the context of a pipeline execution node has the full permissions of

the pipeline stage, including access to all available secrets.

• Access to the underlying host and ability to connect to any system the pipeline has access to.
• Exposure of confidential data through overly broad secret scoping.
• Lateral movement within the CI environment and to servers and systems outside the CI

environment.

• Deployment of malicious artifacts down the pipeline, including to production.
• The extent of potential damage from a compromise is directly determined by the granularity of

PBAC in the environment.

Vulnerability checklist

• Shared pipeline nodes are used for pipelines with different levels of sensitivity or access

requirements.

• Secrets are not scoped to individual pipelines and steps, allowing broader access than required.
• Pipeline execution nodes are not reverted to a pristine state after each execution.
• The OS user running pipeline jobs has excessive permissions on the execution node.
• Pipeline jobs run on the controller node rather than separate dedicated nodes.
• Execution nodes are not regularly patched.
• Network segmentation does not restrict execution node access to only required resources.
• Build nodes have unrestricted internet access.
• Installation scripts execute with access to secrets and sensitive resources from other build

stages.

Prevention controls

1. Do not use shared nodes for pipelines with different levels of sensitivity. Use shared nodes only for pipelines with identical levels of confidentiality. 2. Scope secrets so that each pipeline and step has access to only the secrets it requires. 3. Revert the execution node to its pristine state after each pipeline execution. 4. Ensure the OS user running the pipeline job has permissions granted according to the principle of least privilege. 5. Run CI and CD pipeline jobs on separate, dedicated nodes rather than the controller node. 6. Keep execution nodes appropriately patched. 7. Configure network segmentation so execution nodes can access only the resources they require. Refrain from granting unlimited internet access to build nodes. 8. Ensure installation scripts execute in a separate context without access to secrets or sensitive resources from other build stages.

Example attack scenarios

Scenario A — Shared node secret leakage

An organization runs all pipeline jobs on a shared pool of nodes. A low-sensitivity open source project pipeline and a high-sensitivity production deployment pipeline share the same nodes. An attacker poisons the open source project's pipeline to enumerate environment variables and filesystem contents on the shared node. Because secrets from the production pipeline persist in memory and on disk from prior executions, the attacker exfiltrates production deployment credentials.

Scenario B — Unrestricted network lateral movement

A build node has unrestricted network access within the corporate environment. An attacker gains code execution on the build node through a compromised dependency. Using the node's network access, the attacker scans internal systems, discovers an unprotected internal service, and pivots to access production databases containing customer data.

Detection guidance

• Audit pipeline configurations to identify shared nodes servicing pipelines with differing

sensitivity levels.

• Review secret scoping across CI/CD systems to detect overly broad access grants.
• Monitor execution node state to verify pristine-state restoration after each pipeline run.
• Inspect OS user permissions on execution nodes.
• Monitor network traffic from execution nodes for connections to unexpected destinations.
• Alert on pipeline jobs executing on controller nodes.

Remediation

• Segregate pipeline execution nodes by sensitivity level, dedicating node pools to pipelines

with matching confidentiality requirements.

• Re-scope all secrets to the minimum set of pipelines and steps that require them.
• Implement ephemeral pipeline execution nodes that are destroyed and recreated for each job.
• Reduce OS user privileges on execution nodes to the minimum required for job execution.
• Move all pipeline jobs off the controller node to dedicated worker nodes.
• Establish a patch management cadence for all execution nodes.
• Implement network segmentation and egress filtering on all build node networks.

06 Insufficient Credential Hygiene

Identifier: CICD-SEC-6:2025 Category: Credential Management

Description

Insufficient credential hygiene risks deal with an attacker's ability to obtain and use various secrets and tokens spread throughout the pipeline due to flaws having to do with access controls around credentials, insecure secret management, and overly permissive credentials.

CI/CD environments are built of multiple systems communicating and authenticating against each other, creating challenges around protecting credentials due to the large variety of contexts in which credentials can exist. Application credentials are used at runtime, credentials to production systems are used by pipelines to deploy infrastructure, and engineers use credentials in testing environments and within their code and artifacts.

Major flaws affecting credential hygiene include credentials committed to SCM repositories (remaining visible in commit history even after deletion), credentials used insecurely inside build and deployment processes, credentials left in container image layers, credentials printed to console output and log management systems, and unrotated credentials that accumulate exposure over time.

Risk

• Credentials are the most sought-after object by adversaries seeking access to high-value

resources or to deploy malicious code and artifacts.

• Engineering environments provide attackers with multiple avenues to obtain credentials.
• Credentials committed to code repositories persist in commit history indefinitely.
• Secrets printed to build console output are exposed to anyone with access to build results and

may flow to centralized log management systems.

• Credentials embedded in container image layers are accessible to anyone who can download the

image.

• Unrotated credentials allow a constantly growing number of people and artifacts to hold valid

credentials.

• Shared credentials increase exposure footprint and reduce accountability.

Vulnerability checklist

• Credentials are present in code committed to SCM repository branches, including in commit

history.

• Secrets are used in CI/CD builds without scoping to specific pipelines and steps.
• Pipeline credentials can be accessed by unreviewed code flowing through the pipeline.
• Credentials are injected into the build in a manner that makes them accessible outside runtime.
• Secrets exist in container image layers.
• Credentials are printed to pipeline console output in cleartext.
• Static credentials exist that have not been rotated within the defined rotation period.
• The same set of credentials is shared across multiple contexts.
• Credentials lack usage conditions such as source IP restrictions or identity binding.
• No automated scanning exists for secrets in code repositories.

Prevention controls

1. Establish procedures to continuously map credentials across the engineering ecosystem and ensure each set follows the principle of least privilege. 2. Avoid sharing the same credentials across multiple contexts. 3. Prefer temporary credentials over static credentials. For static credentials, establish periodic rotation procedures and detect stale credentials. 4. Configure credential usage conditions such as scoping to specific source IPs or identities. 5. Detect secrets pushed to code repositories using IDE plugins, push-time scanning, and periodic repository scans covering past commits. 6. Scope secrets in CI/CD systems so each pipeline and step accesses only the secrets it requires. 7. Use built-in vendor options or third-party tools to prevent secrets from being printed to pipeline console outputs and audit existing outputs for secret exposure. 8. Verify that secrets are removed from all artifact types including container image layers, binaries, and Helm charts.

Example attack scenarios

Scenario A — Credentials in commit history

A developer accidentally commits AWS access keys to a repository. The keys are removed in a subsequent commit, but remain visible in the commit history. An attacker with read access to the repository browses the commit history, extracts the keys, and uses them to access the organization's cloud infrastructure and exfiltrate data from production S3 buckets.

Scenario B — Secrets exposed in build logs

A CI pipeline prints environment variables to the console output during a debugging step that was never removed. The build logs, including plaintext credentials for the production database, flow to the centralized log management system. An attacker who gains access to the logging platform discovers the credentials and uses them to access the production database.

Detection guidance

• Scan all repositories for secrets in current branches and historical commits using automated

secret detection tools.

• Audit CI/CD pipeline configurations for secrets injected as environment variables and assess

their scope.

• Review pipeline console outputs for exposed credentials.
• Inspect container images layer by layer to detect embedded secrets.
• Monitor credential usage patterns and alert on access from unexpected sources or contexts.
• Track credential rotation dates and alert on credentials that exceed the defined rotation

period.

Remediation

• Rotate all credentials known or suspected to have been exposed.
• Remove secrets from repository commit history using history-rewriting tools and invalidate the

exposed credentials.

• Implement automated secret scanning in pre-commit hooks, CI pipelines, and periodic repository

scans.

• Re-scope all pipeline secrets to the minimum set of pipelines and steps that require them.
• Mask or redact all secrets in pipeline console outputs.
• Rebuild container images to eliminate secrets from intermediate layers using multi-stage builds.
• Establish and enforce a credential rotation policy with automated tracking and alerting.
• Replace shared credentials with dedicated, individually-scoped credentials.

07 Insecure System Configuration

Identifier: CICD-SEC-7:2025 Category: Configuration Management

Description

Insecure system configuration risks stem from flaws in the security settings, configuration, and hardening of the different systems across the pipeline (SCM, CI, artifact repository), often resulting in low-effort attack vectors for adversaries looking to expand their foothold in the environment.

CI/CD environments are comprised of multiple systems provided by a variety of vendors. These systems involve various security settings and configurations at the application, network, and infrastructure levels that have a major influence on security posture and susceptibility to compromise.

Examples of potential hardening flaws include self-managed systems running outdated versions or lacking security patches, systems with overly permissive network access controls, self-hosted systems that have administrative permissions on the underlying OS, systems with insecure default configurations around authorization, access controls, and logging, and systems with inadequate credential hygiene such as default credentials that are not disabled.

While SaaS CI/CD solutions eliminate some risks associated with system hardening and lateral movement, organizations remain responsible for securely configuring their SaaS solutions, each of which has unique security configurations and best practices.

Risk

• Security flaws in CI/CD systems may be leveraged to obtain unauthorized access or compromise

the system and access the underlying OS.

• Flaws may be abused to manipulate legitimate CI/CD flows, obtain sensitive tokens, and

potentially access production environments.

• Lateral movement within the environment and outside the context of CI/CD systems becomes

possible through compromised nodes.

• Self-managed systems left accessible from the internet with default credentials expose source

code and secrets.

• Debug permissions on execution nodes may allow engineers to access all secrets loaded into

memory and use the node's identity.

Vulnerability checklist

• Self-managed CI/CD systems run outdated versions or lack security patches.
• CI/CD systems have overly permissive network access controls, including internet-facing

instances without access restrictions.

• Self-hosted systems have administrative permissions on the underlying OS.
• Default system configurations have not been reviewed and hardened for security.
• Default credentials exist that are not disabled or changed.
• Overly permissive programmatic tokens are in use.
• Engineers have debug permissions on execution nodes, granting access to secrets in memory.
• No inventory exists of CI/CD systems, versions, and designated owners.
• No periodic review process exists for system security configurations.

Prevention controls

1. Maintain an inventory of all CI/CD systems and versions in use, with a designated owner for each system. 2. Continuously check for known vulnerabilities and apply security patches when available. If a patch is not available, consider removing the component or restricting access. 3. Ensure network access to CI/CD systems is aligned with the principle of least access. 4. Establish a process to periodically review all system configurations that affect security posture, ensuring all settings are optimal. 5. Ensure permissions to pipeline execution nodes follow the principle of least privilege. 6. Restrict debug permissions on execution nodes, recognizing that users with debug access can expose secrets loaded in memory and use the node's identity. 7. Disable default credentials and replace them with properly managed credentials. 8. Ensure all SaaS CI/CD solution configurations are reviewed against vendor-specific security best practices.

Example attack scenarios

Scenario A — Internet-exposed SCM with default credentials

A self-managed Bitbucket instance is left accessible from the internet with default credentials enabled. An attacker discovers the instance through an internet scan, logs in with default credentials, and gains access to all hosted source code repositories including those containing secrets and production deployment configurations.

Scenario B — Unpatched build server compromise

A self-managed Jenkins instance runs an outdated version with a known remote code execution vulnerability. The system is accessible from the internet. An attacker exploits the vulnerability to gain shell access on the Jenkins server, accesses stored pipeline credentials, and uses them to deploy malicious code to production through legitimate deployment pipelines.

Detection guidance

• Scan all CI/CD system instances for known vulnerabilities and outdated versions.
• Audit network access controls to identify internet-facing or overly permissive CI/CD systems.
• Check for the presence of default credentials across all CI/CD systems.
• Review system configurations against hardening baselines and vendor security best practices.
• Monitor for debug sessions on pipeline execution nodes.
• Enumerate and audit all programmatic tokens for excessive permissions.

Remediation

• Patch or upgrade all CI/CD systems to current, supported versions.
• Restrict network access to CI/CD systems, removing internet exposure where not required and

implementing IP allowlisting.

• Disable all default credentials and replace with properly managed alternatives.
• Conduct a comprehensive security configuration review of all CI/CD systems against hardening

baselines.

• Remove administrative OS permissions from self-hosted CI/CD systems.
• Restrict debug permissions on execution nodes to only those who require them, with appropriate

monitoring.

• Establish a vulnerability management cadence for all CI/CD infrastructure components.

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.

09 Improper Artifact Integrity Validation

Identifier: CICD-SEC-9:2025 Category: Artifact Integrity

Description

Improper artifact integrity validation risks allow an attacker with access to one of the systems in the CI/CD process to push malicious (although seemingly benign) code or artifacts down the pipeline, due to insufficient mechanisms for ensuring the validation of code and artifacts.

CI/CD processes consist of multiple steps, ultimately responsible for taking code all the way from an engineer's workstation to production. There are multiple resources being fed into each step, combining internal resources and artifacts with third-party packages and artifacts fetched from remote locations. The fact that the ultimate resource is reliant upon multiple sources spread across different steps, provided by multiple contributors, creates multiple entry points through which this ultimate resource can be tampered with.

If a tampered resource is able to infiltrate the delivery process without raising suspicion or encountering security gates, it will most likely continue flowing through the pipeline, all the way to production, in the guise of a legitimate resource.

Risk

• A malicious artifact shipped through the pipeline can result in the execution of malicious code

on systems within the CI/CD process or in production.

• Unsigned or unverified code commits can introduce tampered code without attribution.
• Tampered artifacts persisting across pipeline stages can compromise downstream systems.
• Third-party resources fetched without hash verification can be substituted with malicious

versions.

• Configuration drifts between deployed resources and CI/CD-managed templates may indicate

unauthorized changes deployed by untrusted sources.

Vulnerability checklist

• Code commits are not signed and the pipeline does not enforce commit signature verification.
• No artifact signing infrastructure exists to sign resources generated during the pipeline.
• Artifacts are not verified against a signing authority before being consumed in subsequent

pipeline stages.

• Third-party resources fetched during build or deploy are not verified against published hashes.
• No configuration drift detection exists for production resources versus their CI/CD source

definitions.

• Pipeline stages accept artifacts from untrusted sources without integrity checks.
• Container images used in production are not signed or verified before deployment.
• No software bill of materials (SBOM) is generated or tracked for pipeline-produced artifacts.

Prevention controls

1. Implement code signing and enforce signature verification on all commits before they enter the pipeline. 2. Sign all artifacts generated during the pipeline using an external resource signing infrastructure. 3. Verify artifact integrity against the signing authority before consuming resources in subsequent pipeline stages. 4. Calculate and cross-reference hashes of third-party resources against the official published hashes of the resource provider before use in build or deploy pipelines. 5. Implement configuration drift detection for production resources, alerting on resources that are not managed through a signed infrastructure-as-code template. 6. Generate and track software bills of materials for all pipeline-produced artifacts. 7. Enforce container image signing and verification before deployment to any environment.

Example attack scenarios

Scenario A — Tampered build artifact

An attacker gains access to the build server and modifies the application binary after it is compiled but before it is uploaded to the artifact repository. No signing or integrity validation exists between the build and deploy stages. The tampered binary is picked up by the deployment pipeline and deployed to production, executing the attacker's backdoor code on production servers.

Scenario B — Compromised third-party script

A CI pipeline fetches a third-party script from an external URL during the build process to perform a specific build task. An attacker gains access to the hosting environment of the third-party script and replaces it with a malicious version. Because the pipeline does not verify the script's hash against a known-good value, the compromised script is executed during the next build, stealing credentials and injecting a backdoor into the build output.

Detection guidance

• Audit pipeline configurations for stages that consume artifacts without integrity verification.
• Monitor for unsigned commits entering protected branches.
• Detect configuration drifts between production resources and their CI/CD source definitions.
• Compare hashes of fetched third-party resources against known-good reference values.
• Track artifact provenance across pipeline stages and alert on artifacts without valid

signatures.

• Monitor for container images deployed without valid signatures.

Remediation

• Deploy an artifact signing infrastructure and integrate signing into all pipeline stages.
• Enforce commit signature verification on all branches feeding into CI/CD pipelines.
• Implement hash verification for all third-party resources fetched during pipeline execution.
• Deploy configuration drift detection tooling for all production environments.
• Establish a policy requiring all artifacts to be signed before entering subsequent pipeline

stages.

• Implement container image signing and enforce verification before deployment.
• Generate and maintain SBOMs for all artifacts produced by CI/CD pipelines.
• Audit and remediate all existing pipeline stages that currently lack integrity validation.

10 Insufficient Logging and Visibility

Identifier: CICD-SEC-10:2025 Category: Logging and Visibility

Description

Insufficient logging and visibility risks allow an adversary to carry out malicious activities within the CI/CD environment without being detected during any phase of the attack kill chain, including identifying the attacker's TTPs (Techniques, Tactics, and Procedures) as part of any post-incident investigation.

The existence of strong logging and visibility capabilities is essential for an organization's ability to prepare for, detect, and investigate a security-related incident. While workstations, servers, network devices, and key IT and business applications are typically covered in depth within an organization's logging and visibility programs, it is often not the case with systems and processes in engineering environments.

Given the amount of potential attack vectors leveraging engineering environments and processes, it is imperative that security teams build the appropriate capabilities to detect these attacks as soon as they happen. As many of these vectors involve leveraging programmatic access against the different systems, a key aspect is to create strong levels of visibility around both human and programmatic access.

Both audit logs (user access, user creation, permission modification) and applicative logs (push events, build executions, artifact uploads) are equally important for maintaining sufficient visibility.

Risk

• Organizations that do not ensure appropriate logging and visibility around engineering

environments may fail to detect a breach entirely.

• Minimal investigative capabilities create great difficulties in mitigation and remediation after

a breach.

• Time and data are the most valuable commodities during incident response, and the absence of

all relevant data sources in a centralized location can be the difference between a successful and devastating outcome.

• Attackers can operate undetected for extended periods within CI/CD systems.
• Post-incident analysis is severely hampered without comprehensive audit trails across all

CI/CD systems.

• Inability to correlate events across SCM, CI, artifact repositories, and deployment systems

prevents detection of multi-stage attacks.

Vulnerability checklist

• No complete inventory exists of all CI/CD systems, including all instances of self-managed

systems.

• Audit logs are not enabled on all CI/CD systems, or are not enabled to their full extent.
• Applicative logs (pipeline execution, artifact operations, code operations) are not captured.
• Logs from CI/CD systems are not shipped to a centralized location such as a SIEM.
• No alerts exist to detect anomalies or potential malicious activity in CI/CD systems.
• Programmatic access to CI/CD systems is not logged or monitored to the same degree as human

access.

• No correlation rules exist to detect anomalies across the code shipping process involving

multiple systems.

• Log retention periods are insufficient for investigation of incidents discovered with a delay.

Prevention controls

1. Build and maintain a comprehensive inventory of all CI/CD systems in use, including every instance of self-managed systems. 2. Identify and enable all relevant log sources across every CI/CD system, covering both human and programmatic access through all available methods. 3. Enable both audit log sources (user access, user creation, permission changes) and applicative log sources (push events, build executions, artifact operations). 4. Ship all CI/CD logs to a centralized location such as a SIEM to support aggregation and correlation across systems. 5. Create alerts to detect anomalies and potential malicious activity within each system as well as across the code shipping process spanning multiple systems. 6. Ensure log retention periods are sufficient for post-incident investigation requirements. 7. Monitor programmatic access with the same rigor as human access.

Example attack scenarios

Scenario A — Undetected credential exfiltration

An attacker compromises a CI pipeline through a poisoned dependency and exfiltrates credentials stored as environment variables. Because no logging exists for outbound network connections from build nodes and pipeline execution events are not shipped to a centralized monitoring system, the credential theft goes undetected. The attacker uses the stolen credentials for months, laterally moving across production environments, before the breach is discovered through an unrelated investigation.

Scenario B — Delayed incident response due to missing logs

A build server is compromised and used to inject a backdoor into production artifacts. When the compromise is eventually discovered, the incident response team attempts to reconstruct the attack timeline. However, audit logs were not enabled on the CI system, and execution logs were retained for only seven days. The team cannot determine when the compromise began, what credentials were accessed, or which artifacts were affected, leading to a full rebuild of all production infrastructure.

Detection guidance

• Verify that all CI/CD systems have audit and applicative logging enabled and configured.
• Confirm that logs from all CI/CD systems are being shipped to and received by the centralized

SIEM.

• Test alert rules by simulating anomalous activities across CI/CD systems.
• Periodically review log coverage to identify CI/CD systems or event types that are not being

captured.

• Validate that programmatic access events (API calls, token usage, webhook invocations) are

logged.

• Confirm log retention periods meet investigation requirements.

Remediation

• Conduct a comprehensive inventory of all CI/CD systems and instances, identifying gaps in log

coverage.

• Enable all audit and applicative log sources on every CI/CD system.
• Configure log shipping from all CI/CD systems to the centralized SIEM or logging platform.
• Develop and deploy detection rules and alerts for anomalous activity across CI/CD systems,

including multi-system correlation rules.

• Extend log retention periods to meet organizational incident investigation requirements.
• Ensure programmatic access is logged and monitored at parity with human access.
• Conduct periodic log coverage reviews to catch newly-added systems or configuration drifts.