Bitbucket

Airia discovers AI assets living in your Bitbucket Cloud repositories: agent frameworks, model SDK usage, prompt files, workflow definitions, MCP server configurations, and hard-coded LLM keys or endpoints.

Status

The Bitbucket connector is released behind a feature flag, so it may not be enabled for your tenant yet. If the Bitbucket tile is not visible under Discover → Connect, ask your Airia contact to enable it. Ingestion is not gated: once a pipeline is configured, scans are accepted and appear in the inventory regardless of the flag.

How Bitbucket discovery works

Bitbucket discovery is powered by the Airia Code Scanner, which runs as a Bitbucket Pipelines step inside your repository. Each scan analyzes the repository's contents and reports its findings to your Airia tenant; every scanned repository then appears as a Bitbucket connection under Discover → Connect, with the discovered code-based agents in the inventory.

There is no credential form to fill in on the Airia side, and Airia never connects to Bitbucket: the scanner authenticates to Airia with an API key you store as a repository variable, and pushes results outward.

The step runs the scanner image directly as its image:, so it needs no Docker service.

What the scanner detects

Customer-side setup steps

1. Generate an Airia API key. In Airia: Settings → Developer → API Keys → Generate Key. Keep Service account selected, since the key is shared with your CI pipeline. Under Roles, select End User. The scanner only reports findings, which needs a valid key but no particular permission, so the least-privileged default role is enough. Name it something like code-scanner-bitbucket, set Scope to All projects, click Create, then copy the key — it is shown once.

2. Enable Pipelines. In the Bitbucket repository: Repository settings → Pipelines → Settings → Enable Pipelines. Pipelines is off by default, and a committed bitbucket-pipelines.yml does nothing until it is on.

3. Add two repository variables. Repository settings → Pipelines → Repository variables.

   Name	Value	Flags
   AIRIA_API_URL	your Airia API URL, for example https://api.airia.ai on Airia's US cloud (use your instance's API URL on another region or a self-managed instance), with no path and no trailing /	—
   AIRIA_API_TOKEN	the API key from step 1	Secured

   To scan several repositories, add the same two variables once as workspace variables (Workspace settings → Pipelines → Workspace variables) instead of per repository. A repository variable overrides a workspace variable with the same name.

4. Add the pipeline file. Create bitbucket-pipelines.yml at the repository root, or merge the step definition and pipelines into an existing one. Replace main under branches: with your default branch.

   # Airia Code Scanner
   
   definitions:
     steps:
       - step: &airia-code-scan
           name: Airia Code Scan
           # The scanner image is the build container: no Docker service needed.
           image: airiadevops305/airia-code-scanner:latest
           script:
             - export PROVIDER="Bitbucket"
             - export REPOSITORY_OWNER="$BITBUCKET_WORKSPACE"
             - export REPOSITORY="$BITBUCKET_REPO_SLUG"
             # BITBUCKET_GIT_HTTP_ORIGIN is http://, so the URL is built explicitly.
             - export REPOSITORY_URL="https://bitbucket.org/$BITBUCKET_REPO_FULL_NAME"
             - export BRANCH="$BITBUCKET_BRANCH"
             - export COMMIT_SHA="$BITBUCKET_COMMIT"
             # AIRIA_API_URL and AIRIA_API_TOKEN come from the repository variables
             # added in step 2. A trailing slash would break the webhook path.
             - export AIRIA_API_URL="${AIRIA_API_URL%/}"
             # Bitbucket clones into .../agent/build, and the scanner skips any path
             # containing a "build" directory, so it scans a copy of the checkout.
             - cp -a "$BITBUCKET_CLONE_DIR" /tmp/src
             - export GITHUB_WORKSPACE=/tmp/src
             - /app/scanner-cli || rc=$?
             # Step artifacts are collected from the clone dir.
             - cp /tmp/src/scan-results.json "$BITBUCKET_CLONE_DIR/" || true
             - exit ${rc:-0}
           artifacts:
             - scan-results.json
   
   pipelines:
     branches:
       # Replace main with your default branch.
       main:
         - step: *airia-code-scan
     pull-requests:
       '**':
         - step: *airia-code-scan
     custom:
       # Run by hand from Pipelines > Run pipeline, or from a schedule.
       airia-code-scan:
         - step: *airia-code-scan

5. Run the pipeline. Pushing the file to the default branch triggers it. To start one by hand: Pipelines → Run pipeline, pick the branch and the custom: airia-code-scan pipeline.

6. Verify. Open the Airia Code Scan step log; the scanner prints the repository, branch, commit and workspace it used, and finishes with Successfully reported findings to API (status: 200). The scan-results.json artifact is exactly what was sent, which separates a scanning problem from a delivery one.

   Read the step's status with two caveats:

   • A failed step can still have delivered its results. The scanner exits with an error when it finds a Critical issue, such as a hard-coded API key, so the pipeline blocks on it. It reports to Airia before exiting, so the findings are in Airia either way; the log shows SCAN FAILED: Found N critical security issues.
   • A passed step does not prove delivery. If the report to Airia fails, the scanner logs Failed to report findings or Error reporting to API and the step still passes. Only the Successfully reported findings to API line confirms the results arrived. An Error reporting to API line that mentions a connection or name-resolution failure means AIRIA_API_URL points at the wrong host.

   Then in Airia open Discover → Connect → Bitbucket: the scanned repository appears as a connection, and its discovered agents land in the inventory with their detected frameworks and model references.

Notes

• The pipeline scans a copy of the checkout at /tmp/src. The scanner reads the checkout from GITHUB_WORKSPACE, a name it kept from its GitHub Actions origins, and skips directories such as build. Bitbucket clones into /opt/atlassian/pipelines/agent/build, so the template copies the checkout out of it, and copies scan-results.json back so the step artifact still works. Without GITHUB_WORKSPACE set, the scanner finds nothing and the scan succeeds with zero findings.
• REPOSITORY_URL is built explicitly because BITBUCKET_GIT_HTTP_ORIGIN is an http:// URL. Findings deep-link to bitbucket.org/{workspace}/{repo}/src/{commit}/{path}#lines-{n}.
• Bitbucket Cloud only. Bitbucket Data Center has no Pipelines; run the scanner from your CI of choice as described in Airia Code Scanner.
• Every scan consumes build minutes from the workspace plan. To scan only when relevant files change, merge a condition: changesets: includePaths: onto the step; for large repositories, run the custom pipeline from a schedule (Pipelines → Schedules) instead of on every push.
• One connection appears per scanned repository and branch; multiple repositories mean multiple connections.

Repositories hosted elsewhere are covered by the GitHub, Azure DevOps and GitLab connectors, which use the same scanner and the same push model.