PR/MR Pipeline Security

This document explains the security differences between the pull_request and pull_request_target trigger events, helping to choose the correct Fork PR pipeline configuration.

PR pipelines need to execute code from external contributors (fork repositories), which poses a security risk. It is necessary to understand the security differences between pull_request and pull_request_target events and choose the appropriate configuration.

Configuration Explanation

Security Differences Between pull_request and pull_request_target

Dimension	pull_request	pull_request_target
Code Source	Code from fork repository (PR submission)	Code from target repository (workflow version on main branch)
ATOMGIT_TOKEN Permissions	Read-only permissions (security restrictions)	Full permissions as declared in permissions
Secrets Accessibility	Secrets of the project are not accessible from fork	Secrets of the project are accessible
Workflow File Version	Uses workflow version from fork	Uses workflow version from target branch
Applicable Scenarios	Safe code checks, lint, build	Deployment, release, comment requiring write permissions
Default Checkout Code Source	PR pre-merged branch	Base branch

Detailed Explanation of pull_request Event

# .gitcode/workflows/pr-check.yml
on:
  pull_request:
    branches: [main]

permissions:
  repository: read        # ATOMGIT_TOKEN has only read permission under pull_request
  pr: read                # Cannot perform write operations on PR

stages:
  check:
    name: Code Check
    jobs:
      name: lint-and-test
      runs-on: [ubuntu-24, x64, small]
      steps:
        - run: npm run lint
          - run: npm test

Security Mechanism:

• Code Source: Executes code from the PR branch of the fork repository, including workflow files modified by the PR submitter.
• Permission Restrictions: The ATOMGIT_TOKEN has only read permissions, unable to push code, modify PR, or operate project resources.
• Secret Isolation: Workflow from fork cannot access project-level and organization-level secrets.

This means: Malicious PR submitters can modify workflow file content, but due to lack of secrets and write permissions, the attack scope is limited — they cannot steal credentials or modify the repository.

Detailed Explanation of pull_request_target Event

# .gitcode/workflows/pr-build.yml
on:
  pull_request_target:
    branches: [main]

permissions:
  repository: write       # ATOMGIT_TOKEN has write permissions under pull_request_target
  pr: write               # Can comment/operate on PR

stages:
  build:
    name: Build
    jobs:
      name: build-and-report
      runs-on: [ubuntu-24, x64, medium]
      steps:
        - uses: checkout
          with:
            ref: ${{ atomgit.event.pull_request.head.sha }}   # checkout PR code
          - run: make build
          - run: |
              curl -X POST "https://atomgit.com/api/v5/repos/${{ atomgit.repository }}/pulls/${{ atomgit.event.pull_request.number }}/comments" \
                -H "Authorization: token $ATOMGIT_TOKEN" \
                -d '{"body": "Build succeeded ✅"}'

Security Mechanism:

• Code Source: The workflow file uses the version from the target repository (main branch), not from the fork. This is the key difference — PR submitters cannot modify the execution logic.
• Permission Scope: ATOMGIT_TOKEN has full permissions as declared in permissions, allowing writing to the repository and operating on PR.
• Secret Accessibility: Can access project-level and organization-level secrets.