A team adopts a security scanner. It runs in CI, it finds things, and a year later nobody can say whether it ran on the commit that shipped last Tuesday. The tool was never the problem. The pipeline either enforces a control on every change or it does not, and that property is what separates a security programme from a collection of scanners.
More on CI/CD security
What CI/CD security covers
CI/CD security is the practice of enforcing security controls inside the delivery pipeline so that every change is checked automatically. It is narrower than application security, which also covers design review, dynamic testing against running systems, and the production runtime. It is wider than scanning, because a control that runs but is not recorded cannot be shown to anyone later.
The distinguishing property is enforcement on every commit. A check that runs when somebody remembers is a habit, not a control. A check that runs on every change, blocks when it fails, and leaves a dated record is a control, and it is the only kind that survives contact with an auditor or an incident review.
Controls a pipeline enforces on every commit
Several security controls fit naturally inside a pipeline because the pipeline already has what they need: the source, the dependency graph, the build output, and a trigger on every change. Static analysis, dependency scanning, secret scanning, container image scanning, and pinning third-party units to immutable references are among them. Each runs unattended and produces a dated result.
Static analysis reads the source for patterns that indicate a vulnerability: injection paths, unsafe deserialisation, weak cryptographic calls. It runs without executing the code, which is why it fits a pipeline stage and why it cannot see anything that only appears at runtime.
Dependency scanning compares the resolved dependency graph against known vulnerability data. The value is entirely in the freshness of the data and the completeness of the graph, which is why lockfiles matter more here than anywhere else.
Secret scanning looks for credentials committed to source. It is the cheapest control to add and the one with the shortest window of usefulness: once a key reaches a remote it should be treated as burned regardless of what the scan says afterwards.
Container image scanning inspects the built image for vulnerable operating system packages and libraries. It only applies where the pipeline produces an image, which is why a meaningful share of repositories have no finding to report rather than a passing one.
Pinning is the odd one out. It is not a scanner. It is a property of how the pipeline references the third-party units it executes, and it is the control that most directly determines whether somebody else can change what your pipeline runs without telling you.
This is not a closed list. Artefact signing, software bill of materials generation, least-privilege scoping of build tokens, and protection of the trunk against history rewrites are all pipeline-enforceable and all matter. Dynamic testing and infrastructure-as-code scanning sit alongside a pipeline rather than inside it. Anyone offering a definitive count of pipeline security controls is describing their own product, not the field.
How common the gaps actually are
Published research suggests the gaps are widespread even among well-maintained projects. A 2026 scan of 50,012 of the most-starred repositories on GitHub found that 19,005 of them, roughly two in five, referenced at least one third-party action by a mutable tag rather than an immutable commit SHA. Unpinned references accounted for 74.5% of all the CI/CD findings in that sample.
Two cautions on that figure. The 74.5% is a share of findings rather than of repositories, because one repository with many unpinned references produces many findings, so it is not a statement about how many teams are affected. And most-starred public repositories are a biased sample: they skew towards large, actively maintained projects. Private estates are unmeasured and there is no particular reason to assume they are better.
Why we are not quoting our own data
We audit pipelines for a living, so the obvious move would be to publish what we see across the estates we monitor. We have deliberately not done that. Our current sample is dominated by a single tenant, which makes it evidence about who adopts a pipeline audit tool early rather than evidence about the industry. A prevalence claim drawn from it would be confident-sounding and wrong.
Published research from people with a representative sample is the honest source for a question like this. Our contribution is below: what the controls mean on each provider, which is something we can speak to directly because the detection has to handle all six.
The same control on six providers
Nearly all published CI/CD security guidance is written for GitHub Actions. That matters because the controls do not translate cleanly. The same instruction can be straightforward on one provider, differently shaped on another, and impossible on a third, and a team on a mixed estate discovers this only when applying the advice.
Scanning controls translate reasonably well. Static analysis, dependency scanning and secret scanning are just steps that run a tool, so the question on any provider is whether the step exists, whether it runs on every change rather than on a schedule, and whether its output is kept. The vocabulary differs and the substance does not.
Pinning is where the translation breaks, because it depends on how each provider models reuse. GitHub Actions references actions by git ref, so an immutable reference is a 40-character commit SHA and anything shorter is mutable. GitLab CI pulls in reusable units through its include mechanism, where components and cross-project includes take a ref that can be pinned the same way. CircleCI uses orbs, which are versioned packages rather than git references. There is no commit SHA to pin to. The strongest available reference is a full three-part version; shorter forms resolve to the newest matching release and can move under you.
So the near-universal advice to pin everything to a SHA is not merely harder on CircleCI. It cannot be followed, and a team that treats it as a checklist item will record a gap that has no fix. The correct target there is the strongest reference the provider offers, which is a different control with a different residual risk, and worth saying out loud rather than scoring as a failure.
Pinning the ref you control, and the ones you do not
Pinning matters because a tag or branch is a pointer that somebody else owns. When a workflow references an action by tag, the owner of that action can repoint the tag at different code, and the next pipeline run executes it with whatever access the job has. In March 2025 this happened to a widely used action, whose tags were repointed at code that wrote CI secrets into build logs. Pipelines referencing a commit SHA were unaffected, because a SHA cannot be repointed.
The limit of pinning is less widely understood. Pinning fixes which code runs, not what that code fetches while running. A pinned action can still pull a container image on a floating tag, call a nested action by version tag, or install packages without a lockfile. Palo Alto Networks found in 2023 that 32% of the top 1,000 Marketplace actions were unpinnable in exactly this way, so pinning them closes the outer door and leaves an inner one open.
That percentage is from 2023 and may well have moved. The structural point does not age: a reference can only be as immutable as the things it pulls. Treat pinning as removing the largest and most easily exploited path rather than as closing the category, and prefer actions whose own dependencies are pinned when there is a choice.
The platforms have started to respond. GitHub added organisation policy in August 2025 that can require actions to be pinned, which moves the control from convention to enforcement, and its roadmap includes locking transitive workflow dependencies the way a lockfile does for packages. Until that lands, the transitive layer stays a reading exercise.
DevSecOps and CI/CD security
DevSecOps names an operating model: security responsibility distributed across delivery teams instead of concentrated in a review at the end. CI/CD security is narrower and more concrete: the specific automated controls that run inside a pipeline and the evidence they leave behind. The first is an organisational choice and the second is a property of a repository.
The distinction is worth keeping because the two fail independently. A team can run every control described above without ever using the word DevSecOps, and an organisation can restructure around the label while its pipelines enforce nothing. Arguing about the terminology is less useful than asking which controls run on every commit, and what happens when one of them fails.
Making controls stick without slowing delivery
Shift left, as an instruction, says to move security checks earlier in the delivery process. The idea is sound and the failure mode is consistent: teams add scanners to the pipeline before deciding what happens when one fails. The result is a pipeline that reports hundreds of findings nobody triages, and a team that learns to scroll past a red security stage.
The ordering that works is the reverse of the one most tools encourage. Decide the policy first: which severities block a merge, who owns a finding when it appears, and what the documented path is for accepting a risk deliberately. Then turn on the scanner. A control without an owner produces a backlog; a control with an owner produces fixes.
This is the same pattern that governs pipeline reliability. Detection is cheap and abundant, and it only becomes useful once somebody is accountable for acting on what it finds. The stability equivalent is a flaky-test list nobody works through.
The sequence that works starts with the cheapest control and the clearest policy, then widens. Secret scanning first, because the cost of a missed credential is unbounded and the check is fast enough to run before a commit leaves a developer machine. Pinning second, because it is a configuration change rather than a remediation programme and it closes the most directly exploitable path.
Dependency scanning third, with the severity threshold agreed before the scanner is switched on rather than after the first hundred findings arrive. Static analysis fourth, because it produces the most output and needs the most triage discipline to stay useful. Container scanning where images are actually built, and not configured as a universal requirement that reports not-applicable everywhere else.
Two rules make the difference between this sticking and becoming another ignored red stage. Every control needs a named owner on the day it is enabled, and every control needs a written path for accepting a finding deliberately. Without the first, findings accumulate. Without the second, people route around the gate, and a gate that gets bypassed evidences nothing.
Where CI/CD Watch fits
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, audits pipeline configuration and run history and reports which controls are present, which are missing, and which do not apply. The per-provider translation described above is not a framing device: the detection has to encode it, because a rule that assumes GitHub semantics produces false findings everywhere else.
Findings arrive structured and dated, which is what makes them usable as evidence later rather than as a snapshot of today. Security insights sit on the Business plan and above; see pricing for what each tier includes.
The platform reports the gap. Deciding whether a finding is worth fixing, accepting, or is simply not applicable to how a given repository ships is a judgement that stays with the team that owns the code. We surface signals for humans to act on rather than claiming to secure a pipeline on their behalf.
FAQ
Common questions
- What is CI/CD security?
- CI/CD security is the practice of enforcing security controls inside the delivery pipeline, so that every commit is checked automatically rather than reviewed by hand before a release. The controls a pipeline can enforce and evidence on its own include static analysis, dependency scanning, secret scanning, container image scanning, and pinning third-party units to immutable references. Other parts of an application security programme, such as dynamic testing against a running system or infrastructure-as-code scanning, sit alongside these rather than inside the same set.
- Is CI/CD security the same as DevSecOps?
- They overlap but they are not interchangeable. DevSecOps names an operating model: security responsibility distributed across delivery teams rather than concentrated in a gate at the end. CI/CD security is narrower and more concrete: the specific automated controls that run in a pipeline and the evidence they produce. A team can have the controls without adopting the label, and plenty of organisations have adopted the label without the controls.
- Does pinning an action to a commit SHA make it safe?
- It makes the reference immutable, which is necessary but not sufficient. Pinning fixes which code the action runs, not what that code fetches at runtime. An action pinned to a SHA can still pull a Docker image on a floating tag, call a nested action by version tag, or install packages without a lockfile. Palo Alto Networks found in 2023 that 32% of the top 1,000 Marketplace actions were unpinnable in this way, meaning pinning them does not fully close the path.
- Can you pin CircleCI orbs to a SHA?
- No. CircleCI orbs are versioned packages rather than git references, so there is no commit SHA to pin to. The strongest available reference is a full three-part version such as 5.1.2. Shorter forms are mutable: 5 and 5.0 resolve to the newest matching release, and volatile and dev tags can be republished at any time. This is the clearest case where advice written for GitHub Actions cannot be followed as written on another provider.
- Which security controls can a pipeline actually prove to an auditor?
- The ones that run as gates and leave a dated record. A scan that runs on every commit and exports its findings produces evidence; a scan that runs when someone remembers does not. The distinction matters because most compliance frameworks ask for evidence that a control operated, not confirmation that a tool was purchased. Mapping pipeline activity to specific control identifiers is covered on the CI/CD compliance page.
- Where should security controls run, pre-commit or in CI?
- Both, for different reasons. Fast checks such as secret scanning and linting belong in a pre-commit hook because catching a leaked credential before it reaches a remote is far cheaper than revoking it afterwards. The same checks must also run in CI, because a hook on a developer machine can be skipped and therefore cannot be evidence. Pre-commit is for speed of feedback; CI is for enforcement and for the record.
Read on
Proving these controls operated, rather than merely existing, is a related and separate discipline. Mapping pipeline activity to specific control identifiers is covered on CI/CD compliance, with the standard-specific cut for ISO 27001 Annex A and the record shape an auditor accepts in building an audit trail.
For how the platform detects each control, including the per-provider handling, see the security insights docs.