# Pipeline Security > > - **Type:** Skill - **Install:** `agentstack add skill-unitoneai-securityskills-pipeline-security` - **Verified:** Pending review - **Seller:** [UnitOneAI](https://agentstack.voostack.com/s/unitoneai) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [UnitOneAI](https://github.com/UnitOneAI) - **Source:** https://github.com/UnitOneAI/SecuritySkills/tree/main/skills/devsecops/pipeline-security - **Website:** https://www.unitone.ai ## Install ```sh agentstack add skill-unitoneai-securityskills-pipeline-security ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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:** ```yaml # 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. ```yaml # 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: ```yaml # 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:** ```yaml # 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:** ```yaml # 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:** ```yaml # 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:** ```yaml # 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:** ```yaml # 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:** ```yaml # 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](https://github.com/UnitOneAI) - **Source:** [UnitOneAI/SecuritySkills](https://github.com/UnitOneAI/SecuritySkills) - **License:** MIT - **Homepage:** https://www.unitone.ai Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: flagged — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-unitoneai-securityskills-pipeline-security - Seller: https://agentstack.voostack.com/s/unitoneai - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.