With the recent shake-up around CVE funding and broader questions about long-term support for cybersecurity infrastructure, one thing is clear: controlling what you can is more important than ever.
This is abundantly clear in modern software development practices which rely heavily on CI/CD systems, which in turn serve as the primary conduit from a developer’s local environment to production. The adoption of DevOps practices and the proliferation of microservices have greatly diversified the CI/CD landscape:
- Development stacks now span multiple languages, frameworks, and tools, including GitOps and Kubernetes.
- New technologies are adopted faster, often without significant integration hurdles.
- Automation and Infrastructure as Code (IaC) are standard practices.
- Third-party components (whether services or code dependencies) are commonly integrated with minimal effort, sometimes by simply adding a line or two of code.
While these capabilities significantly accelerate and enhance software delivery, they also introduce a broader and more complex attack surface. Threat actors, recognising the strategic importance of CI/CD infrastructure, are increasingly targeting these environments to gain access to critical systems and data.
This blog post is Part 1 in a series diving into the OWASP Top 10 risks for CI/CD systems, based on Cloudsmith’s newly published, free eBook that explores these risks in detail and offers practical guidance for securing your software pipelines.
CICD-SEC-1: Insufficient Flow Control
Definition
This risk involves an attacker exploiting weak or missing safeguards within the CI/CD pipeline (such as in source control, CI servers, or artifact repositories) to push unauthorised or malicious code without triggering any manual checks or secondary validation.
Overview
CI/CD processes are designed for speed and efficiency. Code can be committed and deployed to production in minutes, often with little or no human oversight. Without robust flow control mechanisms, a compromised account or system could push changes that go directly into production unchecked.
Types of Exploitation
- Committing code to a monitored branch that automatically triggers deployment.
- Using manual triggers to deploy unauthorised code.
- Publishing malicious updates to shared libraries used in production.
- Exploiting auto-merge rules to introduce malicious changes.
- Circumventing weak branch protections by using excluded users or branches.
- Uploading manipulated artifacts to repositories where they are automatically consumed by deployment processes.
- Modifying production code or infrastructure directly, such as through a misconfigured AWS Lambda, without audit or approval.
Real World Example: Bypassing required reviews using GitHub Actions
This flaw was exploited by leveraging GitHub Actions to bypass branch protection rules that rely on pull request review requirements. Normally, organisations set up branch protection rules that prevent users from merging code into sensitive branches without at least one approval from another team member. However, GitHub Actions is enabled by default in all repositories, and anyone with Write permissions can configure a workflow.
The attacker, after compromising a user account, could push a malicious workflow along with their code. This workflow, using the default GITHUB_TOKEN with elevated permissions, could automatically approve the pull request via the GitHub API, effectively bypassing the human review process. Because GitHub considered the bot’s approval valid, the code could then be merged without oversight, despite the protection rules in place.
This ties directly back to OWASP CICD-SEC-1, which highlights risks stemming from weak or absent enforcement of process and policy within CI/CD pipelines. In this case, the lack of granular flow control in how GitHub Actions interacts with protected branches allowed a user (or an attacker with access to their account) to subvert established safeguards.
The CI system failed to properly distinguish between trusted, manual reviews and automated approvals, blurring a critical boundary in the pipeline's security model. Ultimately, this allowed attackers to exploit CI behaviour to escalate privileges and execute unauthorised changes in production workflows, showcasing the real-world implications of insufficient control mechanisms in CI/CD environments.
Mitigation Strategies
To reduce the risk of unauthorised changes being pushed through CI/CD pipelines, businesses should establish controls that require multiple layers of validation. Here are several ways to enhance pipeline integrity:
- Enforce Strict Branch Protection Rules: Apply strong protection policies on critical branches. Avoid exempting any user or branch from these rules. Ensure that users who can bypass code review cannot trigger deployment processes.
- Limit and Audit Auto-Merge Rules: Restrict the use of automatic merging and thoroughly validate any such configurations. Avoid using third-party scripts for auto-merge unless they are well-audited and sandboxed.
- Require Multi-Person Approval for Deployments: Implement controls that require a 2nd-party to review or approve builds before they can be promoted to production.
- Artifact Origin Verification: Only allow artifacts produced by trusted, pre-approved CI service accounts to enter the deployment pipeline. Artifacts from unknown or unauthorised sources should require secondary review before use.
- Monitor and Detect Production Drift: Use tooling to continuously detect inconsistencies between production code/infrastructure and its source. Automatically flag or roll back unauthorised changes.
OpenSSF Recommendations
To further strengthen your CI/CD security posture, consider integrating the following OpenSSF (Open Source Security Foundation) projects:
- Sigstore: Helps verify the origin and integrity of artifacts through cryptographic signing. You can ensure that only signed and trusted artifacts progress through your pipeline.
- Scorecard: Evaluates the security posture of your project repositories, including branch protection, CI usage, and dependency update practices.
- SLSA: Supply-chain Levels for Software Artifacts is a security framework designed to improve the integrity of software supply chains. SLSA can help enforce provenance and prevent untrusted code from entering the build or deployment pipeline.
- Allstar: An automated policy enforcement tool for GitHub repositories. It can be used to enforce best practices such as required reviews and branch protections.
Conclusion
By combining policy enforcement, robust configuration, and the adoption of security-focused tools like those offered by OpenSSF, organisations can greatly reduce the likelihood of a single point of compromise leading to full pipeline exploitation. If you like the content here, and would like to know more about the OWASP Top 10 for CI/CD systems, check out our free Cloudsmith eBook - download link here.
