Skill Being Reviewed
Skill name: pipeline-security
Skill path: skills/devsecops/pipeline-security/SKILL.md
False Positive Analysis
Benign code/configuration that can be over-flagged:
runs-on: [self-hosted, linux, deploy]
# runner is ephemeral VM, one job per instance, wiped after completion
Why this is a false positive:
runs-on: [self-hosted, linux, deploy] can be safe when the missing compensating evidence is present, but the current skill does not ask reviewers to distinguish that evidence from the risky pattern. The review should require proof of the guardrail before escalating severity.
Coverage Gaps
Missed variant 1:
pull_request_target:
jobs:
build:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
with: { ref: ${{ github.event.pull_request.head.sha }} }
Why it should be caught:
This variant leaves a realistic attack path open while still satisfying the current high-level checklist language.
Missed variant 2:
runs-on: self-hosted
steps:
- run: echo $DEPLOY_KEY > key && ./untrusted-test.sh
# persistent workspace reused by later deploy job
Why it should be caught:
This is a common production edge case where policy exists on paper but does not bind the runtime behavior or evidence trail.
Edge Cases
Self-hosted runners change the CI trust model. A safe workflow on GitHub-hosted runners can become critical if untrusted PR code lands on a persistent runner with secrets, network reach, or cached credentials.
Remediation Quality
Comparison to Other Tools
| Tool |
Catches this? |
Notes |
| Scorecards |
Partial |
Flags dangerous workflow patterns but not runner lifecycle evidence. |
| CodeQL |
No |
Does not model runner persistence. |
| GitHub policy settings |
Partial |
Useful if organization-level controls are evidenced. |
Overall Assessment
Strengths:
The skill already covers CI/CD governance and workflow-change risks.
Needs improvement:
It needs explicit self-hosted runner threat modeling because runner persistence is a common source of credential and deployment compromise.
Priority recommendations:
- Add a self-hosted runner checklist for ephemeral lifecycle, labels, and cleanup.
- Treat pull_request_target plus self-hosted execution as high severity unless separately proven safe.
- Require artifact/cache poisoning review between untrusted test jobs and privileged deploy jobs.
Bounty Info
Skill Being Reviewed
Skill name: pipeline-security
Skill path:
skills/devsecops/pipeline-security/SKILL.mdFalse Positive Analysis
Benign code/configuration that can be over-flagged:
Why this is a false positive:
runs-on: [self-hosted, linux, deploy] can be safe when the missing compensating evidence is present, but the current skill does not ask reviewers to distinguish that evidence from the risky pattern. The review should require proof of the guardrail before escalating severity.
Coverage Gaps
Missed variant 1:
Why it should be caught:
This variant leaves a realistic attack path open while still satisfying the current high-level checklist language.
Missed variant 2:
Why it should be caught:
This is a common production edge case where policy exists on paper but does not bind the runtime behavior or evidence trail.
Edge Cases
Self-hosted runners change the CI trust model. A safe workflow on GitHub-hosted runners can become critical if untrusted PR code lands on a persistent runner with secrets, network reach, or cached credentials.
Remediation Quality
Comparison to Other Tools
Overall Assessment
Strengths:
The skill already covers CI/CD governance and workflow-change risks.
Needs improvement:
It needs explicit self-hosted runner threat modeling because runner persistence is a common source of credential and deployment compromise.
Priority recommendations:
Bounty Info