CI/CD pipelines connect to many of an organization’s most sensitive assets, including source code, credentials, build systems, artifact registries, and production environments. That access makes automated delivery possible, but it also makes the pipeline a valuable target for attackers.
CI/CD security is the practice of protecting software delivery pipelines while embedding automated security checks throughout the build and deployment process. It has two interconnected components: protecting the pipeline itself and applying shift-left security by scanning the code and dependencies that move through it.
According to the 2026 Sembi Software Quality Pulse Report, just 9% of security teams report having fully integrated DevOps toolchains. Security gates can help close that integration gap by turning security policies into enforceable decisions within the delivery workflow.
This article explores common CI/CD risks, explains where security checks belong in the pipeline, and outlines how to implement risk-based security gates.
CI/CD security includes the policies, controls, processes, and tools used to protect continuous integration, continuous delivery, and continuous deployment workflows.
The exact controls depend on how a team delivers software:
The OWASP CI/CD Security Cheat Sheet distinguishes continuous delivery from continuous deployment based on whether the final production release is manually initiated or automated.
Effective CI/CD security addresses two related areas: pipeline protection and application security.
Pipeline protection secures the infrastructure and workflows that make CI/CD possible, including:
Application security evaluates the code and components moving through the pipeline.
Depending on the application, this may include:
Security gates connect scan results and pipeline policy. A gate evaluates predefined criteria and determines whether a change can proceed, requires approval, generates a warning, or must be blocked.
However, not every pipeline protection can be reduced to one go/no-go gate. Identity management, runner isolation, credential protection, secure configuration, and monitoring require their own controls.
CI/CD systems combine broad access with trusted automation. If a pipeline is compromised, an attacker may be able to alter source code, steal credentials, publish a malicious artifact under a legitimate name, or deploy unauthorized changes.
OWASP identifies inadequate identity and access management, dependency-chain abuse, poisoned pipeline execution, insufficient credential hygiene, improper artifact-integrity validation, and insufficient logging among the most significant CI/CD security risks.
Pipelines often accumulate overly broad service-account permissions, long-lived access tokens, and credentials that remain active after they are no longer needed. Secrets may also be hardcoded in repositories, pipeline configuration files, build scripts, container images, or logs.
Production credentials should not be available to untrusted pull-request or feature-branch builds. If untrusted code can access those credentials, an attacker may be able to exfiltrate them simply by modifying the build.
Reduce credential risk by:
Attackers may target pipeline definitions, build scripts, self-hosted runners, or third-party workflow components. Malicious code submitted through a pull request may also exploit a pipeline that executes untrusted changes with privileged credentials.
Teams can reduce this risk by:
Applications rely on direct and transitive third-party components. Those components may contain known vulnerabilities, become compromised, or create license-policy concerns.
Attackers can also exploit dependency-resolution behavior through techniques such as:
Use software composition analysis (SCA) to identify direct and transitive dependencies, known vulnerabilities, available fixes, and license obligations. Teams should also pin dependencies where appropriate, enforce lockfiles, validate package integrity, and restrict package managers to approved registries.
SCA identifies known component risk, but it does not replace controls that protect the package-resolution and build process itself.
SCA analyzes third-party and open-source components; it does not identify every vulnerability in code written by your team.
Static application security testing (SAST) analyzes proprietary source code for insecure patterns and data flows associated with issues such as injection, cross-site scripting, insecure cryptography, improper input handling, and unsafe API use. Dedicated secrets-detection tools should also be used to identify exposed tokens, passwords, and keys.
Human-written and AI-generated code require the same security controls. The Sembi Software Quality Pulse Report found that respondents estimate an average of 53% of their organizations’ code has been touched by AI. As AI-assisted development increases code volume and velocity, automated security analysis becomes more important—not less.
A successful pipeline run does not automatically prove that the deployed artifact is the one the pipeline produced.
Checksums, signatures, attestations, and provenance records can help teams verify that an artifact has not been replaced or modified between build and deployment. Frameworks such as Supply-chain Levels for Software Artifacts (SLSA) provide guidance for improving software artifact integrity and build provenance.
Integrity controls should address:
Artifact signing is valuable, but signing alone does not prove that an artifact is secure. The signing keys, build system, and approval process must also be protected.
Security teams need to know which code was scanned, which policies it passed, who approved an exception, and which artifact was deployed.
Without that information, incident response and compliance investigations become difficult. Centralized logs and approval histories should capture relevant repository, pipeline, scan, artifact, and deployment events without recording secrets or unnecessary sensitive data.
A security gate is an automated or approval-based control that determines whether a change can move to the next stage of the pipeline.
A gate may evaluate:
A security check and a security gate are related but different. A security check identifies a potential issue. A security gate applies policy to that result and takes action.
Depending on the risk and the organization’s policy, a gate might:
Blocking every release that contains any finding can create unnecessary disruption and encourage teams to bypass controls. A risk-based prioritization approach focuses gates on risks the organization has already defined as unacceptable.
For example, a gate might block a change that introduces:
A medium-severity finding might be allowed to proceed if it is assigned an owner and remediation deadline. The correct response depends on exploitability, application exposure, affected data, available mitigations, and the organization’s risk tolerance—not severity alone.
CI/CD security is an ongoing program rather than a one-time configuration task. The following steps help teams introduce controls without creating an unmanageable number of alerts or blocking every release.
Before configuring security tools, document the current delivery workflow.
Include:
Identify where untrusted input enters the workflow, where credentials become available, where privileges increase, and where artifacts cross system boundaries.
This process often exposes hidden build steps, shared service accounts, unnecessary integrations, or untrusted jobs running on privileged infrastructure.
Do not allow a scanner’s default settings to become the organization’s security policy.
Define:
Tools should enforce documented policy rather than define it.
Mature and legacy applications may already contain a backlog of findings. Blocking every release until the entire backlog is resolved is often impractical and can discourage adoption. Establish an approved baseline of known findings, then consider blocking newly introduced risks that exceed the organization’s threshold. Assign ownership for the existing backlog and reduce it according to a documented vulnerability remediation plan.
A baseline should not become a permanent exemption. Review it regularly, especially when an existing issue becomes more exploitable or affects a newly exposed part of the application.
SAST can provide feedback during active development and within the pipeline.
A layered scanning approach may include:
When evaluating a SAST tool, consider:
Pattern-based rules can identify useful issues, while deeper data-flow analysis may be needed for vulnerabilities that cross files, methods, and framework boundaries. Evaluate both coverage and accuracy using representative code.
Use SCA to identify direct and transitive dependencies, known vulnerabilities, component age, available fixed versions, and license obligations.
Build-time scanning is important, but component risk can change after release when a new vulnerability is disclosed. Continuous monitoring can notify teams when an existing dependency becomes newly vulnerable.
SCA can also support SBOM generation and analysis. An SBOM documents the components identified in a particular application or build, but it does not automatically prove which version is currently running in every production environment. Connect SBOM data to release, deployment, and runtime inventory records where that distinction matters.
Application security scanning does not protect the pipeline by itself.
Pipeline controls should include:
SAST and SCA cannot replace identity and access management, secrets management, runner hardening, artifact signing, DAST, or cloud infrastructure security.
Treat artifacts as security-sensitive outputs.
Depending on the delivery model, controls may include:
Avoid rebuilding separately for each environment when doing so breaks the evidence chain between the tested artifact and the deployed one.
Legitimate exceptions will occur, even with carefully tuned gates.
When a gate blocks a build, the failure message should explain:
Exceptions should be documented, assigned, time-bound, and auditable. Otherwise, temporary approvals can quietly become permanent policy bypasses.
Use this checklist when designing a pipeline, introducing new security gates, or reviewing existing controls.
Kiuwan supports the application-security side of CI/CD security by analyzing proprietary code and open-source dependencies and providing findings that teams can incorporate into automated workflows and security gates.
However, Kiuwan does not replace identity and access management, secrets management, runner hardening, artifact signing, DAST, or cloud infrastructure security. Those remain separate requirements for protecting the pipeline itself.
Kiuwan Code Security provides SAST for proprietary source code and supports more than 30 modern and legacy programming languages.
Teams can use Kiuwan Code Security to:
Kiuwan documents integrations with Jenkins and Azure DevOps, GitLab CI analysis through the Local Analyzer, and command-line use with other CI/CD platforms. Its product page also states that quality gates can fail builds when high-severity vulnerabilities appear.
Kiuwan Local Analyzer processes source code within the organization’s infrastructure. Teams should confirm where findings and metadata will be stored based on their selected deployment configuration and data-residency requirements.
Compliance mappings and reports can support audit preparation, but using Kiuwan does not itself guarantee compliance or audit approval.
Kiuwan Insights provides SCA for third-party and open-source components.
It can help teams:
Kiuwan Insights supports component and license analysis, but teams should confirm the exact enforcement options available for license and dependency policies in their chosen CI/CD integration.
Kiuwan Code Security findings can feed pipeline decisions through built-in quality gates and SARIF exports.
For example, teams can configure workflows that:
Kiuwan identifies and prioritizes potential issues; developers still need to review findings and remediate the underlying code or dependency risk.
CI/CD security requires both protection for the delivery pipeline and automated analysis of the code and components moving through it.
Effective teams define unacceptable risk clearly, integrate appropriate security checks, and use gates to enforce policy without treating every finding as equally urgent. They also protect credentials, runners, pipeline configuration, artifacts, and deployment permissions independently of application scans.
Kiuwan helps teams add SAST and SCA to development workflows so proprietary code, open-source dependencies, license obligations, and security findings can be evaluated before release.
Start a free 14-day Kiuwan trial to evaluate Kiuwan within your existing development and CI/CD workflows.
CI/CD security combines protection for pipeline infrastructure—including identities, credentials, runners, configurations, artifacts, and deployment workflows—with security testing for the code and dependencies moving through the pipeline.
Many pipelines should include SAST for proprietary code, SCA for third-party dependencies, and secrets detection. Container scanning, infrastructure-as-code scanning, DAST, API security testing, and other checks may also be appropriate depending on the application and deployment model.
The required scans should be based on the organization’s architecture and risk—not a universal checklist alone.
SAST analyzes proprietary application code for insecure patterns and data flows. SCA analyzes third-party and open-source components for known vulnerabilities, license obligations, and related dependency risks.
SAST and SCA address different parts of application risk and are typically used together.
A security check identifies potential risk. A security gate evaluates the check’s result against policy and determines what happens next, such as blocking the build, issuing a warning, creating a ticket, or requiring approval.
Poorly configured gates can slow development by blocking on low-risk or inaccurate findings. Risk-based gates focus on clearly unacceptable conditions and give developers actionable feedback.
Track gate failure rates, false positives, exception volume, and remediation time to determine whether the policy is protecting releases without creating unnecessary friction.
Not necessarily. For applications with an existing backlog, teams may begin by establishing a documented baseline and blocking newly introduced vulnerabilities above a defined threshold.
The existing backlog should still have assigned owners, remediation targets, and periodic review.
An SBOM documents the components associated with a particular application or build. It does not automatically confirm what is running in every production environment. Connect SBOM records to artifact, release, deployment, and runtime inventory data when production verification is required.
