Skip to content

[Security Question]: How do you prevent malicious or supply-chain attack PRs from being merged?Β #2246

Description

@MrViSiOn

Details

Security Concern: Preventing Malicious Pull Requests

Hi team πŸ‘‹

First of all, great work on Orca β€” it's an impressive project.

I wanted to raise a security question that I think is important for a tool like this, which runs with elevated privileges on users' machines and integrates deeply with AI agents and code execution.

The concern

Orcas's open-source nature means that anyone can submit a Pull Request. This opens the door to potential supply-chain attacks or malicious contributions, where a bad actor could:

  • Inject malicious code into core execution paths
  • Introduce backdoors in agent integrations or terminal/shell runners
  • Smuggle data-exfiltration logic into networking or API-related modules
  • Gradually escalate privileges through seemingly innocent incremental PRs

These kinds of attacks are well-documented (e.g., the xz utils backdoor, event-stream npm incident, etc.) and are particularly dangerous for tools that:

  • Execute code locally
  • Have access to the filesystem
  • Communicate with external APIs or AI backends

My questions

  1. What is your current PR review process? Do you have a checklist or policy for reviewing contributions from unknown/new contributors?
  2. Do you use any automated security scanning on PRs (e.g., CodeQL, Dependabot, Semgrep, Socket.dev for supply-chain risks)?
  3. Do you enforce signed commits or any form of contributor identity verification?
  4. Is there a SECURITY.md or responsible disclosure policy in place?
  5. Do you have branch protection rules that require reviews from specific trusted maintainers before merging?

Suggestion

I'd strongly recommend:

  • Publishing a SECURITY.md with a clear vulnerability disclosure process
  • Enabling GitHub's dependency review and secret scanning
  • Requiring at least 2 maintainer approvals for PRs touching sensitive areas (agent execution, networking, auth)
  • Running SAST tools (CodeQL / Semgrep) automatically on every PR via GitHub Actions
  • Considering a CODEOWNERS file to assign mandatory reviewers per module

Given that Orca is an AI-powered tool that executes code and interacts with the filesystem, the attack surface is significant. I'd love to understand your current security posture and how the community can help keep this project safe.

Thanks for your time and for maintaining this project!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions