← Back to blog
Security

Is Alibaba Open Code Review safe for GitHub Actions?

· 6 min read

I wanted to try Alibaba's Open Code Review in GitHub Actions. Before giving it access to private repositories, though, I needed an answer to a more important question: where does my source code actually go?

The short version is that I would approve a limited, hardened pilot on a non-sensitive repository. I would not copy the default workflow into a private production repository and call it done.

Safe to test is not the same as safe by default. The model endpoint, update path, logs, artifacts, and runner all belong in the threat model.

This review is a point-in-time source and supply-chain assessment, not a penetration test. I reviewed release v1.7.17 at commit 0ced7165718725e15223c3e5a506df7b7e9de51f and the then-current main branch at 74f5cde8b434a3dc8378e2101459f2998e940a07.

The biggest finding: this is not a local-only reviewer

Open Code Review sends the review context to the LLM endpoint you configure. That includes diffs, filenames, and review instructions. More importantly, its built-in tools let the agent find, search, and read repository files. File reads in range mode use git show against the PR head. I therefore treat the entire tracked repository—not only changed lines—as potentially disclosed to the model provider.

I did not find an intentional mechanism that sends repository contents to Alibaba when a non-Alibaba LLM endpoint is configured. Alibaba receives the code if I choose an Alibaba-hosted model such as DashScope. Otherwise, the primary disclosure is to whichever provider sits behind llm_url.

That distinction matters, but it does not make the data exposure disappear. Before using this on private code, I would verify the model provider's retention, training, regional-processing, and zero-retention terms. I would also require TLS. The tool accepts custom HTTP endpoints, so configuration—not the product—has to prevent proprietary code and tokens from crossing the network in plaintext.

Every place data can leave the runner

The LLM is the obvious destination, but it is not the only one:

  • The configured model endpoint can receive diffs, paths, review rules, and additional repository files the agent reads for context.
  • GitHub receives the posted review, Action logs, and—unless disabled—uploaded review and stderr artifacts.
  • The npm registry sees normal package and version-check traffic, including runner network metadata, but I found no repository content in that exchange.
  • An OpenTelemetry collector receives nothing by default. If telemetry is enabled, it can receive paths, model names, counts, timings, and errors, but I did not find prompts or responses in the reviewed telemetry path.
  • Configured MCP servers create new capabilities and new egress paths. A clean GitHub-hosted runner does not have those by default.
  • The runner disk holds review-session transcripts under ~/.opencodereview/. That is temporary on a hosted runner and persistent on a typical self-hosted machine.

Artifacts deserve special attention because the official Action uploads raw output and stderr by default. That duplicates material already written to the Action log and gives it a separate retention lifecycle. For a pilot, I would disable uploads and decide explicitly what evidence is worth keeping.

The supply chain is more mutable than it looks

The documented workflow uses alibaba/open-code-review@main, and the Action defaults to ocr_version: latest. Those are two independent moving targets. GitHub's secure-use guidance recommends full-length commit SHAs because they are the only immutable Action references.

There is a third update path: the npm wrapper checks for new releases and can install a newer version in the background. Setting an exact ocr_version is not sufficient on its own. The wrapper's startup logic and update script show why OCR_NO_UPDATE=1 is part of my baseline.

Even pinning the outer Action does not make the entire graph immutable. The composite Action references dependencies such as actions/checkout@v4 and actions/github-script@v7 by moving tags. For a high-assurance installation, I would vendor the workflow and pin those nested actions too.

pull_request_target needs deliberate guardrails

The Action uses pull_request_target, which runs in the trusted base repository context and can access secrets. The implementation makes an important safe choice: it checks out the trusted base and reads the PR's Git objects as data instead of executing the contributor's code.

That reduces the classic untrusted-checkout risk, but an external PR can still trigger model spend, inject instructions into the review context, and try to persuade the agent to read unrelated files. GitHub treats this trigger as privileged and recommends careful gating. For the first pilot, I would only review branches from the same repository. I would open fork PRs later, after adding an approval gate and a budget strategy.

The hardened workflow I would actually test

name: OCR review

on:
  pull_request_target:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    # Pilot first: do not expose the LLM credential to fork PRs.
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-24.04
    timeout-minutes: 20

    env:
      OCR_NO_UPDATE: "1"
      OCR_ENABLE_TELEMETRY: "0"

    steps:
      - uses: alibaba/open-code-review@0ced7165718725e15223c3e5a506df7b7e9de51f
        with:
          llm_url: ${{ secrets.OCR_LLM_URL }}
          llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }}
          llm_model: ${{ vars.OCR_LLM_MODEL }}
          llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }}
          ocr_version: "1.7.17"
          upload_artifacts: "false"

I would run this on a GitHub-hosted runner, start with a public or synthetic repository, and inspect the network destinations, logs, review comments, and token spend before widening scope. If I later moved it to self-hosted infrastructure, I would use an ephemeral or container-isolated runner and ensure old config, telemetry, MCP tools, and transcripts could not carry across runs.

What the verification did—and did not—prove

For the reviewed release, I matched the npm wrapper files to the tagged source. The Linux npm executable was byte-identical to the GitHub release binary and matched its published SHA-256. GitHub's provenance-attestation verification succeeded, and the release commit's core test, cross-build, and CodeQL checks passed. I also found no published repository security advisories at the time of review.

Those checks increase confidence that the published artifact corresponds to the reviewed source. They do not prove the software is vulnerability-free, guarantee future releases, or approve a third-party model provider to process private code.

My final call

  • Public or non-sensitive test repository: reasonable for a hardened pilot.
  • Private proprietary repository: only after approving the LLM provider to receive the whole tracked repository.
  • Highly sensitive, regulated, or secret-bearing repository: use an internal or self-hosted model gateway with an ephemeral runner—or do not use this tool.

So, is Alibaba Open Code Review safe? With a pinned release, disabled updates and artifacts, constrained permissions, fork gating, an approved model endpoint, and an ephemeral runner, it is safe enough for the pilot I wanted. Without those controls, the default path asks me to trust too many mutable and externally visible pieces at once.

← Back to blog