CI/CD

What Is CI/CD?

CI/CD (Continuous Integration and Continuous Delivery, or Continuous Deployment) is a software development practice that automates how code changes are built, tested, and released. Instead of developers manually integrating and deploying code in large, infrequent batches, CI/CD uses automated pipelines to merge changes continuously, run tests automatically, and push validated code toward production faster and more reliably.

CI/CD has become a foundational practice in modern software delivery because it reduces the manual, error-prone work of integrating and releasing code, shortens the time between writing a change and getting it in front of users, and creates a repeatable, auditable process that teams can trust. This page breaks down what CI and CD each mean, how a typical pipeline works, the tools commonly used at each stage, and — because pipelines have become a meaningful attack surface in their own right — what CI/CD security involves and how teams approach it.

Continuous Integration (CI)

Continuous Integration is the practice of merging code changes from multiple developers into a shared repository frequently — often several times a day — rather than waiting days or weeks between merges. Each time code is merged, an automated process builds the application and runs a suite of tests to catch integration problems, bugs, or regressions as early as possible.

The core value of CI is speed of feedback. Because changes are small and tested immediately, developers find out within minutes whether a change broke something, rather than discovering a conflict weeks later when it is harder to trace and more expensive to fix. Common CI tools include Jenkins, GitHub Actions, and CircleCI, each of which can be configured to automatically build, test, and validate code on every commit or pull request. Many teams also run static application security testing (SAST) and software composition analysis (SCA) at this stage, scanning source code and open-source dependencies for known vulnerabilities before a change moves any further down the pipeline.

Continuous Delivery and Continuous Deployment (CD)

Continuous Delivery picks up where Continuous Integration leaves off. Once code has been built and tested, CD automates the process of preparing that code for release — packaging it, running additional checks against production-like environments, and confirming it is ready to ship. With Continuous Delivery, a human still approves the final push to production; with Continuous Deployment, that last step is automated as well, so validated changes go live without manual sign-off.

At this stage, teams typically run tests focused on production readiness: performance under load, compatibility with the target environment, and whether the change will scale as expected. Tools commonly used to manage delivery and deployment include ArgoCD and Spinnaker, which help automate releases across environments in a consistent, repeatable way. It is also common practice to run container and dependency scans at deploy time, checking the final build artifact for known vulnerabilities one more time before it reaches production.

How a CI/CD Pipeline Fits Together

A CI/CD pipeline is the automated sequence that carries a code change from a developer’s commit to a live release. While every organization configures its pipeline differently, most follow a similar shape:

Source — a developer commits code to a shared repository.
Build — the application is compiled or packaged into a runnable artifact.
Test — automated tests (unit, integration, and often security scans) run against the build.
Deliver — the validated artifact is prepared for release, sometimes with a manual approval gate.
Deploy — the release is pushed to staging or production environments, automatically or on approval.
Monitor — the running application is observed for errors, performance issues, or new vulnerabilities.

Each stage can be supported by different categories of tooling: source control platforms, build automation servers, test runners, artifact repositories, deployment orchestrators, and monitoring systems. Together, these tools form the pipeline infrastructure that lets teams ship changes frequently without sacrificing quality or consistency.

CI/CD Security

CI/CD pipelines move code and credentials through many connected systems — source control, build servers, artifact registries, and deployment targets — which makes them an attractive target for attackers. CI/CD security refers to the practices and controls used to protect that pipeline itself, not just the application it produces. A compromised pipeline can let an attacker inject malicious code, steal credentials, or ship a tampered artifact to production without ever attacking the application directly.

Common risks in CI/CD pipelines include:

Exposed secrets — API keys, credentials, or tokens stored insecurely in code, configuration files, or build logs.
Over-privileged access — build systems or service accounts with broader permissions than they need, widening the blast radius of a compromise.
Unsigned or tampered artifacts — build outputs that aren’t verified for integrity before deployment, allowing tampering to go undetected.
Vulnerable open-source dependencies — third-party libraries and packages with known vulnerabilities pulled into a build.
Software supply chain compromise — attacks that target upstream dependencies, build tools, or CI/CD infrastructure rather than the application’s own code.

CI/CD Security Best Practices

Most CI/CD security guidance centers on a consistent set of practices that reduce the pipeline’s attack surface and make it easier to detect problems early:

Apply least-privilege access to pipeline systems, so build agents, service accounts, and integrations only have the permissions they need.
Use secrets management and vaulting rather than hard-coding credentials in source code or pipeline configuration.
Integrate SCA and SAST tools (such as OWASP Dependency-Check, Snyk, or GitHub Dependabot) directly into the pipeline to catch known vulnerabilities in code and dependencies before deployment.
Require signed commits and signed artifacts so that changes and build outputs can be verified as authentic and untampered.
Generate a software bill of materials (SBOM) for each build to maintain visibility into every component that ships in an application.
Use immutable build environments that are re-created for each run, reducing the risk of a persistent compromise in build infrastructure.
Maintain continuous vulnerability monitoring after deployment, since new vulnerabilities are disclosed constantly and code that was clean at build time may not stay that way.

It’s worth noting that most CI/CD security tooling — SCA, SAST, and dependency scanners — evaluates code and dependencies before deployment, based on what’s present in a build rather than what actually runs. That pre-deployment view is valuable, but it doesn’t capture how an application behaves once it’s live. Runtime detection tools complement pre-deployment scanning by observing what actually executes in production. For example, Azul Vulnerability Detection identifies exploitable, class-level vulnerabilities in running Java applications, giving teams visibility into which known vulnerabilities are actually reachable in a live environment — information that can help prioritize remediation alongside the findings already surfaced earlier in the CI/CD pipeline. This class-level, in-production approach can identify exploitable vulnerabilities with up to 1,000 times greater accuracy than traditional application security (AppSec) and application performance monitoring (APM) tools (Azul, June 2025), by focusing on code paths that are actually loaded and executed rather than every dependency present in a build.

Benefits of CI/CD

Organizations adopt CI/CD for a mix of speed, quality, and operational reasons. Common benefits include:

Faster feedback — developers learn within minutes whether a change works, rather than waiting days.
Fewer integration problems — frequent, small merges are easier to test and troubleshoot than large, infrequent ones.
More consistent releases — automated, repeatable pipelines reduce the variability and manual error that come with manual deployment processes.
Shorter time to production — validated changes can reach users faster, supporting more frequent releases.
Reduced security and compliance risk — consistent, auditable pipelines with built-in scanning and approval gates make it easier to demonstrate control over what gets shipped and when.

Frequently Asked Questions

What is CI/CD?

CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). It is a set of practices that automates building, testing, and releasing software, allowing teams to ship code changes more frequently and reliably than manual processes allow.

What is CI/CD security?

CI/CD security is the practice of protecting the CI/CD pipeline itself — including source code repositories, build systems, artifact registries, and deployment infrastructure — from compromise, in addition to securing the application code that passes through it.

What are CI/CD security best practices?

Common best practices include least-privilege access, secrets management, integrating SCA and SAST scanning into the pipeline, signing commits and artifacts, generating an SBOM for each build, using immutable build environments, and continuously monitoring applications for vulnerabilities after deployment.

Is CI/CD secure by default?

No. A CI/CD pipeline automates delivery, but it does not automatically secure itself. Pipelines introduce their own risks — exposed secrets, over-privileged access, and vulnerable dependencies, among others — that need to be addressed deliberately through the practices described above.

What’s the difference between Continuous Delivery and Continuous Deployment?

Continuous Delivery automates everything up to production but leaves a manual approval step before a release goes live. Continuous Deployment goes one step further and automates that final release step as well, so every change that passes testing is deployed automatically.

CI/CD pipelines are the delivery mechanism most DevSecOps practices run inside. Readers new to this space may also want to review Azul’s glossary entry on DevSecOps for how security fits into the pipeline described here, as well as related terms covering software supply chain security and container security.

How Azul Can Help

Azul also supports the pipeline’s build inputs directly. Azul Core provides 100% open-source builds of OpenJDK, verified against the Technology Compatibility Kit (TCK), with a documented quarterly and monthly patch cadence and out-of-cycle zero-day fixes, so teams pulling a JDK into their CI/CD pipeline know exactly what they’re building with and how quickly it gets patched.