This article was co-written by Mikey Strauss and Viktor Kartashov.
Turn OWASP Top 10 risks into automated, auditable controls
In modern DevOps environments, CI/CD pipelines are the backbone of software delivery. But with great speed comes great exposure. As organizations accelerate releases, attackers are increasingly targeting insecure pipelines to inject malicious code, exfiltrate secrets, or compromise supply chain integrity.
To address this, the OWASP Top 10 CI/CD Security Risks framework highlights the most common and critical weaknesses across development pipelines. At Scribe Security, we’ve adopted this framework to help organizations embed CI/CD security directly into their workflows through signed evidence, initiative-based enforcement, and policy-as-code.
Why the OWASP CI/CD Risks Matter
Traditional security tools struggle to keep up with the velocity of modern pipelines. Without automated enforcement and visibility, common issues slip through:
❌ Hardcoded secrets in pipeline configs
❌ Tampered build artifacts with no provenance
❌ Insecure base images pulled from public registries
❌ Admin-level access with no 2FA or review controls
The OWASP framework formalizes these risks, providing a shared language and structure for remediation. At Scribe, we use it to define initiatives that automatically verify the security posture of your CI/CD pipelines , without requiring major changes to your build process.
Security Starts with Signed Evidence
To validate that your pipeline is secure, we collect and cryptographically sign evidence such as:
- Git SBOM & Image SBOM
Generated using scribe-security/action-bom, these provide full visibility into what’s in your code and containers. - SLSA Provenance
Captures how, where, and by whom your artifacts were built. - GitHub org & repo scans
Run via action-platforms to check for secrets, config drift, and misconfigured access.
All of this evidence is signed , ensuring integrity and traceability , and mapped to specific products and versions for lifecycle tracking.
📌 We covered this evidence-driven model in our earlier posts on SLSA compliance and SP 800–190 enforcement.
🔒 Enforcing OWASP Controls via Policy-as-Code
At Scribe, we map the OWASP Top 10 CI/CD risks into a policy-as-code initiative that runs directly in your CI pipeline. Each risk is represented as a configurable rule defined in a local owasp-top10-cicd.yaml file. These rules are evaluated automatically during the verification phase, providing actionable feedback and remediation guidance.
Here are some of the key controls included:
- CICD-SEC-1 : Enforce branch protection rules
Prevent unauthorized code changes by restricting direct pushes to critical branches like main. - CICD-SEC-2 : Identity and access management controls
Require multi-factor authentication (MFA) and limit administrative privileges in your Git provider. - CICD-SEC-3 : Dependency verification
Ensure all base images and third-party dependencies are pulled from approved and trusted registries. - CICD-SEC-4 : Poisoned pipeline execution prevention
Restrict who can modify CI/CD scripts to avoid introducing malicious logic into your workflows. - CICD-SEC-6 : Credential hygiene enforcement
Scan for hardcoded secrets, expired tokens, or leaked credentials — then flag them before release.
Each of these controls can be customized based on your organization’s risk tolerance, environment, or compliance requirements. Because it’s defined as code, your security posture becomes auditable, version-controlled, and enforceable by automation.
✅ Pro tip: You can include or exclude specific rules, set severity thresholds, and even tailor remediation advice — directly in your initiative configuration file.
By bringing these controls into your pipeline, you move from ad-hoc reviews to automated, verifiable security enforcement – a critical step in protecting your software supply chain.
GitHub Actions: Real-World CI/CD Integration
Here’s an example workflow using Scribe’s actions to build, collect evidence, scan the org, and verify compliance against the OWASP Top 10 CI/CD framework:
name: OWASP CI/CD Secure Build
on:
push:
branches:
- main
env:
PRODUCT_NAME: my-app
PRODUCT_VERSION: v1.0
jobs:
build:
runs-on: ubuntu-latest
outputs:
image-name: ${{ steps.meta.outputs.image }}
steps:
- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@v3
- run: echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login ${{ secrets.REGISTRY_URL }} -u ${{ secrets.REGISTRY_USER }} --password-stdin
- id: meta
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }}
- uses: scribe-security/action-bom@master
with:
target: 'git:.'
product-key: ${{ env.PRODUCT_NAME }}
product-version: ${{ env.PRODUCT_VERSION }}
format: attest
- uses: scribe-security/action-bom@master
with:
target: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }}
base-image: Dockerfile
product-key: ${{ env.PRODUCT_NAME }}
product-version: ${{ env.PRODUCT_VERSION }}
format: attest
- uses: scribe-security/action-verify@master
with:
target: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }}
product-key: ${{ env.PRODUCT_NAME }}
product-version: ${{ env.PRODUCT_VERSION }}
initiative: slsa.l2@v2
provenance: true
format: attest
beautify: true
org-scan:
runs-on: ubuntu-latest
steps:
- uses: scribe-security/action-platforms@master
with:
command: discover
platform: github
sign: true
attest-default: sigstore
args: >-
--token ${{ secrets.GITHUB_PAT }}
--organization.mapping ${{ github.repository_owner }}::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }}
--repository.mapping $(basename ${{ github.repository }})::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }}
--scope.workflow.past_days 1
--scope.branch ${{ github.ref_name }}
--hook trivy_iac_and_secrets_sarif
verify:
runs-on: ubuntu-latest
needs: [build, org-scan]
steps:
- uses: scribe-security/action-verify@master
with:
initiative: owasp-top10-cicd.yaml
product-key: ${{ env.PRODUCT_NAME }}
product-version: ${{ env.PRODUCT_VERSION }}
format: attest
all-evidence: true
beautify: true
Continuous Compliance in Action
This workflow results in a verifiable attestation showing which OWASP risks your pipeline passes or fails. Each violation is traceable to specific evidence ( SBOMs, workflow logs, and org configs ), allowing teams to fix issues quickly and confidently.
Want to see what this looks like in the real world? Here’s an example scan result from one of our internal pipelines:
Summary view
Violation view
Evidence view
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
