CICD-SEC-7 in the OWASP Top 10 CI/CD Security Risks is insecure system configuration: weak security settings, missing patches and poor hardening in the systems that make up a pipeline, such as source control, build servers and artifact repositories. Fix it by inventorying each system, patching, tightening access and reviewing settings on a schedule.
What does OWASP say the risk is?
The CICD-SEC-7 entry defines it as flaws in the security settings, configuration and hardening of the systems across the pipeline, which often give attackers "low hanging fruit" to expand their foothold. It points out that CI/CD environments combine systems from many vendors, each with settings at the application, network and infrastructure level, and that default configurations are often not secure.
Its examples of hardening flaws include a self-managed system with an outdated version or missing patches, overly permissive network access controls, a self-hosted system with administrative permissions on the underlying operating system, insecure configuration of authorization, access and logging, and weak credential hygiene such as default credentials left enabled and overly permissive tokens.
The entry also says that using SaaS pipeline tools removes some hardening and lateral movement risk, but each SaaS product still has its own settings that must be configured securely.
Why do attackers care?
A flaw in one pipeline system may give access to it, or to the operating system underneath. From there, an attacker can alter legitimate pipeline flows, take tokens and reach production. OWASP lists real cases among its references, including the compromise of the SolarWinds build system, a backdoor pushed to the PHP git repository after a probable compromise of its self-maintained server, an internet-accessible TeamCity build server at Stack Overflow, and an unpatched Webmin build server. Read the linked sources on that page for details.
The common thread is that the build system was treated as internal plumbing, and it was reachable or under-maintained.
What are the typical weak spots?
- Build servers reachable from the internet, with a login page and an old version.
- Runners with administrative rights on the host, shared across projects.
- Engineers with debug access to execution nodes. OWASP warns that anyone who can debug a node may expose all secrets while they are loaded in memory and use the node's identity.
- Artifact repositories with anonymous write or broad service tokens.
- Source control organizations that allow unreviewed pushes to main, or apps with excess scopes.
- Audit logging turned off, or not retained.
A constructed example
A team self-hosts a build server. It is three minor versions behind, listens on the public internet, and runs jobs as a user with sudo rights on the host. Developers have debug access to the runners to troubleshoot flaky tests. The team's inventory spreadsheet does not list the server, because a contractor set it up.
After a review the team puts the server behind identity-aware access, upgrades it, runs jobs in ephemeral containers without host privileges, replaces standing debug access with a logged break-glass process, and assigns an owner who checks release notes monthly.
How to check or apply this
- List every pipeline system, its version, where it runs and its owner. Include SaaS tools and contractor-built ones.
- Check each against vendor advisories continuously. Patch, or if no patch exists, restrict access or remove the component.
- Limit network access to the least required. Keep management interfaces off the public internet.
- Run build jobs on ephemeral, unprivileged runners. Do not give them host admin rights.
- Remove standing debug access to execution nodes. Use time-limited, logged access.
- Remove default credentials, and replace broad tokens with scoped, short-lived ones.
- Turn on audit logging for source control, CI and artifact systems and retain it.
- Review every system's security settings at set intervals, and compare against vendor hardening guidance.
- Enforce branch protection and required reviews in source control.
Where do policies fit?
Pipeline settings drift, so checks should be repeatable. Safeguard policies and gates can enforce rules on pull requests and builds, such as blocking merges that fail security conditions. They complement, and do not replace, hardening the systems themselves.
Quick check
Does using a SaaS CI service remove this risk?
It removes part of it, such as patching servers. You still own settings like access, tokens, runner configuration and logging.
What is the first thing to do?
Build the inventory with owners. You cannot patch or restrict a system nobody knows exists.
Sources
- OWASP Top 10 CI/CD Security Risks, CICD-SEC-7 Insecure System Configuration
- NIST SP 800-218, Secure Software Development Framework
- SLSA
Last reviewed: 18 October 2026.
