Insecure System Configuration
OWASP Top 10 CI/CD Security Risks · CICD-SEC-7
The CI/CD platform is itself production infrastructure holding credentials for everything, yet it is often configured with convenience in mind and patched on a slower schedule than the systems it deploys to. Self-hosted instances, runners, and orchestrators carry the usual hardening burden, and permissive defaults in the platform's own settings can undermine every control layered on top.
How it shows up in the real world
- An unpatched self-hosted CI server or plugin with a known remote code execution vulnerability.
- A CI web interface or runner management port exposed to the internet.
- Overly permissive default settings allowing any user to create or modify pipelines and read secrets.
- Runners executing with excessive host privileges, or with a container socket mounted.
How to mitigate it
- Treat CI/CD as production: patch the platform, plugins, and runner images on a defined schedule.
- Restrict network exposure of management interfaces and require strong authentication with single sign-on.
- Harden platform defaults so pipeline creation, secret access, and settings changes require explicit authorisation.
- Run runners unprivileged and isolated, without host socket access, and manage configuration as code with policy checks.
Practice this topic
Test your knowledge of Insecure System Configuration with exam-style practice questions.
Rest of the CI/CD v1.0 list
CICD-SEC-1Insufficient Flow Control Mechanisms
Flow control is what stops a single change from reaching production unreviewed. Where those controls are missing or bypassable, anyone with commit access — or anyone who obtains it — can push code straight through to deployment. The problem is usually not the absence of a review process but the existence of paths around it: unprotected branches, direct registry pushes, or the ability to trigger a deployment without an approved artifact.
CICD-SEC-2Inadequate Identity and Access Management
CI/CD environments accumulate identities: human accounts, service accounts, bot users, integration tokens, and third-party app installations, spread across source control, build systems, registries, and cloud providers. They are rarely reviewed, frequently over-permissioned, and often outlive the person or project that created them, so the effective access of the whole system is far larger than anyone's model of it.
CICD-SEC-3Dependency Chain Abuse
Builds fetch dependencies automatically, and the resolution process itself can be manipulated. If a build can be induced to fetch a package the attacker controls — by claiming an internal name on a public registry, by taking over an abandoned package, or by registering a plausible misspelling — the attacker gets code execution inside the build with the build's credentials.
CICD-SEC-4Poisoned Pipeline Execution (PPE)
Pipelines execute configuration and scripts that live in the repository, which means influencing the repository can mean executing code in the build. Where a pipeline runs against untrusted contributions — most notably pull requests from forks — an outsider may be able to modify what runs and read the secrets available to that job. Variants differ in whether the pipeline definition itself is modified or a file it invokes is.
CICD-SEC-5Insufficient PBAC (Pipeline-Based Access Controls)
Pipeline jobs run with whatever access their execution environment provides, and that access is frequently far broader than the job needs. A single compromised step therefore reaches credentials, networks, and artifacts belonging to unrelated parts of the system. Shared, long-lived runners make this worse by letting one job leave state, or secrets, behind for the next.
CICD-SEC-6Insufficient Credential Hygiene
CI/CD systems handle a large volume of secrets, and those secrets have a strong tendency to spread — into repositories, build logs, container image layers, environment variables, and artifact metadata. Long-lived static credentials are the core problem: they are copied between places, they outlast their purpose, and a single exposure remains exploitable until someone notices and rotates it.
CICD-SEC-8Ungoverned Usage of 3rd Party Services
Modern pipelines integrate readily with external services — marketplace actions, code-quality tools, bots, and reusable workflows — and those integrations are typically granted broad, standing access to source and build environments. Because they can usually be added by any developer without security review, the set of third parties with write access to production code drifts well beyond what anyone has approved.
CICD-SEC-9Improper Artifact Integrity Validation
Between a reviewed commit and a running workload, an artifact passes through build, storage, promotion, and deployment. If nothing verifies at each handoff that the artifact is the one the pipeline produced from that commit, an attacker who can write to any intermediate store can substitute their own and have it deployed through the legitimate process, with no code change visible in review.
CICD-SEC-10Insufficient Logging and Visibility
Attacks on delivery infrastructure look like ordinary engineering activity, so distinguishing them depends almost entirely on telemetry. CI/CD logging is often thin, scattered across several tools, short-lived, and not forwarded anywhere that performs detection. That combination means a pipeline compromise can proceed without alarm and, afterwards, without enough evidence to establish what was built and shipped.