Who this is for

Developers and platform engineers who need to understand how Aikido integrates into a CI/CD pipeline. Specifically: how PR-time scanning works, how findings route to the right team, how ephemeral runners and fork safety are handled, and how the pattern changes across GitHub Actions, GitLab CI, Azure Pipelines, and Bitbucket Pipes.

The CI/CD pattern at a high level

Aikido's CI/CD integration has four components that work together:

1. PR gating runs scanners on every pull request and blocks or warns based on rules you configure

2. AutoTriage filters false positives before findings reach developers, using reachability analysis plus reasoning-model context

3. CODEOWNERS routing assigns findings to the team that owns the affected code

4. AutoFix generates reviewable pull requests that address vulnerabilities

You do not need to run Aikido as a CI step that consumes your runner minutes. The default pattern is dashboard-managed scanning triggered by VCS webhooks, with optional CLI-based scanning when you need to run Aikido inside your pipeline for custom control.

Dashboard-managed gating vs runner-local scanning

Scanning mode	When to prefer	Tradeoff
Dashboard-managed (default)	Standard PR gating, no custom CI integration required	Scan happens in Aikido's infrastructure, no runner minutes consumed
Runner-local via CLI	You need Aikido to block a build step in your existing pipeline, or you want to scan before code reaches the VCS	Consumes runner minutes; you manage CLI installation and secrets

Most teams use dashboard-managed gating. Runner-local CLI scanning is typically used by platform teams with specific pipeline-integration requirements. See the CLI documentation for runner-local setup.

PR and release gating: what runs on every PR

When a PR opens against a branch you've enabled gating on, Aikido runs the scanners you've configured (SAST, SCA, Secrets, IaC, container) against the PR's diff. The results post as a status check on the PR.

Status checks are configured per repository:

• Block on critical findings prevents merge until the finding is resolved or explicitly waived

• Block on new findings blocks only if the PR introduces new findings (pre-existing ones do not block)

• Warn-only posts results without blocking

The PR and Release Gating documentation covers the configuration. Start with warn-only for the first week on a new repository to calibrate, then move to block-on-new-critical.

Auto

Triage: denoising before the queue

AutoTriage runs as part of the PR scan pipeline. From the SAST AutoTriage documentation:

AutoTriage is Aikido's noise-reduction tool that operates downstream of SAST scanners. It reduces noise from static analysis so engineers can focus on issues that are actual security threats.

The flow:

1. Reachability engine verifies vulnerable code paths are actually reachable (function calls traced, sanitization detected between source and sink, unused code paths eliminated)

2. For complex cases where reachability alone cannot rule out exploitability, reasoning models evaluate code context

3. Baseline severity (0 to 100) is adjusted up or down based on the context (e.g., SQL injection from trusted database sources downgraded; NoSQL injection in login endpoints upgraded)

From the documentation: "this approach detects roughly twice as many false positives on those complex cases compared to non-reasoning approaches." The practical effect on a PR is that the status check reports fewer false positives than a raw scanner would.

CODEOWNERS routing: the right team sees the finding

Aikido uses your existing GitHub, GitLab, or Bitbucket CODEOWNERS file to route findings. When a finding lands in a file path owned by @team/backend, the finding is assigned to that team in the Aikido dashboard. The same routing determines who gets notified via Slack, Teams, Jira, Asana, ClickUp, Monday, or YouTrack.

This turns "the security team has a queue of 2,000 findings" into "each engineering team has a queue of their own findings for the code they own." For platform and security leaders, it is the single mechanism that makes findings accountable at scale.

Configure CODEOWNERS in your repository (not in Aikido) using your VCS's standard format.

Auto

Fix: resolving without context-switching

For confirmed vulnerabilities, AutoFix generates a reviewable pull request with the patch. Supported across GitHub, GitLab, Bitbucket, Azure DevOps, and IDE (VSCode). The developer reviews the proposed fix and merges it like any other PR.

Bulk Fix with One Click creates ready-to-merge pull requests that address multiple related alerts at once (e.g., upgrading a single dependency version across a monorepo). See the Product page for the full feature list.

Platform-specific notes

Git

Hub Actions Install the Aikido GitHub App. PR gating runs automatically on pull requests. Status checks appear on the PR with block/warn behavior as configured. No workflow YAML changes required for the default pattern. For runner-local scanning, install the Aikido CLI as a step in your workflow.

Git

Lab CI Connect Aikido to your GitLab instance via OAuth. PR gating runs on merge requests. Status appears as an MR check. Self-hosted GitLab instances are supported on paid plans.

Azure Pipelines

Aikido supports Azure DevOps as a VCS. PR gating integrates with Azure Repos. AutoFix PRs flow through the Azure DevOps PR model.

Bitbucket Pipes

Aikido supports Bitbucket (Cloud). PR gating runs as a PR check. AutoFix opens a Bitbucket pull request with the proposed patch.

Ephemeral runners and fork safety

Two patterns that come up in CI-heavy environments:

Ephemeral runners (Git

Hub, GitLab self-hosted) Dashboard-managed scanning runs in Aikido's infrastructure, so ephemeral runners in your own environment do not need to install or configure Aikido. If you run runner-local CLI scans, the CLI is stateless and installs fresh on each ephemeral runner without persistent configuration.

Fork-originated PRs

Dashboard-managed scanning handles fork PRs by scanning the fork's code against your repository's rules without granting the fork write access. For runner-local CLI scanning, GitHub Actions' default secret-masking for fork PRs applies; follow GitHub's guidance on pull_request_target for workflows that need secrets.

For the specific configuration of either pattern, see the PR and Release Gating documentation.

What this replaces

Before this setup: a security scanner that posts 1,200 findings into a shared queue, a security engineer triaging them one by one, and developers ignoring the scanner because most of what it reports is not real. The replacement: a PR-time check that blocks only real critical findings, a per-team queue with accountable ownership, and an AutoFix flow that closes the loop without a manual fix step.

Related resources

• PR and Release Gating — configuration detail

• SAST AutoTriage — noise reduction mechanics

• Aikido Product page — full scanner and feature list

• Aikido vs Semgrep vs GHAS — CI/CD-relevant comparison

• Aikido as a Low-Noise Checkmarx Alternative — migration-focused

• Latio 2026 AppSec report — Aikido named a platform leader — independent third-party validation