[Trustabl-Je]

Hi! We came across crewAIInc/crewAI and like that it focuses on building an open-source framework for creating AI agents.

We ran Trustabl, an open-source agent reliability scanner, on the repo and it flagged a few things that may be worth a look:

• CrewAI agent enables built-in code execution (lib/crewai/tests/test_crew.py): This Agent sets allow_code_execution=True, which makes CrewAI auto-inject a CodeInterpreterTool into the agent's tool set.

This PR adds a small GitHub Actions workflow (.github/workflows/trustabl.yml) so these checks run automatically:

• Runs on pushes to the default branch, on pull requests, and on demand
• Advisory only: the job uses continue-on-error, so it never fails your CI
• No secrets needed; findings show up in the repo's code scanning results
• Actions are pinned to commit SHAs, with read-only contents access

Some findings may be intentional. Happy to adjust the workflow, or to close this if it's not useful.

Add Trustabl to your CI · trustabl/trustabl-action · https://trustabl.ai

---

Note

Low Risk
Adds an optional third-party CI scan with read-only repo access and advisory failure behavior; no application or runtime code changes.

Overview
Adds a new GitHub Actions workflow Trustabl Agent Scanner that runs the Trustabl open-source agent reliability scanner on every push to main, on pull requests, and via workflow_dispatch.

The scan job checks out the repo (credentials not persisted), runs trustabl/trustabl-action at a pinned SHA with scanner version v0.1.6, and uses scoped permissions (security-events: write, pull-requests: write) so findings can surface in code scanning. continue-on-error: true keeps the workflow advisory so CI stays green; concurrency cancels in-progress runs per ref.

^{Reviewed by Cursor Bugbot for commit 46e9a84. Bugbot is set up for automated code reviews on this repo. Configure here.}

[strix-security]

Strix Security Review

✅ No open security findings.

PR summary: This PR adds a new GitHub Actions workflow (`.github/workflows/trustabl.yml`) that runs the third-party Trustabl agent-reliability scanner on pushes to main, on pull requests, and on demand, uploading findings to code scanning and posting an advisory (non-blocking) PR comment.

Review summary

The only change is a 33-line workflow file, and it follows the repository's existing CI conventions: pull_request rather than pull_request_target, both actions pinned to full commit SHAs (the trustabl pin verified against the upstream v0.4.1 tag), persist-credentials: false on checkout, top-level contents: read with write scopes narrowed to the scan job, no interpolated github.event.* values, no run: steps and no secrets. Both suspected issues raised during review — the write scopes requested on a PR-triggered job, and the fact that the SHA pin is partly defeated by the action resolving version: v0.1.6 to a mutable release artifact at runtime — were independently validated and rejected: fork PRs receive a read-only token under GitHub's default policy, same-repo PR authors already hold equivalent or greater authority, the action could already execute publisher code via the pinned uses: line, and the repo already relies on runtime-resolved toolchain downloads (for example astral-sh/setup-uv). What remains is least-privilege hygiene rather than a vulnerability: pull-requests: write is unnecessary on the push-to-main path, and pinning the scanner to an immutable digest would make the commit pin fully effective.

Ruled out (2)

• Do the requested `security-events: write` and `pull-requests: write` scopes on a `pull_request`-triggered job let a PR author gain privilege they do not alread…
  Fork PRs get a read-only GITHUB_TOKEN under GitHub's default downgrade (the write scopes are inert for the untrusted-author case), same-repo branch authors already hold equivalent authority, no secrets are referenced, and the workflow grants no `contents: write`, matching the pre-existing posture o…
• Does passing `version: v0.1.6` let a mutable runtime release download bypass the action's commit SHA pin and execute unreviewed code with the job token?
  The action does resolve that version to a mutable GitHub release and run it with inherited environment, but the SHA-pinned `uses:` line already runs publisher-written code with the same token, no attacker-controlled value reaches the download or the process arguments, and runtime-resolved toolchain…

_{Review 1 on this PR · 46e9a84 · requested Oct 27 03:07 UTC when the PR was opened}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[github-actions]

Thanks for the pull request.

First-time contributors need an associated open issue before we can review a PR.

1. Open an issue with a template, or pick an existing open one.
2. Open a new PR (or reopen this one) whose title or body mentions that issue, for example #123.

See the contributing guide.

[cursor]

🔒 Agentic Security Review

Severity: HIGH

Description: The new scan job SHA-pins trustabl/trustabl-action@973f666 (tag v0.4.1) but selects the executed engine with version: v0.1.6. At that commit the action treats any value other than latest as a release tag, downloads trustabl_.tar.gz and checksums.txt from the same GitHub release URL, and accepts the archive when those two publisher-controlled files match. It then spawns the extracted binary with the job environment. The v0.1.6 release (canonical repo trustabl/agent-reliability-analyzer, which trustabl/trustabl redirects to) is marked immutable:false, and the only visible ruleset protects the main branch, so the tag and its assets can still be replaced. A party who can replace that release gets code execution on push to main, workflow_dispatch, and same-repo pull_request runs with this job's GITHUB_TOKEN.

Impact: This PR newly runs a public third-party binary, bound only to a mutable release tag, inside CI with security-events: write and pull-requests: write. On non-fork runs that token can upload arbitrary code-scanning analyses and post or edit pull-request comments, including by calling the GitHub API directly from the spawned process. Those alerts and comments persist in the Security tab and PR conversation after the job ends. contents: read and the absent id-token permission keep the blast radius to those write scopes plus the ephemeral runner: the job cannot push commits, change workflows, or mint an OIDC cloud credential. Fork pull_request runs still receive GitHub's read-only GITHUB_TOKEN, so an external PR author does not obtain the write scopes. ACTIONS_RUNTIME_TOKEN is inherited too, but it is a job-scoped Actions service credential and is not the code-scanning or pull-request credential. continue-on-error only keeps the check advisory; it does not stop token use or SARIF upload. persist-credentials: false only stops the checkout step from storing git credentials.

Remediation: Record the engine archive digest in this repository after hashing the artifact you intend to run, and verify the download against that value. The pinned action has no checksum input and its same-release checksums.txt does not provide that binding, so use an action or wrapper that fails closed on an independent digest and spawns the scanner without GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN. Keep those credentials only in the SHA-pinned action process that uploads SARIF and comments. Keep the action commit pin and contents: read.