Pipeline Security

Pipeline Security Assessment

Overview

If a target is provided via arguments, focus the review on: $ARGUMENTS

This skill performs a structured security review of CI/CD pipeline configurations against two industry-standard frameworks:

• SLSA v1.0 (Supply-chain Levels for Software Artifacts) -- Build level determination per slsa.dev specifications.
• OWASP Top 10 CI/CD Security Risks -- Systematic evaluation against all ten CICD-SEC controls defined by the OWASP CI/CD Security project.

The assessment produces a formal report containing a SLSA build level determination, per-control CICD-SEC findings, and prioritized remediation guidance.

---

Objectives

1. Determine the repository's current SLSA Build Level (L1, L2, or L3).
2. Evaluate pipeline configurations against each of the ten OWASP CICD-SEC risk categories.
3. Identify concrete misconfigurations, insecure patterns, and missing controls.
4. Deliver prioritized, actionable remediation steps with control IDs.

---

Prerequisites

• Access to CI/CD configuration files (e.g., .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, cloudbuild.yaml).
• Access to repository settings context (branch protection rules, environment configurations).
• Read access to dependency manifests and lock files for supply-chain analysis.

---

Frameworks Reference

SLSA v1.0 Build Levels

| Level | Requirements | Key Controls | |-------|-------------|--------------| | SLSA Build L1 | Documentation of the build process exists. The build process is scripted (not manual). | Build steps defined in version-controlled config. | | SLSA Build L2 | Hosted build platform. Signed provenance generated by the build service. | Builds run on a managed service (GitHub Actions, Cloud Build, etc.). Provenance metadata is produced and signed. | | SLSA Build L3 | Hardened builds. Build environment is isolated, ephemeral, and parameterless. Builds cannot influence one another. | Isolated runners, no shared caches across trust boundaries, hermetic builds, non-falsifiable provenance. |

OWASP Top 10 CI/CD Security Risks

| Control ID | Risk Name | |------------|-----------| | CICD-SEC-1 | Insufficient Flow Control Mechanisms | | CICD-SEC-2 | Inadequate Identity and Access Management | | CICD-SEC-3 | Dependency Chain Abuse | | CICD-SEC-4 | Poisoned Pipeline Execution (PPE) | | CICD-SEC-5 | Insufficient PBAC (Pipeline-Based Access Controls) | | CICD-SEC-6 | Insufficient Credential Hygiene | | CICD-SEC-7 | Insecure System Configuration | | CICD-SEC-8 | Ungoverned Usage of 3rd Party Services | | CICD-SEC-9 | Improper Artifact Integrity Validation | | CICD-SEC-10 | Insufficient Logging and Visibility |

---

Process

Step 1: Discovery -- Locate Pipeline Configurations

Use Glob to locate all CI/CD configuration files in the repository.

Patterns to search:

.github/workflows/*.yml
.github/workflows/*.yaml
.gitlab-ci.yml
Jenkinsfile
Jenkinsfile.*
cloudbuild.yaml
cloudbuild.json
azure-pipelines.yml
.circleci/config.yml
bitbucket-pipelines.yml
.tekton/*.yaml

Also locate supporting security configuration:

.github/CODEOWNERS
.github/dependabot.yml
.github/renovate.json
renovate.json
.snyk

Record all discovered files. If no CI/CD configurations are found, report that finding and halt.

---

Step 2: SLSA Build Level Determination

Read each pipeline configuration file and evaluate against SLSA v1.0 build track requirements.

SLSA Build L1 Checklist

• [ ] Build process is defined in version-controlled configuration (not ad-hoc scripts run manually).
• [ ] Build steps are scripted and reproducible.
• [ ] Build inputs (source repo, branch/ref) are documented in the configuration.

SLSA Build L2 Checklist

• [ ] Builds execute on a hosted/managed build platform (GitHub Actions, GitLab CI SaaS, Cloud Build, etc.).
• [ ] Build service generates signed provenance (e.g., using actions/attest-build-provenance, Sigstore, or in-toto).
• [ ] Provenance includes: builder identity, source reference, build configuration reference, and build timestamp.

SLSA Build L3 Checklist

• [ ] Build environments are ephemeral (fresh VM/container per build, no persistent state).
• [ ] Builds are isolated from one another (no shared writable caches across trust boundaries).
• [ ] Build configuration is fetched from a verified source (not from user-controlled inputs).
• [ ] Provenance is non-falsifiable (generated by the build platform, not user-defined steps).
• [ ] No use of self-hosted runners in security-critical build paths (unless hardened and ephemeral).

Determination logic: The repository achieves the highest level for which ALL checklist items are satisfied. Partial compliance at a given level means the repository remains at the level below.

---

Step 3: OWASP CICD-SEC Risk Evaluation

Evaluate each CICD-SEC control by inspecting pipeline configurations for the specific patterns described below.

CICD-SEC-1: Insufficient Flow Control Mechanisms

What to look for:

• Workflows that can push to protected branches without required reviews.
• Missing or insufficient branch protection rules (no required reviewers, no status checks).
• Workflows that auto-merge without approval gates.
• Deployment pipelines that lack manual approval steps for production.
• Missing environment protection rules on production/staging environments.

Grep patterns:

# GitHub Actions: check for direct pushes to main/master
on:
  push:
    branches: [main, master]

# Look for auto-merge actions
auto-merge
merge-method
enable-auto-merge

# Look for missing environment protection
environment:
  name: production
  # Should have: url, reviewers, wait-timer

Finding format: Report whether deployments to production require human approval, whether branch protection enforces review requirements, and whether any workflow can bypass flow controls.

---

CICD-SEC-2: Inadequate Identity and Access Management

What to look for:

• Overly permissive permissions blocks in GitHub Actions (or absence of permissions, which defaults to read-write).
• Use of permissions: write-all or top-level write permissions without scoping.
• Shared service accounts across environments.
• Missing CODEOWNERS file or broad ownership patterns.
• Workflows that do not pin the GITHUB_TOKEN to minimum required permissions.

Specific patterns in GitHub Actions:

# BAD: No permissions block (defaults to read-write for everything)
jobs:
  build:
    runs-on: ubuntu-latest

# BAD: Overly broad permissions
permissions: write-all

# GOOD: Least-privilege permissions
permissions:
  contents: read
  packages: write

Finding format: Report the effective permission model, whether least-privilege is enforced, and whether identity controls (CODEOWNERS, required reviewers) are in place.

---

CICD-SEC-3: Dependency Chain Abuse

What to look for:

• Missing dependency lock files (package-lock.json, poetry.lock, go.sum, Cargo.lock).
• No Dependabot or Renovate configuration for automated dependency updates.
• Use of floating version ranges in dependency manifests without lock files.
• Missing integrity checks (no npm ci vs npm install, no --frozen-lockfile).
• Dependency confusion risk: private package names that could be squatted on public registries.

Grep patterns:

# Check for proper locked installs
npm ci
yarn install --frozen-lockfile
pip install -r requirements.txt  # vs pip install with --require-hashes
poetry install --no-update

Finding format: Report dependency pinning status, lock file presence, automated update tooling, and whether install commands use locked/frozen modes.

---

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

What to look for -- this is a critical control:

• Direct PPE: Use of pull_request_target trigger with explicit checkout of PR head code. This is the single most dangerous GitHub Actions pattern because it runs PR code with write permissions and secret access.

# DANGEROUS: pull_request_target + checkout of PR code
on: pull_request_target
# ...
- uses: actions/checkout@v4
  with:
    ref: ${{ github.event.pull_request.head.sha }}

• Indirect PPE: Workflows that execute scripts, Makefiles, or config files that exist in the repository and can be modified by a pull request.
• Public fork access: Whether the repository allows workflows to run on pull requests from forks with access to secrets.
• Injection of untrusted input into shell commands:

# DANGEROUS: Direct interpolation of PR title into shell
- run: echo "PR title is ${{ github.event.pull_request.title }}"

# SAFE: Use environment variable
- run: echo "PR title is $PR_TITLE"
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}

Finding format: Report any pull_request_target usage, direct expression injection in run: steps, fork workflow policies, and whether PR code can influence privileged pipelines.

---

CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

What to look for:

• Workflows that have access to production secrets but run on non-production branches.
• Missing GitHub Actions environment protection rules.
• Secrets available to all workflows rather than scoped to specific environments.
• No conditional checks on branch or environment before accessing sensitive resources.
• Self-hosted runners shared across repositories with different trust levels.

Grep patterns:

# Check for environment-scoped deployments
environment:
  name: production

# Check for conditional secret access
if: github.ref == 'refs/heads/main'

# Check for runner isolation
runs-on: self-hosted  # Shared runners are a risk

Finding format: Report whether secrets and deployment capabilities are scoped to appropriate environments and branches, and whether runner infrastructure is properly segmented.

---

CICD-SEC-6: Insufficient Credential Hygiene

What to look for:

• Secrets printed to logs (via echo, debug mode, or error messages).
• Long-lived credentials (API keys, service account keys) instead of short-lived tokens (OIDC, workload identity federation).
• Secrets passed as command-line arguments (visible in process listings).
• Hardcoded credentials in pipeline configuration files.
• Missing secret rotation policies.

Grep patterns:

# BAD: Secret in command line argument
- run: deploy --token ${{ secrets.DEPLOY_TOKEN }}

# BAD: Printing secrets
- run: echo ${{ secrets.API_KEY }}

# GOOD: OIDC-based authentication
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/deploy
    aws-region: us-east-1

# GOOD: Using environment variables for secrets
- run: deploy-tool
  env:
    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Finding format: Report credential types in use (long-lived vs. short-lived), whether OIDC/workload identity is used where available, and any secrets exposed in logs or command arguments.

---

CICD-SEC-7: Insecure System Configuration

What to look for:

• Self-hosted runners without hardening (not ephemeral, shared across repos).
• Debug mode enabled in production workflows (ACTIONS_RUNNER_DEBUG, ACTIONS_STEP_DEBUG).
• Insecure runner images or outdated runner versions.
• Missing network controls on build infrastructure.
• Docker-in-Docker without appropriate security boundaries.

Grep patterns:

# Check for debug flags
ACTIONS_RUNNER_DEBUG: true
ACTIONS_STEP_DEBUG: true

# Check for privileged Docker operations
--privileged
docker.sock

Finding format: Report runner configuration security, debug settings, and any privileged operations in the build environment.

---

CICD-SEC-8: Ungoverned Usage of 3rd Party Services

What to look for:

• Third-party GitHub Actions referenced by mutable tag instead of pinned SHA.
• Use of unverified or low-reputation Actions from the marketplace.
• Third-party services with broad OAuth scopes on the repository.
• Missing allow-list for approved Actions (GitHub Actions allowed-actions policy).

Specific patterns:

# BAD: Mutable tag reference -- can be changed by the action author
- uses: some-org/some-action@v1
- uses: some-org/some-action@main

# GOOD: Pinned to immutable SHA
- uses: some-org/some-action@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2
# With comment for readability:
- uses: actions/checkout@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2 # v4.1.1

Finding format: List all third-party actions, their pinning status (SHA vs. tag vs. branch), and whether an organizational allow-list policy is in place.

---

CICD-SEC-9: Improper Artifact Integrity Validation

What to look for:

• Artifacts built and deployed without signing or attestation.
• Container images pushed without digest pinning or signing (cosign, Notary).
• No SBOM (Software Bill of Materials) generation in the build pipeline.
• Downloaded dependencies or tools without checksum verification.
• Missing provenance attestation (SLSA provenance, in-toto, Sigstore).

Grep patterns:

# Look for artifact signing
cosign sign
cosign attest
actions/attest-build-provenance
sigstore
in-toto

# Look for SBOM generation
syft
cyclonedx
spdx
sbom

# Look for digest pinning in container references
image: nginx@sha256:abcdef...  # GOOD
image: nginx:latest            # BAD

Finding format: Report whether artifacts are signed, whether provenance is generated, whether SBOMs are produced, and whether container images use digest pinning.

---

CICD-SEC-10: Insufficient Logging and Visibility

What to look for:

• Missing audit logging for pipeline modifications.
• No alerting on pipeline configuration changes.
• Lack of SIEM integration for CI/CD events.
• No monitoring of failed or anomalous pipeline runs.
• Missing retention policies for build logs.
• No tracking of who triggered deployments and when.

Grep patterns:

# Look for audit/logging integrations
audit
logging
siem
splunk
datadog
sentinel

# Look for notification/alerting on failures
slack
teams
pagerduty
on: workflow_run
  types: [completed]

Finding format: Report logging and monitoring coverage, whether pipeline changes are audited, and whether alerting exists for security-relevant events.

---

Step 4: Compile Assessment Report

Produce the final report using the following structure:

## Pipeline Security Assessment Report

### Repository
- Name: 
- Date: 
- Configurations reviewed: 

### SLSA Build Level Determination
- **Current Level:** SLSA Build L
- **Evidence:**
  - L1:  -- 
  - L2:  -- 
  - L3:  -- 
- **Gap to next level:** 

### OWASP CICD-SEC Findings

| Control ID | Risk Name | Severity | Status | Finding Summary |
|------------|-----------|----------|--------|-----------------|
| CICD-SEC-1 | Insufficient Flow Control | High/Med/Low | Pass/Fail/Partial |  |
| CICD-SEC-2 | Inadequate IAM | ... | ... | ... |
| ... | ... | ... | ... | ... |

### Detailed Findings

#### [CICD-SEC-X] 
- **Status:** Pass / Fail / Partial
- **Severity:** Critical / High / Medium / Low
- **File:** 
- **Line(s):** 
- **Description:** 
- **Remediation:** 

### Prioritized Remediation Plan

Before applying or proposing pipeline changes, classify each remediation path using [Security Fixer Policy](../../../docs/fixer-policy.md). Include the policy review gate, reviewer evidence, and rollback guidance in the remediation plan.

1. **[Critical]**  -- 
2. **[High]**  -- 
3. ...

### Summary
- Total controls evaluated: 10
- Passed: X
- Partial: X
- Failed: X
- Current SLSA Level: L
- Target SLSA Level: L

---

Output Format

The final deliverable is a structured assessment report as shown in Step 4 above. All findings must reference specific control IDs (CICD-SEC-1 through CICD-SEC-10) and SLSA build levels (L1, L2, L3). Every finding must include the file path and, wh

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: UnitOneAI
• Source: UnitOneAI/SecuritySkills
• License: MIT
• Homepage: https://www.unitone.ai

Install and usage instructions live in the source repository linked above.