Your pipeline holds production credentials and can deploy without further approval. It is the most privileged system most teams have, and the least protected.
The short answer
CI/CD security means protecting the build and deployment pipeline itself, rather than using it to run security checks on your code. The distinction matters because a pipeline typically holds credentials to production, can push changes without a second approval, and is trusted by every environment it deploys to. Compromise it and every downstream control is bypassed.
Most teams have thought carefully about the first job, and CI/CD security is the second one, which almost nobody reviews.
On this page
Two different CI/CD security questions
| Question | What it means |
|---|---|
| Security in the pipeline | Running SAST, SCA and SBOM generation as build steps, so flaws in the application are caught before release. Covered under application security |
| Security of the pipeline | Treating the build system as production infrastructure and protecting it accordingly. This is CI/CD security, and it is the subject of this page |
A pipeline running every scanner available is still a single point of compromise if anyone who can open a pull request can change what it does.
Why the pipeline is a target
CI/CD security starts from an uncomfortable inventory of what the build system can already do.
| Property | What it gives an attacker |
|---|---|
| Holds deployment credentials | Access to production, often through a role broad enough to cover every service the team has ever deployed |
| Deploys without further review | Code that reaches the pipeline is generally assumed to have been approved already, so nothing checks again |
| Trusted by production | Traffic and changes arriving from the build system look expected, because they are |
| Reads every repository | One compromised pipeline frequently exposes source for the whole organisation, not one project |
| Executes untrusted input by design | Its entire job is running code and dependencies that changed since the last run |
| Rarely monitored | Build logs are read when something breaks, not when something succeeds unusually |
The four CI/CD security attack routes
| Route | How it works |
|---|---|
| Malicious dependency | A package or build action is updated to include hostile code. The pipeline pulls the latest version and runs it with full access to whatever the build has |
| Contributor account | A developer credential is stolen, and the attacker submits a change that looks routine. Review catches sloppy attempts, rarely careful ones |
| Pipeline configuration | The build definition lives in the repository, so changing it is a code change. A modified step can exfiltrate every secret the pipeline holds |
| Build runner | A shared or self-hosted runner retains state between jobs, letting one build reach the credentials or artefacts of another |
A change to the pipeline config is a production change
Most review processes scrutinise application code and wave through the build file, on the reasoning that it is only configuration. It is not. A single added step can print every secret into a log, publish an altered artefact, or open a connection outward, and it executes with the pipeline’s full privileges the moment the change merges. Build definitions deserve stricter review than the code they build, not looser, and the people who can approve them should be a named and short list.
The five CI/CD security controls that matter
| Control | What it prevents |
|---|---|
| Short-lived deployment credentials | Removes the standing production key from the build system entirely. Federated identity issuing temporary credentials per run is the single highest-value change available. See secrets management |
| Narrow pipeline permissions | Scoped per project rather than one role that can deploy anything, so a compromised build reaches one service. Enforced through identity and access management |
| Protected branches and required review | Stops a single account merging directly to the branch that deploys, and forces build definition changes through the same gate |
| Pinned dependencies and actions | Referencing an exact version or digest rather than a moving tag, so a compromised upstream release does not enter automatically |
| Ephemeral isolated runners | A fresh environment per job, discarded afterwards, so nothing persists for the next build to find |
None of these require a dedicated CI/CD security product to be purchased. They are configuration decisions, and they are usually free with the platform you already run.
Where Osto fits
Osto does not harden build runners or replace your CI platform, so part of CI/CD security stays with your build provider, and the five controls above are settings you apply where the pipeline lives. What Osto covers is the surrounding surface, which is where the consequences land.
In the pipeline itself, SAST, SCA and SBOM generation address the dependency route, because a component inventory is what lets you answer quickly when a package you rely on is found to be malicious.
Around it, the blast radius is an identity question. Identity and access management keeps the deployment role narrow, privileged access management governs the accounts that can change the pipeline, and cloud posture management flags the over-permissioned deploy role that was created during setup and never revisited. Because build, identity and cloud events all reach one SIEM, a deployment credential used outside a build window or calling operations it never calls is visible as a pattern rather than as a routine authenticated request. That evidence supports the change management and access control expectations in SOC 2, ISO 27001 Annex A and PCI DSS.
Platform walkthrough
Limit what a build can reach
Dependency scanning and SBOM in the pipeline, narrow deployment identity around it, and credential misuse visible in one SIEM.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is CI/CD security?
Protecting the build and deployment pipeline as production infrastructure, covering the credentials it holds, who can change it, what it executes and what it can reach. It is distinct from running security scans inside the pipeline.
Why is the pipeline a high-value target?
It holds deployment credentials, pushes to production without further approval, is trusted by the environments it deploys to, and usually has read access to every repository. Compromising it bypasses controls that sit further downstream.
What is a supply chain attack on a pipeline?
Compromising something the build depends on rather than the build itself, most often a package or a shared build action. The pipeline pulls the newest version automatically and executes it with full build privileges, which is why pinning to an exact version matters.
Should pipeline configuration changes be reviewed?
More strictly than application code. A single added step can export every secret the pipeline holds, and it runs with full privileges as soon as the change merges.
Do you need a dedicated CI/CD security tool?
Usually not. The highest-value controls are configuration: short-lived credentials instead of stored keys, narrow permissions, protected branches, pinned dependencies and disposable runners. All are available in the platforms most teams already use.