🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== workflow file =="
cat -n .github/workflows/labeler.yml

echo
echo "== referenced reusable workflow metadata/contents if present =="
if [ -f .github/commit-check/.github/.github/workflows/pr-labeler.yml ]; then
  wc -l .github/commit-check/.github/.github/workflows/pr-labeler.yml
  cat -n .github/commit-check/.github/.github/workflows/pr-labeler.yml
else
  echo "referenced file not present in tree"
fi

echo
echo "== search for pr-labeler workflow usage/checkouts =="
rg -n "pr-labeler\.yml|pull_request_target|pull-requests: write|actions/checkout|checkout|\${{\s*github\.event\.pull_request|github\.event\.pull_request" .github -S || true

Repository: commit-check/commit-check

Length of output: 1105

🌐 Web query:

commit-check .github workflows pr-labeler.yml main

💡 Result:

The term "commit-check" in a GitHub Actions workflow typically refers to the use of the Commit Check tool [1][2], a policy engine used to validate Git commit metadata such as commit messages, branch names, and author information [1][3][4]. While users may name their workflow files anything (e.g., pr-labeler.yml) [5], the specific action provided by the Commit Check project is commonly implemented in a dedicated workflow file like.github/workflows/commit-check.yml [3][6]. To integrate Commit Check into your workflow, you can add the following step to your GitHub Actions file [3][4]: - uses: commit-check/commit-check-action@v2 with: message: true branch: true # Optional configurations author-name: false author-email: false job-summary: true pr-comments: ${{ github.event_name == 'pull_request' }} Key requirements for this action include: 1. Using actions/checkout@v5 with fetch-depth: 0 to ensure the full history is available for validation [3][4][6]. 2. Optionally providing a cchk.toml file in your repository root to customize policies [2][6]. If you are encountering a workflow named pr-labeler.yml that includes a commit check, it is likely a custom implementation where the developer has combined automated PR labeling with a commit validation step (often using actions/github-script or custom bash scripts) to enforce project standards [7][8][9]. Unlike the dedicated Commit Check action, these custom implementations often use regex patterns or API calls to validate commit titles directly within the PR workflow [7][8].

Citations:

• 1: https://commit-check.github.io/commit-check/
• 2: https://pypi.org/project/commit-check/
• 3: https://github.com/commit-check/commit-check-action
• 4: https://commit-check.github.io/
• 5: https://github.com/ruzickap/my-git-projects/actions/workflows/pr-size-labeler.yml
• 6: https://github.com/marketplace/actions/commit-check-action
• 7: https://github.com/alexneamtu/htoprc.dev/blob/6163fe03a5a44d50b3443bf77d03764bd6a30be2/.github/workflows/pr-checks.yml
• 8: https://github.com/leplusorg/docker-md/blob/acfdf7c8ebfa992e0605f588306a570a72120094/.github/workflows/check-pr.yml
• 9: https://github.com/troylar/devsync/blob/ba0ca2671feac736571242302876a0f4317671c2/.github/workflows/pr-automation.yml

🌐 Web query:

site:github.com/commit-check/.github .github/workflows/pr-labeler.yml

💡 Result:

The file path.github/workflows/pr-labeler.yml is a common convention for a GitHub Actions workflow file designed to automatically label pull requests. While the specific file name is user-defined, it typically leverages the official actions/labeler GitHub Action to categorize pull requests based on the files they modify. To implement this functionality, you generally need two components: 1. A workflow file (e.g.,.github/workflows/pr-labeler.yml) that triggers on pull request events. 2. A configuration file (often located at.github/labeler.yml) that defines the rules for which files should trigger which labels. Example configuration for.github/workflows/pr-labeler.yml: name: Pull Request Labeler on: pull_request_target: types: [opened, synchronize, reopened] jobs: label: runs-on: ubuntu-latest permissions: contents: read pull-requests: write steps: - uses: actions/labeler@v5 with: repo-token: ${{ secrets.GITHUB_TOKEN }} The corresponding.github/labeler.yml file would map patterns to labels, such as: documentation: - docs/ - README.md frontend: - src/ui/ The provided search results did not contain specific implementation details for this file path within the referenced repositories.

Citations:

• 1: https://github.com/commit-check/.github
• 2: https://github.com/commit-check/.github/blob/main/CONTRIBUTING.md
• 3: https://github.com/commit-check/.github/blob/main/SECURITY.md

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== git diff stat and any workflow-related diff context =="
git diff --stat || true
git diff -- .github/workflows/labeler.yml .github/commit-check/.github/.github/workflows/pr-labeler.yml || true

echo
echo "== workflow references to pull_request_target/reusable workflow/permissions =="
rg -n "pull_request_target|pull-requests:\s*write|uses:\s*commit-check/.github/.github/workflows/pr-labeler.yml|actions/github-script|actions/checkout|\$\{\{\s*github\.event\.github\.event_name|github\.event\." .github/workflows/labeler.yml .github/commit-check/.github/.github/workflows/pr-labeler.yml 2>/dev/null || true

Repository: commit-check/commit-check

Length of output: 621

Pin the privileged reusable workflow to an immutable commit SHA.

pull_request_target grants pull-requests: write to the reusable workflow at @main, so that mutable branch can receive write access if changed. Pin pr-labeler.yml to an audited full-length commit SHA and ensure it does not check out or execute fork code.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/labeler.yml around lines 4 - 5, Pin the privileged
reusable workflow referenced by the pull_request_target workflow to an audited,
full-length immutable commit SHA instead of the mutable main branch. Update the
pr-labeler.yml invocation while preserving the existing pull-requests write
permission, and ensure the workflow does not check out or execute code from the
forked pull request.