You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a PR from a fork, GITHUB_TOKEN is read-only, so the report-comment step in both security workflows fails with 403 Resource not accessible by integration:
Component Security Validation → Comment PR with Results
Skill Security Scan → Comment PR with results
Every step before it completes, and the job goes red at the comment step. Recent examples:
SkillSpector's Enforce gate never runs on fork PRs. It is ordered after the comment step, and the 403 fails the job first (run 30843950116 shows it as skipped). The HIGH/CRITICAL block only enforces on same-repo PRs, and for outside contributors every PR is a fork PR.
Red has stopped meaning "flagged." Every fork PR gets the same two red X's whether its scans passed or not, so a flagged skill produces the same signal as a clean one; feat(skills): add patentfig skill (creative-design) #770 merged over them. On the Security Audit side the audit step is continue-on-error: true, so the comment 403 is that job's only failure mode: red there never means the audit failed. (The CI-mode audit currently exits non-zero on every run, with 412 of 769 components failing the strict checks repo-wide, and even that never reds the job.)
The minimal fix is to skip the comment step when the PR is from a fork (github.event.pull_request.head.repo.full_name == github.repository). Fork contributors get no comment today either (the step 403s before posting), and the reports stay available as artifacts. With the step skipped instead of failing, the jobs go green when scans pass and Enforce gate actually runs.
A fuller fix would move the commenting into a workflow_run job, which runs with write permissions and could post the report on fork PRs too. That is a bigger change; the guard works either way as a first step.
On a PR from a fork,
GITHUB_TOKENis read-only, so the report-comment step in both security workflows fails with403 Resource not accessible by integration:Comment PR with ResultsComment PR with resultsEvery step before it completes, and the job goes red at the comment step. Recent examples:
Scanned=1 flagged=0 errors=0continue-on-error)Two effects beyond the cosmetic red X:
Enforce gatenever runs on fork PRs. It is ordered after the comment step, and the 403 fails the job first (run 30843950116 shows it as skipped). The HIGH/CRITICAL block only enforces on same-repo PRs, and for outside contributors every PR is a fork PR.continue-on-error: true, so the comment 403 is that job's only failure mode: red there never means the audit failed. (The CI-mode audit currently exits non-zero on every run, with 412 of 769 components failing the strict checks repo-wide, and even that never reds the job.)The minimal fix is to skip the comment step when the PR is from a fork (
github.event.pull_request.head.repo.full_name == github.repository). Fork contributors get no comment today either (the step 403s before posting), and the reports stay available as artifacts. With the step skipped instead of failing, the jobs go green when scans pass andEnforce gateactually runs.A fuller fix would move the commenting into a
workflow_runjob, which runs with write permissions and could post the report on fork PRs too. That is a bigger change; the guard works either way as a first step.