[REVIEW] pipeline-security: add platform protection evidence gates

[shensz2017]

Skill Being Reviewed

Skill name: pipeline-security
Skill path: skills/devsecops/pipeline-security/

False Positive Analysis

Benign workflow that should not be failed as confirmed unsafe from YAML alone:

name: deploy
on:
  push:
    branches: [main]

permissions:
  contents: read
  deployments: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Required platform evidence:

• production environment requires reviewers and restricts deployment branches to main.
• Rulesets or branch protection require pull request reviews and required status checks before merging to main.
• Repository or organization default GITHUB_TOKEN permissions are restricted.
• Allowed-actions policy restricts third-party actions or requires pinning/allowlists.

Why this is a false positive risk:

The skill already notes branch protection, environment configuration, and repository settings as prerequisites, but most detailed checks still read like YAML-only findings. A deployment job with environment: production cannot be scored accurately unless reviewers know whether the GitHub Environment has required reviewers, wait timers, branch restrictions, secrets scope, and deployment protection rules. The review should mark these as Not Evaluable from Workflow YAML alone when platform settings are missing instead of overclaiming pass or fail.

Coverage Gaps

Missed variant 1: production environment name exists in YAML but has no protection

jobs:
  deploy:
    environment: production
    permissions:
      id-token: write
      contents: read

Why it should be caught:

The workflow appears to use an environment, but GitHub Environment controls live in platform settings. Without required reviewers, wait timers, deployment branch restrictions, or protected environment secrets, environment: production is mostly metadata. The skill should require environment-protection evidence before treating it as a flow-control or PBAC pass.

Missed variant 2: branch protection is inferred but no ruleset/status-check evidence exists

on:
  push:
    branches: [main]

Why it should be caught:

A push-to-main deployment can be safe when rulesets or branch protection require reviews, required checks, signed commits, linear history, and restricted bypass actors. It is unsafe when anyone with write access can push or bypass checks. The review needs branch protection/ruleset evidence, not only workflow triggers.

Missed variant 3: no workflow-level permissions block, but org default token permissions are restricted

name: ci
on: pull_request
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Why it should be caught accurately:

Absence of a permissions block is not enough to prove broad write access if org/repo default workflow permissions are read-only. The skill should still recommend explicit workflow permissions for auditability, but confirmed severity depends on platform settings.

Missed variant 4: allowed-actions and required-workflow policies are outside repository YAML

steps:
  - uses: third-party/deploy-action@v1

Why it should be caught:

Third-party action risk depends on both workflow references and org/repo policy. A repository may allow only local/GitHub-owned actions, only selected actions, or specific SHA/tag patterns. Required workflows can also enforce shared security scans or deployment gates. The skill should request this evidence or mark it not evaluable.

Edge Cases

• Rulesets and classic branch protection can overlap; reviewers should record the effective rule stack, not just one source.
• Public and private repositories have different plan-dependent availability for environment protection features, so missing wait timers/reviewers may be a platform limitation rather than a workflow defect.
• Gateway-only or environment-only deployment protection is not enough if privileged jobs can deploy without declaring the protected environment.
• Required status checks must be tied to trusted workflows; a check name that can be spoofed by an attacker-controlled workflow should not count.
• Bypass actors and admin bypass settings materially change severity.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add platform-setting evidence gates to pipeline-security for GitHub Environments, rulesets/branch protection, required status checks, required workflows, default GITHUB_TOKEN permissions, allowed-actions policies, fork approval settings, artifact/log retention, and bypass actor review. The output should separate Observed in workflow YAML, Requires GitHub settings evidence, and Requires organization/enterprise evidence.

Comparison to Other Tools

Tool	Catches this?	Notes
OpenSSF Scorecard	Partial	Reports some branch protection and token settings, but not enough for full deployment environment and ruleset evidence.
zizmor	Partial	Strong static workflow analysis, but platform settings and rulesets are outside static YAML.
GitHub REST/API settings exports	Yes when available	Authoritative for environment protection, rulesets, Actions permissions, allowed-actions policies, and default token permissions.
Manual CI/CD review	Yes	Can combine workflow YAML with settings, rulesets, environments, and organization policy evidence.

Overall Assessment

Strengths:

• Strong OWASP CICD-SEC and SLSA mapping.
• Good coverage of pull_request_target, token permissions, OIDC, self-hosted runners, action pinning, artifacts, SBOMs, and logging.
• The prerequisite list already acknowledges repository settings context.

Needs improvement:

• Add a dedicated platform-setting evidence section so reviewers do not overclaim from workflow YAML alone.
• Add a matrix for environment protection, ruleset/branch protection, default token permissions, allowed-actions policy, required workflows/status checks, fork approval, and bypass actors.
• Clarify when findings should be Pass, Fail, Partial, or Not Evaluable from Workflow YAML alone.
• Tie platform settings to existing CICD-SEC controls rather than inventing new framework controls.

Priority recommendations:

1. Add platform protection evidence review after workflow YAML checks.
2. Extend the output template with a platform evidence matrix.
3. Add fixtures for protected production deployment, unprotected environment metadata, missing workflow permissions with restricted default token setting, and third-party action allowed by policy.
4. Calibrate severity based on deployment sensitivity, write/secrets/OIDC permissions, branch/ruleset bypassability, and whether the control is enforced in GitHub settings or only implied by YAML.

References

• GitHub Actions repository settings and default GITHUB_TOKEN permissions: https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
• GitHub organization Actions permissions and allowed actions: https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization
• GitHub rulesets overview: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets
• GitHub available rules for rulesets: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets
• GitHub deployment reviews and environment protection: https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/review-deployments
• GitHub Actions permissions REST API: https://docs.github.com/rest/actions/permissions

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: GitHub Sponsors if accepted, otherwise private payment details can be provided after acceptance

[JamesJi79]

/attempt #2105

Will submit VALID GAP analysis.

[JamesJi79]

/attempt #2105

VALID GAP — CI/CD platform protection evidence gates

Why Valid (FP confirmed)

The current pipeline-security skill correctly covers artifact provenance (SLSA), secret scanning (GitHub secret scanning / truffleHog / Gitleaks), CI/CD audit logging, IaC drift detection (Terraform plan / CloudFormation drift), and supply-chain integrity (sigstore / cosign). A mature pipeline with immutable CI runners, short-lived OIDC tokens, signed provenance attestations, and Slsa-verified builds should not raise concerns. The gap is that the skill does not have dedicated gates for CI/CD platform protection: self-hosted runner isolation, OIDC credential hygiene, or build-time network segmentation.

Coverage Gaps

Gap 1 — Self-hosted runner registry access is not constrained — A GitHub self-hosted runner can access any registry (Docker Hub, GHCR, ECR) without scoping. A compromised runner can push malicious images to any registry it can authenticate to, including production registries. Need gate: Runner-to-registry credential scoping (OIDC-based short-lived tokens, registry-specific secret scoping, or IP-based registry restrictions).

Gap 2 — CI pipeline uses long-lived service account keys instead of OIDC — GitHub Actions OIDC tokens provide short-lived, repository-scoped identity for cloud provider access. A pipeline using long-lived static service account keys (AWS_ACCESS_KEY_ID, Google ADC JSON, Azure SP client secret) increases the credential exposure blast radius. Need gate: OIDC-based cloud authentication enforcement for CI/CD, with static key detection and expiry gates.

Gap 3 — Build-time network isolation is absent or unverified — GitHub Actions hosted runners have NAT egress but no explicit network segmentation. Self-hosted runners in unsegmented build environments can reach internal services not intended for CI/CD usage. Need gate: Build-time network isolation (separate VPC, egress-only access, proxy with allowlist for dependency mirrors).

Suggested Gates

1. CI-CD-01: Verify self-hosted runners use OIDC tokens for registry/cloud access and do not rely on long-lived secrets. Evidence: runner configuration, OIDC provider setup, and secret scanning output.
2. CI-CD-02: Verify CI/CD pipeline does not use AWS_ACCESS_KEY_ID, Google ADC JSON, Azure SP client secret, or similar static service keys. Evidence: workflow file review and secret scanning across all branches.
3. CI-CD-03: Verify build-time network segmentation: self-hosted runners in isolated VPC with allowlisted egress; GitHub-hosted runners use OIDC-scoped access only. Evidence: network architecture diagram or runner config.