CI Platform Usage Share 2026: Survey Data and Pipeline Security

In JetBrains' State of CI/CD 2026 survey of 598 respondents, 47% of organizations use GitHub Actions, 32% use GitLab CI and 28% use Jenkins, followed by Azure DevOps Server at 15%, TeamCity at 10%, AWS CodePipeline or CodeBuild at 7% and Bitbucket Pipelines at 6%. The answers are multi select, so most organizations run more than one CI system, and that is the real security finding: pipeline controls have to work across several platforms at once.

Below: what each dataset measures, where they disagree, how CI follows code hosting, what each platform documents for pipeline security, and a minimum control set for mixed CI.

Key takeaways

• Newest organizational data: JetBrains State of CI/CD 2026 (598 respondents, 576 using a CI/CD tool) puts GitHub Actions at 47%, GitLab CI 32%, Jenkins 28%, Azure DevOps Server 15%, TeamCity 10%, Bitbucket Pipelines 6%.
• Shares sum to well over 100% because the question is multi select. Controls that exist on only one CI system leave gaps.
• 2025 and 2026 do not line up cleanly. The 2026 page prints its own 2025 column (GitHub Actions 41%, GitLab CI 34%, Jenkins 31%), which differs from figures attributed to JetBrains' October 2025 blog, and JetBrains says its two 2026 datasets put Jenkins at 28% and 37%.
• Stack Overflow does not ask about CI. Its 2025 collaboration tools question gives GitHub 81.1%, GitLab 35.6%, Azure DevOps 16.6%. The 2026 results are out (30,903 responses) but carry no CI or code hosting question on the technology page.
• Every hosted CI platform documents OIDC, with different issuers, subjects and lifetimes, so trust policies do not port.
• Every platform has a way to pin reusable steps, but only the GitHub and GitLab docs we read recommend commit SHA pinning explicitly.

How we measured

There is no census of CI usage. Every number in this post comes from one of four kinds of source, and each counts something different.

Why these numbers cannot be added or averaged:

1. Different units. JetBrains' tools survey counts organizations; its Developer Ecosystem Survey and Stack Overflow count individuals; Octoverse counts events on one platform.
2. Different questions. Stack Overflow asks about collaboration and code documentation tools, which captures where code is hosted, not where builds run. A developer using GitHub for code and Jenkins for builds is a GitHub user to Stack Overflow and a Jenkins user to JetBrains.
3. Different recruitment. JetBrains recruits through developer blogs, newsletters, social media and community lists, weights results, and says they describe "engaged developers", not the whole industry. JetBrains also publishes TeamCity, which appears in its own chart.
4. Multi select. Percentages sum to more than 100%, so they are not market shares in the revenue sense.
5. Different years. Where we show change over time, both numbers come from the same publisher's page.

Platform security features in this post come only from each platform's own documentation, fetched on 23 October 2026. We describe what the docs say, not how well each platform implements it, and we do not rank platforms.

What CI usage shares do JetBrains 2025 and 2026 report?

JetBrains' State of CI/CD 2026 page gives the most recent organizational picture. The chart below is titled "The most popular CI/CD tools in organizations in 2026" and comes from the CI/CD Tools Adoption Survey (598 respondents, 576 using at least one tool). The page prints a 2025 column next to each 2026 figure.

Ranked table: CI tools by organizational usage share, 2026

The ranking is by the 2026 percentage and nothing else. It says how many respondents' organizations use a tool, not how many pipelines, builds or repositories run on it, and not which tool is more secure.

Details that matter when quoting it:

• "Azure DevOps Server" is the chart's label. The page does not say whether users of the hosted Azure Pipelines service chose it.
• Buildkite, Travis CI, Bitrise, CloudBees CI, Harness CI/CD and Semaphore CI show 0% for 2025 because they had no 2025 option, and the page prints no 2026 values for them. CircleCI does not appear in the list as fetched; absence is not a usage figure.
• The AWS line is not growth. The option was renamed between years.

Personal versus organizational use

The 2026 page carries the heading "GitHub is popular both for personal use and in organizations" but prints no personal use chart. Figures attributed to JetBrains' October 2025 State of CI/CD blog post give personal use of GitHub Actions 39%, Jenkins 13%, GitLab CI 10%, and organizational use of 33%, 28% and 19%, with 18% using no CI. That page returned HTTP 403 when we tried to fetch it on 23 October 2026, so those numbers are unconfirmed and we use them only to explain the disagreement below.

Why do the 2025 and 2026 numbers differ so much?

There are two sets of 2025 numbers for the same tools: the 2025 column printed on the 2026 page (GitHub Actions 41%, GitLab CI 34%, Jenkins 31%) and the unconfirmed figures attributed to the October 2025 blog (33%, 19%, 28% organizational). We cannot reconcile them from the published pages, but the 2026 page explains most of the mechanism:

1. Two surveys with different units. JetBrains ran a tools survey about organizations and a Developer Ecosystem Survey about individuals. The page says "the share of developers using Jenkins was 28% in one and 37% in the other, and TeamCity's share shifted from 9% to 4%", attributes this to unit and recruitment, and does not say which survey gave which number. Its chart shows TeamCity at 10%, which matches neither.
2. Different bases. A share of all respondents, including people with no CI, is lower than a share of CI users. The 2025 blog figures reportedly included an 18% "no CI" group; the 2026 page gives 598 respondents with 576 using a tool.
3. Changed answer options. The AWS option was renamed and six tools were added. When options change, picks redistribute.
4. Changed AI questions. JetBrains says its AI adoption question changed between years. The CI question is separate, but a survey reshaped around AI can attract different respondents.
5. Sample size. At 598 respondents, one percentage point is about six people.

Quote the 2026 chart as "47% of organizations in JetBrains' 2026 CI/CD tools survey (n=598)", use the 2025 column printed beside it for trend, and do not mix in the 2025 blog figures.

How strongly does CI choice follow SCM choice?

None of the sources we fetched measures the link directly. The JetBrains 2026 page does not cross tabulate CI tool against code hosting platform, and Stack Overflow does not ask about CI at all. What we can show is how tightly each CI product is coupled to a source code host by design, and that the order of the survey numbers is similar when you put the two kinds of data side by side.

Coupling by design

GitHub Actions, GitLab CI and Bitbucket Pipelines are built into a code host, so choosing the SCM very nearly chooses the CI system. Azure Pipelines, Jenkins, CircleCI and TeamCity are not tied to one host.

The two datasets side by side, not combined

These columns count different things (individuals using a collaboration tool versus organizations running a CI tool) in different years and samples. Do not subtract them or compute an "attach rate". The safe reading is qualitative: the order is the same in both lists, which fits the coupling above, and independent CI systems such as Jenkins, Azure Pipelines and CircleCI build a share of the code that lives on GitHub.

For security, this means the identity that runs a build is often issued by a different system from the one that holds the code. A Jenkins job building a GitHub repository uses Jenkins credentials, and SCM branch protection does not stop it building an unprotected branch unless someone wires that rule into the job.

What does Stack Overflow 2025 add, and what about 2026?

Stack Overflow's 2025 technology section asks: "Which collaborative work management and/or code documentation tools did you use regularly over the past year, and which do you want to work with over the next year? Select all that apply". The figures we fetched for the "used regularly" half:

Source: Stack Overflow Developer Survey 2025, technology section, 30,065 respondents to this question (61.3% of all respondents), 23,683 professional developers. Bitbucket, Jenkins, GitHub Actions and CircleCI did not appear in the portion of the page we could read, so we do not quote figures for them.

What this adds: professional developers report Azure DevOps far more often than learners (18.6% versus 4.1%), which fits Azure Pipelines being an organizational choice, and GitHub use among learners is 88.8%, so new engineers tend to arrive knowing its workflow syntax. It says nothing about builds; a developer who answers "GitHub" may never touch a workflow file.

On 23 October 2026 the Stack Overflow 2026 results were live: 30,903 responses from 169 countries, 103 questions and 467 technologies. The 2026 technology page covers languages, databases, LLM providers, build types and AI use, with no collaboration tools, code hosting or CI question, so there is no 2026 Stack Overflow figure to set beside 2025.

What does GitHub's own data say about volume?

Usage share tells you how many organizations touch a tool. Volume tells you how much runs through it. GitHub is the only CI platform in this set that publishes volume at this scale in a way we could fetch.

The minute counts cover public projects, so they say nothing about private enterprise workloads. The gap between 11.5 billion and 13.5 billion is self hosted runner time under the same rubric, the kind of runner GitHub's hardening guide warns about for public repositories. A secondary claim that Bitbucket Pipelines runs over one billion build minutes a month could not be confirmed from an Atlassian page, so we do not use it.

For context, the CNCF annual cloud native survey (published 20 January 2026) reports that 82% of container users run Kubernetes in production. It tells you where pipelines deploy, not which CI system runs them.

What OIDC, secret handling and runner isolation does each CI platform document?

Every hosted CI platform in this post documents a way to issue a short lived OpenID Connect token to a job, so the job can exchange it for cloud credentials instead of storing a long lived key. The details differ in ways that break copy and paste trust policies.

OIDC tokens by platform, from each platform's docs

The practical consequences:

• Trust policies are not portable. A role that trusts repo:org/app:ref:refs/heads/main from GitHub says nothing about a GitLab job whose subject starts with project_path:. See the GitHub OIDC immutable subject migration post.
• Lifetimes differ. GitLab defaults to the job timeout or 5 minutes; CircleCI uses one hour. Our post on how long a CI OIDC token is valid on GitHub and GitLab explains why that matters if a token leaks.
• Check the branch claim. A trust policy that checks only the repository lets any branch assume the role. Use ref_protected on GitLab, ref or environment on GitHub.

Secret handling by platform

Runner and agent isolation by platform

A self hosted runner that accepts work from untrusted branches is where a CI compromise becomes a network compromise, and each platform that documents such runners documents a way to restrict which jobs reach them.

How are third party actions, orbs, pipes and templates pinned on each platform?

Reusable pipeline steps are dependencies that run with the job's secrets and tokens.

Three points stand out:

1. Immutability is not uniform. CircleCI says production orb versions are immutable; GitHub warns tags can be moved; GitLab ranks a SHA above a tag; Bitbucket documents versions but not immutability. An exact version is a strong pin only if the registry refuses overwrites.
2. Pinning and update tooling interact. Dependabot alerts cover semver referenced actions, not SHA pinned ones, so SHA pins need another way to stay current.
3. Azure puts the control on the resource. Approvals and checks are not defined in YAML, so a pipeline author cannot remove them. A Required template check on a service connection enforces "every deploying pipeline uses our vetted template".

Where do SBOM and provenance get generated in each CI platform?

"Not documented in the pages we fetched" describes our sources, not proof of absence. Use native SBOM or provenance features where they exist, and also run one tool that behaves the same everywhere so evidence is comparable across the estate.

What is the minimum control set for mixed CI?

With most organizations running more than one CI system, a control that exists only on the primary platform is a partial control. This set uses documented features plus steps you can run anywhere.

The last row is the one most teams skip. If GitHub repositories are scanned by one tool with one severity threshold and Jenkins builds by another, the same vulnerable package can fail a build in one place and ship from the other.

Step by step: apply the minimum control set

The commands below are standard platform syntax. Replace placeholders with your own values.

1. Inventory which CI systems you actually run

Search your repositories for each platform's configuration file. Run this from a directory that contains your cloned repositories:

# Count repositories per CI system by config file
for f in .github/workflows .gitlab-ci.yml azure-pipelines.yml bitbucket-pipelines.yml .circleci/config.yml Jenkinsfile; do
  printf '%-26s %s\n' "$f" "$(find . -maxdepth 3 -path "*/$f" 2>/dev/null | wc -l)"
done

On GitHub, list repositories that have workflows with the gh CLI:

gh repo list YOUR_ORG --limit 1000 --json name -q '.[].name' | while read r; do
  gh api "repos/YOUR_ORG/$r/contents/.github/workflows" --silent 2>/dev/null && echo "$r"
done

2. Find unpinned reusable steps

GitHub Actions references that are not a 40 character SHA:

grep -rhoE 'uses:\s*[^ ]+@[^ ]+' .github/workflows \
  | grep -vE '@[0-9a-f]{40}' | sort | uniq -c | sort -rn

GitLab components that float:

grep -nE 'component:.*@(~latest|[0-9]+(\.[0-9]+)?$|main$)' .gitlab-ci.yml

CircleCI orbs on volatile or a partial version:

grep -nE '@(volatile|[0-9]+(\.[0-9]+)?)$' .circleci/config.yml

Bitbucket pipes, to review their versions:

grep -n 'pipe:' bitbucket-pipelines.yml

3. Pin and restrict a GitHub Actions workflow

# .github/workflows/build.yml
permissions:
  contents: read            # default read only, raise per job

jobs:
  build:
    runs-on: ubuntu-latest  # hosted runner for anything that builds pull requests
    permissions:
      contents: read
      id-token: write       # OIDC for cloud access and attestations
      attestations: write
    steps:
      - uses: actions/checkout@<full-40-char-sha>   # v4, pinned by SHA
      - run: make build
      - uses: actions/attest-build-provenance@<full-40-char-sha>  # v1
        with:
          subject-path: dist/app.tar.gz

Verify the attestation from any machine with the GitHub CLI:

gh attestation verify dist/app.tar.gz -o YOUR_ORG

4. Pin components and request an ID token in GitLab CI

# .gitlab-ci.yml
variables:
  RUNNER_GENERATE_ARTIFACTS_METADATA: "true"   # SLSA provenance next to artifacts

include:
  - component: $CI_SERVER_FQDN/my-org/security-components/scan@e3262fdd0914fa823210cdb79a8c421e2cef79d8

deploy:
  stage: deploy
  id_tokens:
    CLOUD_ID_TOKEN:
      aud: https://sts.example.com
  script:
    - ./deploy.sh "$CLOUD_ID_TOKEN"
  rules:
    - if: $CI_COMMIT_REF_PROTECTED == "true"
  tags: [protected-deploy]   # runs only on a protected, tagged runner

On the cloud side, write the trust condition against the sub claim and ref_protected, not just the project path.

5. Enable OIDC and pin pipes in Bitbucket Pipelines

# bitbucket-pipelines.yml
pipelines:
  branches:
    main:
      - step:
          name: Deploy
          deployment: production
          oidc: true
          script:
            # Exact version you have reviewed (example version from Atlassian's docs).
            # Swap the static keys for the pipe's OIDC variables per its README.
            - pipe: atlassian/aws-s3-deploy:0.2.2
              variables:
                AWS_DEFAULT_REGION: 'us-east-1'
                S3_BUCKET: 'my-bucket-name'
                LOCAL_PATH: 'build'

The step's token is in $BITBUCKET_STEP_OIDC_TOKEN. Check the pipe's README for the variable names it accepts for OIDC.

6. Force a vetted template in Azure Pipelines

# azure-pipelines.yml
resources:
  repositories:
    - repository: templates
      type: git
      name: Platform/pipeline-templates
      ref: refs/tags/v3.2.0

extends:
  template: secure-build.yml@templates
  parameters:
    serviceConnection: prod-wif   # workload identity federation connection

Then, on the prod-wif service connection in Project settings > Service connections > Approvals and checks, add a Required template check pointing at secure-build.yml on that ref, and a Branch control check that allows only refs/heads/main. Because checks live on the resource, a pipeline author cannot remove them by editing YAML.

7. Pin orbs and use OIDC in CircleCI

# .circleci/config.yml
version: 2.1
orbs:
  aws-cli: circleci/aws-cli@X.Y.Z   # replace with the exact x.y.z you reviewed; never volatile

jobs:
  deploy:
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - run: echo "Exchange \$CIRCLE_OIDC_TOKEN_V2 for cloud credentials here"

Write the cloud trust policy against the V2 sub, which includes vcs-origin and vcs-ref, so a token from a different repository or branch is refused.

8. Isolate the Jenkins controller

In Manage Jenkins > Nodes and Clouds > Built-In Node > Configure, set the number of executors to 0 and save, after you have agents or a cloud configured. On Jenkins 2.325 or earlier, confirm Agent to Controller Access Control is enabled under Manage Jenkins > Security; from 2.326 it is always on.

9. Run the same scan and policy on every platform

Add one scan step to every pipeline, whatever the platform, with the same severity threshold. With the Safeguard CLI (installation steps are in the CLI docs), the scan itself is one line:

safeguard scan --dir .            # source repository and its dependencies
safeguard scan --image my-app:ci  # the image this pipeline just built

Results land as JSON under ./output; keep them as a build artifact so evidence looks the same on every CI platform.

Where do the datasets disagree?

None of these changes the broad picture: in JetBrains' 2026 data the three highest organizational shares are GitHub Actions, GitLab CI and Jenkins, and most organizations run more than one CI system. They do change what you can responsibly quote precisely.

Where Safeguard fits, and where it does not

Safeguard is not a CI platform and does not replace any of the controls above. It helps with the "same scanner and policy everywhere" row and with acting on what the scan finds.

• Scanning in any pipeline. The Safeguard CLI scans a directory, a container image or an SBOM file (safeguard scan --dir ., --image, --sbom), and safeguard exec is built for CI use. That lets a GitHub Actions job and a Jenkins job produce comparable results.
• Policies and gates in one place. Policies are evaluated in the platform, so the threshold that fails a build is the same across CI systems.
• Knowing where a component lives. The platform shows which projects contain a given component and version, which matters when the same library is built by three different CI systems.
• Fix pull requests in the SCM. Autonomous remediation opens fix pull requests in the connected repository. It ships switched off. See how to connect GitHub, GitLab, Azure DevOps or Bitbucket.

Where it does not help: Safeguard does not configure OIDC trust policies, runner isolation, branch protection or Azure checks for you, and it does not replace the platform's own secret storage. Those stay with each CI platform's settings and your cloud provider.

Common mistakes

Mistakes in reading the data

1. Calling a usage percentage a market share. "47% of organizations use GitHub Actions" is not "47% of the CI market"; answers are multi select and n=598.
2. Mixing the two 2025 baselines. Setting the 2026 chart against the October 2025 blog figures creates a growth story that may be an artefact of base and wording.
3. Treating Stack Overflow's GitHub figure as CI usage. 81.1% used GitHub as a collaboration tool, not GitHub Actions.
4. Ignoring who ran the survey. JetBrains publishes TeamCity and recruits through its own channels; read its TeamCity figure with care, as its own 9% versus 4% note shows.
5. Reading absence as zero. CircleCI's absence and the 0% values for new options are artefacts of the answer list.

Mistakes in acting on it

6. Securing only the primary CI system. Controls on GitHub Actions do not cover the Jenkins server next to it.
7. Copying OIDC trust policies between platforms. Subject formats differ (repo:, project_path:, org/.../project/...). A wildcard that matches too much fails open.
8. Checking repository but not branch in a trust policy, so any branch can assume the role.
9. Pinning to tags and calling it done. GitHub's guide says tags can be moved or deleted if a repository is compromised.
10. Pinning to SHAs with no update path. Dependabot alerts do not cover SHA pinned actions.
11. Different scan thresholds per platform, so a dependency blocked in one pipeline ships from another.

FAQ

What is the most used CI/CD tool in 2026?

In JetBrains' State of CI/CD 2026 survey (598 respondents), GitHub Actions has the largest organizational usage share at 47%, followed by GitLab CI at 32% and Jenkins at 28%. These are shares of respondents' organizations, multi select, not shares of builds or revenue.

Does the Stack Overflow Developer Survey ask about CI/CD tools?

Not in the sections we fetched. The 2025 survey asks about collaborative work management and code documentation tools (GitHub, GitLab, Azure DevOps, Jira). The 2026 results were live on 23 October 2026 with 30,903 responses, and the technology page we checked does not include a CI or code hosting question.

Why do CI survey percentages add up to more than 100%?

Because respondents can pick every tool their organization uses. Many organizations run two or more CI systems, for example GitHub Actions for new services and Jenkins for older ones.

Which CI platforms support OIDC for cloud deployments?

Per their own docs: GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Azure Pipelines (workload identity federation) and CircleCI. The Jenkins pages we fetched do not document a built in OIDC issuer.

How should I pin GitHub Actions safely?

GitHub's hardening guide says to pin actions to a full length commit SHA and to verify the SHA comes from the action's own repository rather than a fork. Note that Dependabot alerts do not cover SHA pinned actions, so plan another way to keep them current.

How do GitHub Actions and GitLab CI security features compare?

Both document OIDC tokens, pinning by commit SHA, runner restrictions and build provenance, with different syntax and claims. The data does not support ranking them; outcomes depend on how a team configures trust policies, runners and tokens.

What are GitHub artifact attestations?

Signed records, built on Sigstore, that link an artifact to the GitHub Actions workflow run that built it. They became generally available on 25 June 2024. You generate them with actions/attest-build-provenance and verify with gh attestation verify.

Does GitLab CI generate SLSA provenance?

GitLab Runner writes an in-toto statement with an SLSA 1.0 provenance predicate next to each artifact when RUNNER_GENERATE_ARTIFACTS_METADATA is set to "true", according to GitLab's runner configuration docs.

Fix it without waiting for upstream

Pipeline controls decide what can run in CI. They do not fix the vulnerable dependency the pipeline just built. The same gaps apply whichever CI platform runs the build.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To try the CLI on your own machine before adding it to a pipeline, download it from safeguard.sh/download and follow the CLI docs.

This demo is a real CLI session. It installs the CLI, opens the interactive terminal, and asks it to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. It ends with /permissions, /model and /scan ., the same scan you would run as a step in GitHub Actions, GitLab CI, Azure Pipelines or Jenkins.

Click through it at your own pace, or open it full screen.

This demo sets up the runner on your own machine, approves it with a device code, and then scans from the terminal. It is the closest match to a self hosted CI agent: the scan runs on hardware you control, which matters if your Jenkins agents or self hosted runners sit inside a private network.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. For a team running several CI systems, it is a way to ask one question, such as which projects contain a given package version, and get one answer regardless of which pipeline built them.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• JetBrains: The State of CI/CD in 2026
• Stack Overflow Developer Survey 2025: Technology
• Stack Overflow Developer Survey 2026
• Stack Overflow Developer Survey 2026: Technology
• GitHub Octoverse 2025: A new developer joins GitHub every second
• CNCF: The CNCF annual cloud native survey
• GitHub Docs: Security hardening for GitHub Actions
• GitHub Docs: About security hardening with OpenID Connect
• GitHub Changelog: Artifact attestations is generally available (25 June 2024)
• GitHub Docs: Exporting a software bill of materials for your repository
• GitLab Docs: OpenID Connect (OIDC) authentication using ID tokens
• GitLab Docs: CI/CD components
• GitLab Docs: Configuring runners
• GitLab Docs: Dependency list
• Atlassian: Integrate Pipelines with resource servers using OIDC
• Atlassian: What are pipes?
• Atlassian: Variables and secrets
• Microsoft Learn: Use an Azure Resource Manager service connection
• Microsoft Learn: Secure your Azure Pipelines
• Microsoft Learn: Pipeline deployment approvals and checks
• CircleCI Docs: OpenID Connect tokens
• CircleCI Docs: Orb concepts
• Jenkins: Controller isolation

Last reviewed: 23 October 2026. Survey figures change when publishers revise their pages; check the linked sources for the latest values.