---
title: 'CICD-SEC-7: Insecure System Configuration'
description: OWASP CI/CD Top 10 reference for insecure system configuration vulnerabilities including unpatched CI/CD infrastructure and debug exposure
---

# 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.
