Modern software development runs through automated pipelines: code is merged, built, tested and rolled out to target environments, often several times a day. This automation is an enormous gain in productivity, but it changes the threat landscape. The pipeline has access to source code and credentials, often also to production environments. An attacker who compromises it no longer has to crack a single application: they have your own automation conveniently deliver their malicious code. CI/CD security therefore puts the software supply chain at the centre.
What is CI/CD security?
CI/CD security encompasses all measures that protect the integrity of the automated build and delivery chain: from the source code repository through build servers and artefact registries to the target environment. The goal can be summed up in one sentence: only vetted code, built in a traceable way, reaches production. This includes technical controls such as access restrictions and signatures, as well as organisational rules, such as mandatory reviews for changes to pipeline definitions. The term overlaps with software supply chain security, but focuses on the part of the supply chain that you operate yourself. The tools themselves are also part of the chain: an outdated build server is just as real a risk as a vulnerable dependency in the code.
How it works
Effective protection starts at several points in the chain at once:
- Minimise access: Every pipeline receives only the rights it needs for its purpose. Short-lived, automatically rotated tokens replace static credentials, and changes to protected branches require a review.
- Manage secrets centrally: Credentials reside in a secret store and are surfaced only at runtime. Secret scanning prevents keys from ending up in the source code and finds legacy items in the history.
- Control dependencies: Software composition analysis checks integrated packages for known vulnerabilities. Lockfiles and curated internal registries make attacks such as dependency confusion or typosquatting harder.
- Sign artefacts: Every build produces an immutable, signed artefact together with proof of provenance. Before deployment, the signature is checked: what demonstrably comes from your own pipeline may be rolled out, everything else is discarded.
- Harden the build environment: Runners run isolated and short-lived, ideally created fresh per job. Network segmentation and controlled egress prevent a compromised build job from leaking data or accessing production.
- Log and alert: Audit logs record who changes pipelines and who triggers deployments. Unusual patterns, such as builds at atypical times, trigger a review.
Why it matters
- The pipeline is a master key: it is allowed to bring code into production. That is precisely why it is more valuable to attackers than individual servers.
- Supply chain attacks scale: if a build process is compromised, the malicious code reaches all recipients of the software at the same time, potentially including your customers.
- Secrets are a preferred gateway: leaked tokens in repositories or build logs are among the common causes of real incidents and are easy for attackers to find in an automated way.
- Regulation is catching up: rules such as NIS2 and DORA demand control over the software supply chain. Signed artefacts and complete build logs provide the required evidence.
- Trust becomes verifiable: customers and partners increasingly ask how your software comes about. A secured pipeline makes the answer demonstrable.
Typical scenarios
The classic case is the leaked token: an access key accidentally ends up in a public repository and opens the way to internal systems. Just as common is the compromised open-source package: a dependency changes owner and, in its next version, ships malicious code that the pipeline builds in unchecked. In environments that have grown over time, there is also often a central build server with permanent full access to all environments, an ideal springboard for attackers. And at the latest during an audit, the question arises whether it can be proven completely, for a production artefact, which code and which build it originates from. All four cases have the same root: the pipeline was regarded as a tool but never treated as a system worth protecting.
CI and CD: drawing the line
CI stands for continuous integration: code changes are merged continuously and checked automatically through builds and tests. Depending on the reading, CD stands for continuous delivery, in which states that can be delivered at any time are produced, or for continuous deployment, in which every successful change goes into production automatically. For security, the distinction is relevant because the attack surfaces differ. In the CI phase, risks around code and dependencies dominate, such as manipulated packages or insecure build scripts. In the CD phase, it is about the path into production, that is, deployment access and the integrity of the rolled-out artefacts. Those who look at the two phases separately recognise more quickly which control is missing where.
How KAEMI helps
Many of the controls in CI/CD security are, at their core, network controls. KAEMI segments build environments with microsegmentation , so that build systems and production environments communicate only via explicitly permitted connections. A compromised build job thereby stays locally confined instead of becoming the starting point for lateral movement. In addition, Application Security protects the applications and APIs that your pipeline delivers, in ongoing operation. As a managed service provider, KAEMI takes over the set-up and operation of these controls and adapts the rule sets when your development processes change. Via Contact , you can reach our team for a review of your build infrastructure.