Home / Knowledge hub / CI/CD
Knowledge hub
CI/CD
The pipeline that builds, tests and ships code on every merge.
What it means
CI/CD is the pipeline that builds, tests and ships your code automatically whenever a developer merges a change. Continuous integration covers the building and testing. Continuous delivery covers the shipping.
For most teams it is the only place every change reliably passes through, which makes it the most useful checkpoint you own.
The pipeline also holds things worth protecting in their own right: deploy keys, signing credentials, and access to production.
Why it matters
A security check belongs here because it runs on every change instead of once a year. A finding that arrives while the author still remembers writing the code is cheap to fix. The same finding three months later has to be learned again by somebody who has moved on.
It changes who the report is for as well. An annual report goes to a manager. A pipeline finding goes to the person who wrote the line, which is where the fix has to happen anyway.
When checks run on every change, you can also tell an old problem from one that arrived last Tuesday. The second is far easier to fix, because you know what changed.
How it shows up
The mistake is gating on everything at once. A pipeline that fails a build for every informational finding gets switched off within a fortnight, usually by whoever was most enthusiastic about it.
Start by failing only on new issues at high and critical severity, and report the rest without blocking. Cyberlop can fail a build when something serious is new. See how it runs.
Questions people ask
CI/CD, answered
What is the difference between continuous integration, delivery and deployment?
Continuous integration builds and tests every change as it merges. Continuous delivery keeps each successful build ready to release. Continuous deployment goes one step further and releases it automatically.
Most teams run the first two and decide deliberately whether they want the third.
Which security findings should actually fail a build?
Start with new issues at high and critical severity, and nothing else. Report the rest without blocking.
A pipeline that fails on informational findings gets switched off, and then you have no checks at all. Widen the gate later, once the team trusts what it tells them.
How do I keep production credentials out of my pipeline logs?
Store them as pipeline secrets rather than in the repository, scope each one as narrowly as the job allows, and rotate on a schedule. Assume anything a build step echoes ends up in a log somebody can read.
OWASP's CI/CD guidance treats the pipeline as a target in its own right, because whoever can change it can change what ships.
Is it risky to run CI on pull requests from forks?
Yes, if those builds get your secrets. A fork can propose a change to the pipeline file itself, so a pipeline that runs untrusted code with production credentials hands them over.
Run fork builds without secrets, and make a human approve anything privileged.
Do we need a pipeline if we only ship every few weeks?
Some teams genuinely work without one, usually in regulated or embedded work where a release is a formal event. It is rarer than it used to be.
Release frequency is not really the point. The pipeline is the one place every change passes through, and that is worth having even at monthly releases.
Related
Terms that sit next to this one
Gating a build
Stopping a release automatically when a security check fails.
Shift left
Doing security work while code is written, not as a check at the end.
SAST
Tools that read your source code without ever running it.
Regression
A bug that was fixed and has come back, usually undone by a later change.
Severity
How bad a finding is, from critical down to informational.
Should this build have failed?
We run on each change rather than once a year, and can fail a build when something serious is new. Findings carry the request, the response and the line. Ask how it fits your pipeline.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.