What is CI/CD?

What is CI/CD?

CI/CD is the automated path code follows from a developer's commit to running software. With continuous integration (CI), developers fold their work into the main code line many times a day, and every merge kicks off an automatic build plus a test suite, so a breaking change shows up within minutes. The CD half can mean either of two things. Continuous delivery keeps every passing build ready to ship, and a person chooses when it goes live. Continuous deployment goes one step further: with no human release decision, anything that clears every stage ships to production on its own. The SY0-801 acronym list expands CI/CD as continuous integration and continuous deployment.

How a pipeline runs

A pipeline is defined in a file stored with the code and executed by a CI server or hosted service on runners, short-lived machines that do the work. A typical run checks out the code, builds it, runs unit tests and security scans, packages the result as an artifact such as a container image, signs it, and deploys it to a test environment and then to production. Any stage that fails stops the stages after it. A summary of one failed run:

The flawed change never reaches staging, and the developer hears about it while the code is still fresh.

Security gates in the pipeline

When releases happen many times a day, security checks have to run automatically inside the pipeline rather than as a review before a quarterly release. Common gates are secrets scanning, static application security testing (SAST), dependency scanning that also produces a software bill of materials (SBOM), infrastructure-as-code scanning, container image scanning and dynamic testing (DAST) against a staging deployment. After the gates pass, the pipeline signs the artifact so the deployment system can refuse anything unsigned or altered.

Protecting the pipeline itself

A pipeline holds credentials for source control, registries and production, and everything it builds is trusted downstream, which makes it a prime target. In the SolarWinds compromise discovered in 2020, attackers tampered with the build process so that trojanized Orion updates went out signed with the company's legitimate certificate; the signature proved where the build came from, not that it was clean. In 2021, a tampered upload script from the code-coverage vendor Codecov sent environment variables, including credentials, from customers' CI jobs to the attackers. The controls follow from cases like these:

• Branch protection that blocks direct pushes and demands a second reviewer and passing checks before any merge.
• Scoped, short-lived credentials for each job instead of long-lived keys stored as pipeline secrets.
• Third-party build steps and plugins pinned to a specific commit hash.
• Isolated, throwaway runners, plus audit logs for every change to pipeline definitions.

CI/CD vs. DevSecOps and shift left

CI/CD is the machinery. DevSecOps is the practice of making security a shared part of development and operations, and shifting left means moving security checks earlier in the process. The pipeline is where both become concrete: each scan in it is a shift-left control that runs on every change.

CI/CD on the CompTIA Security+ exam

CI/CD is new on the SY0-801 acronym list, and pipelines are part of the automation and orchestration material in objective 4.6. Look for CI/CD when a question wants flaws caught automatically each time code is committed or before it can be released. When delivery and deployment are contrasted, ask whether a human signs off on the release (delivery) or not (deployment). If a plugin or build step was hijacked and leaked secrets, the fix is tighter pipeline permissions, expiring credentials and dependencies pinned to known versions; another scanner wouldn't have helped. Distractors include a manual code review before each release and a penetration test, both of which run too late and too rarely to gate every change.