Framework

OWASP Top 10 CI/CD Security Risks
the per-class risk catalogue for the pipeline

The OWASP Top 10 CI/CD Security Risks (the OWASP CI/CD Top 10) is the open risk-class catalogue for the CI/CD pipeline itself, maintained by the OWASP CI/CD Security project. The ten CICD-SEC categories name the pipeline-specific risk classes that show up across pipeline-as-code definitions, runner infrastructure, package registries, identity and access management, and observability layers. SecPortal operates a CI/CD Top 10 engagement as one structured record across the in-scope pipeline platforms, repositories, runner environments, and third-party action allowlists.

Get Started Free

No credit card required. Free plan available forever.

OWASP Top 10 CI/CD Security Risks: a pipeline-class risk catalogue, not a maturity score

The OWASP Top 10 CI/CD Security Risks is the open risk-class catalogue for the CI/CD pipeline itself, maintained by the OWASP CI/CD Security project on GitHub. Where OWASP SAMM measures the AppSec function at the organisational layer and OWASP DSOMM measures the pipeline-and-runtime maturity on a four-level scale, the OWASP CI/CD Top 10 names the ten pipeline-specific risk classes that show up across the pipeline platform, the pipeline-as-code definitions, the runner infrastructure, the package registries, the identity and access management surface, and the observability layer. The catalogue is the per-risk-class verification target the engineering team builds against and the auditor reads against. SecPortal operates a CI/CD Top 10 engagement as one structured record across the in-scope pipeline platforms, repositories, and runner environments.

For internal AppSec teams running a pipeline-security verification programme, product security teams owning a shippable product surface, DevSecOps and platform engineering teams operating the pipeline, security engineering and security architecture teams modelling the pipeline threat surface, GRC and compliance teams mapping pipeline verification to NIST SSDF, ISO 27001 Annex A, SOC 2, PCI DSS, NIST CSF 2.0, DORA, and NIS2, and CISOs carrying the audit-committee and board risk-committee read on the pipeline surface, the OWASP CI/CD Top 10 is the per-risk-class evidence artefact the pipeline verification claim reads through. The value is the risk-class traceability that turns pipeline security from an ad-hoc review into a durable per-class operating record.

This page covers what each CICD-SEC risk class names, how the risk class shows up across the major pipeline platforms (GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, CircleCI, Jenkins, Azure DevOps, Buildkite, ArgoCD, Tekton), where the OWASP CI/CD Top 10 sits next to SAMM, DSOMM, NIST SSDF, SLSA, and CISA Secure by Design, the buyer and operator read for AppSec, DevSecOps, product security, security engineering, GRC, and CISO functions, the framework crosswalk against ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, CIS Controls, DORA, and NIS2, and how SecPortal operates a CI/CD Top 10 engagement as one structured record.

The ten CICD-SEC risk classes

The catalogue names ten risk classes. Each class is a category of pipeline weakness with a named identifier (CICD-SEC-1 to CICD-SEC-10), an operational description, and a typical set of evidence patterns. The risk classes are not severity-ranked; they are category-ranked against the operating shape of a typical CI/CD pipeline, and a single finding can map to more than one class when the same weakness has multiple expressions.

CICD-SEC-1Insufficient Flow Control Mechanisms

A pipeline that allows a single contributor to push code, define the pipeline that builds that code, approve the build, and ship the artefact to production with no separation-of-duties gate. The risk shows up as missing required reviewers on protected branches, missing approval gates between build and deploy, missing branch protection on the pipeline definition repository itself, and missing controls over who can edit the pipeline configuration.

CICD-SEC-2Inadequate Identity and Access Management

A pipeline where service accounts and human identities are over-permissioned, long-lived, or share credentials across environments. The risk shows up as long-lived personal access tokens with admin scopes, build-runner service principals with production write rights, shared bot accounts that nobody owns, and inherited group memberships that grant pipeline write access to former contributors.

CICD-SEC-3Dependency Chain Abuse

A pipeline that pulls dependencies in a way that lets an attacker substitute a malicious package for a legitimate one. The risk shows up as dependency confusion (private package names resolved against public registries first), typosquatting (look-alike package names), brand-jacking (stale owner accounts on public registries), and unverified package signatures during install.

CICD-SEC-4Poisoned Pipeline Execution (PPE)

A pipeline whose definition is influenced by attacker-controlled input that triggers a build with elevated permissions. The risk shows up as pipeline-as-code stored next to application code (so a malicious PR rewrites the pipeline that runs against it), pull-request-triggered builds with secret access, untrusted-runner execution against trusted runners, and lack of validation between the pipeline source and the pipeline executor.

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

A pipeline where runtime steps run with more privilege than the work they do requires. The risk shows up as runner agents with broad cloud roles attached, build steps with secrets the step does not need, ephemeral runners with persistent credentials, and downstream pipelines inheriting upstream secrets they do not need to consume.

CICD-SEC-6Insufficient Credential Hygiene

A pipeline that handles secrets in a way that lets them leak, persist beyond use, or escape the security boundary. The risk shows up as secrets in source code, secrets in environment variables logged to build output, secrets in container layers, secrets in pipeline definition files, secrets reused across environments, and secrets without rotation cadence.

CICD-SEC-7Insecure System Configuration

A pipeline where the runner host, the build agent, the build tooling, or the package proxy is misconfigured in a way that weakens the trust boundary. The risk shows up as outdated runner images, build runners on the public internet without network segmentation, missing build runner hardening (no read-only filesystem, no resource limits, no logging), and missing isolation between concurrent jobs.

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

A pipeline that integrates third-party actions, plugins, or services without a vetting record. The risk shows up as pinned-by-tag actions that resolve to mutable references, plugins from unverified publishers, marketplace integrations that read repository secrets, and SaaS callouts that exfiltrate build output through analytics or telemetry channels.

CICD-SEC-9Improper Artefact Integrity Validation

A pipeline that produces or consumes build artefacts without a verifiable integrity signal. The risk shows up as unsigned build artefacts, unsigned container images, missing SBOM attachment per release, missing provenance attestation against SLSA expectations, and downstream consumers that accept artefacts without verifying signatures.

CICD-SEC-10Insufficient Logging and Visibility

A pipeline whose security-relevant events are not logged, not retained, or not correlatable with the artefacts they produced. The risk shows up as missing audit trail on pipeline configuration edits, missing log retention on runner agents, missing correlation between a build event and the artefact it produced, missing log integrity, and missing alerting on anomalous pipeline behaviour.

For the workspace-side mechanics that hold each risk-class finding to a real engagement record, see the engagement management feature, the findings management feature, the code scanning feature, and the repository connections feature, which together carry the structured record each CICD-SEC finding pairs against.

Recurring failure modes that weaken a CI/CD Top 10 record

Programmes that struggle with the OWASP CI/CD Top 10 typically hit a small set of recurring failure modes. Naming the failure modes up front lets the engagement design controls to avoid them rather than discovering them during the report review or the audit fieldwork.

Treating the CI/CD Top 10 as a developer checklist rather than a programme-level risk catalogue. The list reads as ten categories of pipeline risk that show up across pipeline-as-code definitions, runner infrastructure, registry layers, identity and access management, and observability. A programme that delegates the entire list to per-team developer reviews and never aggregates the gaps at the platform level discovers the same risk class in a dozen places at fieldwork rather than once at the platform layer.

Reading CICD-SEC-4 (PPE) as a GitHub Actions issue only. Poisoned Pipeline Execution applies to any pipeline platform where the pipeline definition is co-located with application code (GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, CircleCI, Jenkins multibranch, Azure DevOps YAML, Buildkite). The risk class is platform-agnostic; programmes that solve it only on the most-visible platform leave the same class open on the rest.

Treating dependency chain abuse (CICD-SEC-3) as solved by the package scanner alone. Dependency confusion, typosquatting, and brand-jacking exploit the install-time resolution behaviour and the trust chain on the public registry. Package scanning detects known-vulnerable dependencies in the bill of materials after install; it does not prevent install-time substitution against a permissive resolution policy. The risk class requires registry policy controls (scoped private registry, pinned hashes, internal mirror with allowlist), not only post-install scanning.

Treating SLSA, SBOM, and provenance attestation as separate compliance threads. The CICD-SEC-9 risk class (artefact integrity validation) is what they pair against operationally. A programme that maintains a separate SBOM workflow, a separate signing workflow, and a separate provenance attestation workflow without anchoring them against the CICD-SEC-9 risk class rebuilds the same integrity record three times.

Letting third-party action governance (CICD-SEC-8) live in the action marketplace UI alone. Most pipeline platforms let an organisation pin actions, restrict actions to verified publishers, mirror actions to an internal registry, or block actions by name. Programmes that rely on marketplace defaults without the named restriction inherit the supply chain of every action a developer ever pinned by tag.

Skipping the pipeline configuration history (CICD-SEC-10) because the build logs already exist. Build logs record what the build did; the pipeline configuration history records who changed the pipeline-as-code over time and who approved the change. A programme that retains build logs without the pipeline configuration history loses the per-edit attribution that the post-incident review reads against.

Treating ephemeral runners as a substitute for least-privilege (CICD-SEC-5). Ephemeral runners reset their filesystem and process state per job, which is a useful blast-radius control. They do not, on their own, scope the credentials the job inherits. A programme that adopts ephemeral runners without scoping the per-job credentials still hands over excess privilege at the start of each job.

Conflating secret scanning with credential hygiene (CICD-SEC-6). Secret scanning detects secrets that have already been committed; credential hygiene prevents the commit, prevents the use of long-lived credentials, enforces rotation cadence, and scopes secrets per environment. A programme that runs secret scanning alone produces a steady backlog of credentials to rotate without addressing the upstream behaviour that produced them.

How the CI/CD Top 10 sits next to SAMM, DSOMM, SSDF, SLSA, and Secure by Design

The OWASP CI/CD Top 10 is rarely used in isolation. It is the per-risk-class catalogue that the wider AppSec maturity models, the regulator-facing practice catalogues, the supply chain integrity frameworks, and the default-secure pledges read into. The contrast below is a working view, not a buyer comparison: the practitioner question is which artefacts to pair the CI/CD Top 10 with, not which to pick instead of it.

OWASP CI/CD Top 10 vs OWASP SAMM

OWASP SAMM is a maturity model that measures the AppSec function at the organisational layer (Governance, Design, Implementation, Verification, Operations) on a three-level scale. The OWASP CI/CD Top 10 is a risk catalogue that names ten pipeline-class risks (flow control, IAM, dependency chain abuse, PPE, PBAC, credential hygiene, system configuration, third-party services, artefact integrity, logging). SAMM tells the programme what good looks like at the function level; CI/CD Top 10 tells the programme which pipeline-specific risk classes the engineering team has to verify against. Most mature programmes operate the two in parallel: SAMM as the maturity scorecard, CI/CD Top 10 as the risk catalogue the Implementation and Verification functions read against.

OWASP CI/CD Top 10 vs OWASP DSOMM

OWASP DSOMM is the DevSecOps Maturity Model that scores pipeline and runtime maturity across four dimensions (Build and Deployment, Culture and Organization, Implementation, Information Gathering) on a four-level scale. The OWASP CI/CD Top 10 is the pipeline-specific risk class catalogue underneath the Build and Deployment dimension of DSOMM. DSOMM scores how mature the practices are; the CI/CD Top 10 names which risks the practices have to mitigate. The two read together: DSOMM as the maturity ladder for the pipeline-and-runtime, CI/CD Top 10 as the risk-class evidence checklist for the pipeline tier.

OWASP CI/CD Top 10 vs NIST SSDF

NIST SSDF (SP 800-218) is the secure-development practices framework with 42 named tasks across PO, PS, PW, and RV groups. The OWASP CI/CD Top 10 is the pipeline-class risk catalogue the SSDF practices read against. SSDF PS.1 (Protect software) and PS.2 (Verify software integrity) pair against CICD-SEC-9 (artefact integrity validation). SSDF PW.4 (Reuse existing secure software) and PW.6 (Configure compilation) pair against CICD-SEC-3 (dependency chain abuse). SSDF RV.1 to RV.3 (Respond to vulnerabilities) pair against CICD-SEC-6 (credential hygiene) and CICD-SEC-9. Federal acquisition programmes typically pair the two: SSDF as the practice catalogue the CISA Secure Software Development Attestation reads against, CI/CD Top 10 as the risk-class evidence the SSDF practices produce.

OWASP CI/CD Top 10 vs SLSA

SLSA (Supply chain Levels for Software Artefacts) is a four-level framework for supply chain integrity built around source, build, and dependency requirements at Level 1 (build process documented) through Level 4 (hermetic and reproducible builds with two-person review). The OWASP CI/CD Top 10 is the broader pipeline-class risk catalogue that includes SLSA-adjacent risk classes (CICD-SEC-3 dependency chain, CICD-SEC-4 PPE, CICD-SEC-9 artefact integrity) plus risk classes SLSA does not directly address (CICD-SEC-2 IAM, CICD-SEC-5 PBAC, CICD-SEC-7 system configuration, CICD-SEC-10 logging). Programmes typically claim a SLSA level on the build provenance side and use the CI/CD Top 10 to cover the broader pipeline risk surface.

OWASP CI/CD Top 10 vs CISA Secure by Design

CISA Secure by Design is the voluntary pledge framework for software producers committing to default-secure software products, with goals like multi-factor authentication, default-strong configuration, secure-by-design hardware, vulnerability disclosure programmes, and transparent reporting. The OWASP CI/CD Top 10 is the technical risk catalogue the Secure by Design commitments operate through. A producer that signs the Secure by Design pledge reads the CI/CD Top 10 as the per-risk-class evidence catalogue for the pipeline that ships the default-secure product.

OWASP CI/CD Top 10 vs scanner output dashboards

CI/CD security scanner dashboards (GitHub Code Scanning, Stepsecurity Harden-Runner, Snyk CI/CD, Wiz Code, Chainguard Enforce, Sysdig pipeline scanning, Frogbot, Anchore Enforce) are useful as scanner-source views of finding data, but they are not risk-class catalogues. They produce detections; the OWASP CI/CD Top 10 produces a structured taxonomy that scanner detections, manual review findings, and policy-as-code violations all map into for one comparable per-risk-class record.

Buyers procuring a CI/CD security engagement should pair the CI/CD Top 10 risk-class record with OWASP SAMM as the organisational maturity model the AppSec function is built against, with OWASP DSOMM as the pipeline-and-runtime maturity model the platform team scores against, with NIST SSDF as the regulator-facing practice catalogue the federal acquisition path reads against, and with CISA Secure by Design as the default-secure software pledge the producer commits to.

Adjacent OWASP, CISA, NIST, and EU references

The CI/CD Top 10 reads alongside several OWASP, NIST, CISA, and EU references. Each one covers a different slice of the pipeline operating model; the CI/CD Top 10 is the per-risk-class evidence artefact that converts the standards and regulations into a verifiable record.

OWASP CI/CD Top 10 and the OWASP CI/CD Security project

The OWASP CI/CD Top 10 is the headline deliverable of the OWASP CI/CD Security project, alongside detailed per-category guidance and reference attack scenarios. The project is maintained on GitHub by the OWASP community; engagements cite the project version and the risk-class identifiers (CICD-SEC-1 to CICD-SEC-10) together so the verification claim is reproducible against a versioned project state.

OWASP CI/CD Top 10 and SLSA

SLSA (Supply chain Levels for Software Artefacts) defines a four-level framework for supply chain integrity (source, build, and dependency requirements). The OWASP CI/CD Top 10 risk classes CICD-SEC-3 (dependency chain abuse), CICD-SEC-4 (poisoned pipeline execution), and CICD-SEC-9 (improper artefact integrity validation) read directly into SLSA Level claims. Programmes pursuing a SLSA Level 3 or Level 4 claim pair the SLSA level claim with the CI/CD Top 10 risk-class evidence so the supply-chain claim has both a level and a per-risk-class verification record.

OWASP CI/CD Top 10 and Sigstore, Cosign, SLSA provenance

Sigstore (the open-source signing infrastructure), Cosign (the container signing CLI), and SLSA provenance attestation are operating tools that produce the artefact-integrity evidence CICD-SEC-9 expects. The CI/CD Top 10 names the risk class; the tools produce the cryptographic record the verification reads against. SecPortal captures the signing identity, the signing timestamp, the artefact hash, and the provenance attestation reference on the engagement record as evidence pointers, with the artefacts themselves living in the registry of record.

OWASP CI/CD Top 10 and CycloneDX, SPDX, and SBOM regulation

CycloneDX (the OWASP SBOM standard) and SPDX (the ISO/IEC 5962 SBOM standard) are the SBOM formats US Executive Order 14028, the CISA SSDA, and the EU Cyber Resilience Act read against. The CI/CD Top 10 CICD-SEC-3 (dependency chain abuse) and CICD-SEC-9 (artefact integrity validation) categories read against the SBOM workflow as the per-risk-class evidence layer. SecPortal captures the SBOM reference, the SBOM format, the SBOM publication channel, and the SBOM consumer trust expectations on the engagement record as document-management artefacts.

How auditors and regulators read a CI/CD Top 10 citation

The OWASP CI/CD Top 10 is not itself a regulator-issued standard; it is the open pipeline-security risk catalogue that regulator-issued standards, audit frameworks, and procurement processes accept as the per-risk-class evidence record for the pipeline. The list below maps the CI/CD Top 10 catalogue to the regulator-side and audit-side references that read against it; the same engagement record satisfies several reads at once when the per-risk-class coverage is honest.

NIST SSDF (SP 800-218) practices PS.1 (Protect all forms of code), PS.2 (Verify software integrity), PS.3 (Verify intentional behaviour), PW.4 (Reuse existing secure software), PW.5 (Create source code with secure practices), PW.6 (Configure compilation, interpreter, and build processes), PW.7 (Review and analyse human-readable code), PW.8 (Test executable code), RV.1 (Identify and confirm vulnerabilities), RV.2 (Assess and remediate vulnerabilities), and RV.3 (Analyse vulnerabilities to root cause): the CI/CD Top 10 risk class catalogue is the per-risk-class evidence the SSDF practices produce in operating systems where the pipeline is the production path.
CISA Secure Software Development Attestation (SSDA): the SSDA reads against a subset of SSDF practices, and the CI/CD Top 10 risk class catalogue is the per-risk-class technical evidence the attestation rests on for the pipeline that ships the attested software.
CISA Secure by Design pledge: the voluntary commitments around default-secure configuration, vulnerability disclosure, and transparent reporting read against the CI/CD Top 10 risk class catalogue for the pipeline that ships the default-secure product.
EU Cyber Resilience Act (CRA) Article 13 (Essential cybersecurity requirements) and Annex I (Cybersecurity requirements relating to the properties of products with digital elements): the CI/CD Top 10 risk class catalogue is the technical-evidence layer the CRA conformity assessment reads against on the pipeline that produces the CE-marked product.
ISO 27001:2022 Annex A.5.23 (Information security for use of cloud services), A.8.8 (Management of technical vulnerabilities), A.8.25 (Secure development life cycle), A.8.27 (Secure system architecture and engineering principles), A.8.28 (Secure coding), A.8.29 (Security testing in development and acceptance), A.8.31 (Separation of development, test and production environments), and A.8.33 (Test information): the CI/CD Top 10 catalogue supplies the per-risk-class verification record auditors read against the ISMS-in-scope pipeline.
SOC 2 Trust Services Criteria CC6.1 (Logical and physical access), CC6.6 (Logical access security measures), CC7.1 (Detection and monitoring), CC7.2 (Incident response evaluation), CC8.1 (Change management), and CC8.2 (Change management documentation): the CI/CD Top 10 catalogue maps to the change-management and access-control criteria the SOC 2 auditor reads on the pipeline.
PCI DSS Requirement 6.2 (Custom and bespoke software developed securely), Requirement 6.3 (Security vulnerabilities identified and addressed), Requirement 6.4 (Public-facing web applications protected against attacks), Requirement 7 (Access to system components restricted to authorised users), Requirement 8 (Identity and authentication), and Requirement 10 (Log and monitor all access to system components and cardholder data): the CI/CD Top 10 catalogue supplies the per-risk-class evidence the QSA reads on the pipeline that builds payment-handling software.
NIST SP 800-53 Rev 5 SA-3 (System development life cycle), SA-10 (Developer configuration management), SA-11 (Developer testing and evaluation), SA-15 (Development process, standards, and tools), CM-3 (Configuration change control), CM-7 (Least functionality), and SI-7 (Software, firmware, and information integrity): the CI/CD Top 10 catalogue is the per-risk-class evidence the assessor reads against the System and Communications Protection family for the pipeline.
NIST CSF 2.0 PR.PS (Platform security), PR.AA (Identity management, authentication, and access control), PR.IR (Technology infrastructure resilience), DE.CM (Continuous monitoring), and RS.AN (Incident analysis): the CI/CD Top 10 catalogue supplies the pipeline-side row record the framework outcomes are evidenced against.
CIS Controls v8.1 Control 16 (Application Software Security) Safeguards 16.1 through 16.14, Control 4 (Secure Configuration of Enterprise Assets and Software), Control 6 (Access Control Management), and Control 8 (Audit Log Management): the CI/CD Top 10 catalogue supplies the per-risk-class verification evidence the Control 16 safeguards expect.
DORA Article 9 (ICT security policies), Article 13 (Learning and evolving), and Article 17 (ICT-related incident management): the CI/CD Top 10 catalogue is the per-risk-class evidence financial-entity supervisory authorities read against the pipeline supporting in-scope ICT services.
NIS2 Article 21 (Cybersecurity risk-management measures) paragraph 2(e) (security in network and information systems acquisition, development and maintenance): the CI/CD Top 10 catalogue supplies the per-risk-class evidence the competent authority reads against essential and important entity pipelines.

For the broader audit-evidence story (how the same finding can satisfy multiple regulator reads without rebuilding the evidence pack per audit), see the vulnerability evidence reuse across audits research and the multi-framework control crosswalk economics research.

The CI/CD Top 10 read across pipeline-shipping functions

The OWASP CI/CD Top 10 is a cross-functional artefact. The same risk-class record reads differently depending on which function holds the work. Programmes that run pipeline verification as an engineering exercise alone lose the audit depth the catalogue supports; programmes that run it as a procurement exercise alone lose the engineering depth. The named functions below own different parts of the same risk-class record.

AppSec teams running CI/CD security verification internally

AppSec teams use the OWASP CI/CD Top 10 as the structured catalogue that converts ad-hoc pipeline-security review into a per-risk-class verification engagement. The team owns the engagement workspace, the in-scope pipeline platforms, the in-scope repository set, the in-scope runner environments, and the in-scope third-party action allowlist. The work product per risk class is a verification claim with named evidence: which CICD-SEC categories were tested, what was found, what was remediated, and what is deferred with a named approver and expiry.

DevSecOps and platform engineering teams operating the pipeline

DevSecOps and platform engineering teams use the OWASP CI/CD Top 10 as the risk catalogue the pipeline contracts read against. The team translates each CICD-SEC risk class into named platform controls: branch protection, required reviewers, scoped service principals, ephemeral runners with per-job credentials, registry allowlists, action allowlists, secret rotation cadences, signed artefacts, provenance attestation, structured pipeline event logging. The CI/CD Top 10 becomes the input to the platform roadmap.

Product security teams owning shippable product surfaces

Product security teams use the OWASP CI/CD Top 10 as the per-release pipeline verification gate: which CICD-SEC categories were exercised on the pipeline that built this release, which were deferred with named compensating controls, and which were excluded from scope. The verification claim is part of the release record so a release does not silently inherit unresolved pipeline-side risk.

Security engineering and security architecture teams

Security engineering and security architecture teams use the OWASP CI/CD Top 10 as the pipeline threat model anchor. The catalogue replaces ad-hoc pipeline threat modelling sessions with a structured ten-category surface, and the per-risk-class verification record replaces tabletop-style assessment summaries with a per-category evidence trail the auditor can read.

GRC and compliance teams reading pipeline evidence

GRC and compliance teams use the OWASP CI/CD Top 10 as the per-risk-class evidence artefact that maps to NIST SSDF, ISO 27001 Annex A.8.25 to A.8.33, SOC 2 CC6, CC7, CC8, PCI DSS Requirement 6 and 10, NIST SP 800-53 SA and CM families, CIS Controls v8.1 Control 16, DORA Article 9 and Article 17, and NIS2 Article 21(2)(e). The team consumes the per-risk-class record on the workspace rather than rebuilding the evidence pack per audit.

CISOs and security leaders reporting on pipeline posture

CISOs and security leaders use the OWASP CI/CD Top 10 as the durable, version-anchored pipeline evidence layer the audit-committee and board risk-committee reads run against. The leader-side question is no longer how many vulnerabilities were found in code, it is which CICD-SEC risk classes are verified at which level on which pipeline platforms across the engineering estate, which are deferred with named compensating control, and which are excluded from scope and why. The catalogue gives the answer a structured shape.

The persona-specific entry points are SecPortal for AppSec teams, SecPortal for DevSecOps teams, SecPortal for product security teams, SecPortal for platform engineering teams, SecPortal for security engineering teams, SecPortal for GRC and compliance teams, and SecPortal for CISOs. Each anchors a different view of the same CI/CD Top 10 engagement record.

Running a CI/CD Top 10 engagement on SecPortal

SecPortal is the operating record for a CI/CD Top 10 engagement. The engagement record captures the in-scope pipeline platforms, the in-scope repository set, the in-scope runner environments, the in-scope package registries, the in-scope third-party actions or plugins, the testing window, and the retest scope. The findings record carries each CICD-SEC finding with the risk-class identifier, the CVSS 3.1 vector, the named pipeline platform, the named repository, the named runner environment, the evidence the verification produced, and the framework crosswalk against NIST SSDF, ISO 27001 Annex A, SOC 2 Trust Services Criteria, and PCI DSS, so the per-risk-class engagement record reads against the same workspace state the verification report reads against. The platform alignment below maps each verified SecPortal capability to the CICD-SEC risk class or evidence type it supports so the engagement is held on one operating record rather than reconstructed at report time.

Engagement management captures a CI/CD security engagement as a structured record: the in-scope pipeline platforms (GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, CircleCI, Jenkins, Azure DevOps, Buildkite, ArgoCD, Tekton, others), the in-scope repository set, the runner environments, the package registries in scope, the third-party actions or plugins in scope, the testing window, and the agreed retest scope, so each risk class read sits on the same engagement scaffold rather than a contract attachment.
Findings management stores each CICD-SEC finding with a CVSS 3.1 vector, severity, evidence inline (the pipeline configuration excerpt, the runner role JSON, the secret store inventory, the action pin reference, the signed artefact attestation example or missing-attestation evidence, the log retention configuration), owner, a free-text mapping field for the CICD-SEC identifier the finding evidences, and an OWASP CI/CD Top 10 risk category tag so the verification report and the per-risk-class record stay paired.
Code scanning runs SAST and SCA against connected GitHub, GitLab, and Bitbucket repositories through OAuth, with Semgrep rules that can be extended to flag pipeline-as-code patterns (untrusted-input PR triggers, branch-targeted secret access, plugin-by-tag references) directly inside the pipeline definition files themselves so the CICD-SEC-3, CICD-SEC-4, and CICD-SEC-8 risk classes have code-side evidence on the same engagement record.
Repository connections under OAuth bind each scan back to a specific commit on a specific branch on a specific repository, so the CICD-SEC-1 (flow control), CICD-SEC-4 (PPE), and CICD-SEC-10 (logging and visibility) evidence trail points at the live pipeline-as-code state rather than a frozen export.
Bulk finding import accepts CI/CD security scanner output (Stepsecurity Harden-Runner detections, Chainguard Enforce reports, Wiz Code findings, Snyk CI/CD findings, Sysdig pipeline findings, GitHub Actions security advisories, GitLab CI/CD insights, Frogbot findings, Anchore Enforce reports, Cosign verification failures) as CSV intake with column mapping, so external-scanner-produced rows land on the engagement ledger and pair to the CICD-SEC category the finding evidences, rather than living in a separate working file.
AI-assisted reports compose the executive summary, the technical body, the per-risk-class coverage statement, and the remediation roadmap from the live engagement, findings, and per-CICD-SEC tags, citing the named pipeline platform, the named repository, the named runner environment, and the named third-party action where each finding was observed rather than starting from a blank template.
Document management holds the externally produced artefacts the platform does not generate inline: the pipeline policy document, the runner hardening baseline, the scoped service-account inventory, the third-party action allowlist, the registry policy document, the SBOM and provenance attestation samples, the rotation cadence document, and the log retention and integrity policy, with version history per artefact and named custodian per file, so the risk-class evidence pointers land on durable storage rather than email attachments.
Compliance tracking lets one CI/CD security engagement feed framework mappings to NIST SSDF (PS.1 Protect Software, PS.2 Verify Software Integrity, PS.3 Verify Intentional Behaviour, PW.4 Reuse Existing Software, PW.5 Create Source Code with Secure Practices, PW.6 Configure Compilation, PW.7 Review Code, PW.8 Test Executable Code, RV.1 Identify and Confirm Vulnerabilities, RV.2 Assess and Remediate, RV.3 Analyse Vulnerabilities), CISA Secure by Design, EU Cyber Resilience Act, OWASP SAMM Implementation business function, OWASP DSOMM Build and Deployment dimension, ISO 27001 Annex A.5.23 (Information security for use of cloud services), A.8.8 (Management of technical vulnerabilities), A.8.25 (Secure development life cycle), A.8.27 (Secure system architecture and engineering principles), A.8.28 (Secure coding), A.8.29 (Security testing in development and acceptance), A.8.31 (Separation of development, test and production environments), and A.8.33 (Test information), SOC 2 Trust Services Criteria CC6.1 (Logical and physical access), CC7.1 (Detection of malicious software and unauthorised actions), CC7.2 (Incident response evaluation), CC8.1 (Change management), and CC8.2 (Change management documentation), PCI DSS Requirement 6.2 (Custom and bespoke software developed securely) and Requirement 6.3 (Security vulnerabilities identified and addressed), NIST SP 800-53 Rev 5 SA-3 (System development life cycle), SA-10 (Developer configuration management), SA-11 (Developer testing and evaluation), SA-15 (Development process, standards, and tools), CM-3 (Configuration change control), CM-7 (Least functionality), and SI-7 (Software, firmware, and information integrity), NIST SP 800-218A (SSDF for Generative AI), CIS Controls v8.1 Control 16 (Application Software Security) Safeguards 16.1 to 16.14, DORA Article 9 (ICT security policies) and Article 17 (Incident management), and NIS2 Article 21 (Cybersecurity risk-management measures), so the same engagement record satisfies several reads at once.
Retesting workflows pair each remediated finding to a verification step run against the post-fix pipeline configuration, with the retest evidence carrying the same CICD-SEC identifier the original finding cited, so the closure record updates the per-risk-class row directly without renegotiation.
Activity log with CSV export records the actor, the entity, the action, and the timestamp for every state change on the engagement, the findings, the override decisions, and the retests, with 30, 90, and 365-day retention windows depending on plan, so the audit trail behind the CI/CD security verification operating record is portable across audit cycles and personnel transitions.
Team management with role-based access keeps AppSec, DevSecOps, platform engineering, security engineering, security operations leaders, GRC and compliance, and the security firm running the engagement on the same workspace with appropriate scoping per risk class.
Multi-factor authentication enforcement at workspace level for the CI/CD security operating records, so the identity assurance applies at access time as well as at evidence time.
Finding overrides hold the deferred CICD-SEC findings on the engagement record with a named approver, named scope, cited reason, hard expiry, compensating control, and refresh trigger, so a deferred row is evidenced rather than silent.

Honest scope: what SecPortal does not do

The CI/CD Top 10 work runs across multiple specialist tools and roles the SecPortal product does not replicate inline. The honest scope below names the boundaries so the engagement record reads against the verified product surface and the externally produced artefacts attach through document management rather than implying the platform performs work it does not perform.

SecPortal is not a CI/CD pipeline scanner agent. The platform does not run inside GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, CircleCI, Jenkins, Azure DevOps, Buildkite, ArgoCD, or Tekton as an in-pipeline scanner. The pipeline-side detections (Stepsecurity Harden-Runner, Chainguard Enforce, Snyk CI/CD, Wiz Code, Frogbot, Sysdig pipeline scanning, GitHub Actions security advisories, GitLab CI/CD insights) are produced where those tools run and land on the engagement record through bulk finding import as CSV intake with column mapping.
SecPortal is not an artefact registry. The platform does not host container images, package artefacts, or build outputs. The registry of record stays with the customer-managed JFrog Artifactory, Sonatype Nexus, Cloudsmith, GitHub Container Registry, Amazon ECR, Azure Container Registry, Google Artifact Registry, or other registry tier; SecPortal captures the artefact identifier (image digest, package hash, version reference) on the engagement record as evidence metadata, not as a hosted artefact.
SecPortal is not a signing service. The platform does not run Sigstore, Cosign, Notary, or another signing infrastructure inline. The signing identity, the signing timestamp, the signed artefact reference, and the verification policy live with the customer-managed signing service; SecPortal captures the signing record on the engagement record as evidence pointers.
SecPortal is not a secrets manager. The platform does not host application secrets or pipeline secrets. The secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, 1Password Connect, Doppler, GitHub Encrypted Secrets, GitLab CI/CD variables) remains the system of record; SecPortal captures the secret inventory and rotation cadence evidence on the engagement record as document-management artefacts. SecPortal does store encrypted credentials for its own authenticated scanning use case at AES-256-GCM at the application layer, which is a separate scoped surface and is not a general-purpose secrets manager substitute.
SecPortal is not a runtime sensor. The platform does not run an eBPF probe, a Kubernetes admission controller, a runtime EDR agent, a Sysdig Falco rule engine, or any other live runtime detection layer. Runtime detections produced by those tools land on the engagement record through bulk finding import, not as native runtime telemetry.
SecPortal does not push to GitHub Actions, GitLab Pipelines, Bitbucket Pipelines, CircleCI, Jenkins, Azure DevOps, Buildkite, ArgoCD, or Tekton through native admin APIs. The platform reads repository state through GitHub, GitLab, and Bitbucket OAuth connections for code scanning purposes; it does not write back to pipeline configurations, runner settings, or pipeline approval states.
SecPortal does not ship packaged connectors into Jira, ServiceNow, Slack, Microsoft Teams, PagerDuty, SIEM, SOAR, GRC platforms, or asset management or CMDB systems. The CI/CD Top 10 findings live on the SecPortal workspace and the wider operational ticketing, runbook, and asset-management workflows remain in the systems where the rest of the work is tracked.
SecPortal does not ship enterprise single sign-on, SCIM, or SAML at the platform layer. Workspace authentication is email-plus-password with TOTP multi-factor authentication enforcement; identity assurance for federated enterprise login remains on customer-managed identity providers.
SecPortal does not run automated approval routing for CICD-SEC findings. Risk acceptance, exception approval, and deferred-finding sign-off are recorded on the workspace with named approver, named scope, cited reason, hard expiry, and compensating control; the platform records the decision as a finding override but does not route the approval through an external approval workflow engine.
SecPortal does not issue CI/CD Top 10 verification certificates. Verification claims at the engagement level are made by the engagement team and reviewed by the buyer; SecPortal supplies the operating record the claim is anchored in, not the certificate.
SecPortal does not replace the OWASP CI/CD Security project. The risk-class catalogue and the supporting documentation are maintained by the OWASP CI/CD Security community on GitHub. SecPortal is the operating layer that runs an engagement against a versioned snapshot of the project, with the per-risk-class record paired to the workspace findings and evidence.

The operational workstreams the CI/CD Top 10 programme reads against already exist as named use cases on SecPortal. The internal developer platform security guardrails workflow covers the paved-road platform contract the CI/CD Top 10 risk classes translate into. The code review use case covers the SAST and SCA evidence the CICD-SEC-3 and CICD-SEC-9 risk classes read against. The DevSecOps scanning use case covers the continuous-scanning rhythm the per-release pipeline verification gate runs on. The secret scanning remediation workflow covers the CICD-SEC-6 (credential hygiene) operational discipline. The SBOM management and VEX publishing workflow covers the CICD-SEC-9 (artefact integrity validation) operating record. The cross-framework control mapping workflow reads the same CI/CD Top 10 engagement record across NIST SSDF, ISO 27001 Annex A, SOC 2, PCI DSS, NIST SP 800-53, CIS Controls, DORA, and NIS2 so the cross-regime read is reconcilable rather than reconciled per audit.

Key control areas

SecPortal helps you track and manage compliance across these domains.

CICD-SEC-1: Insufficient Flow Control Mechanisms

A pipeline that lets a single contributor push code, define the build that runs against it, approve the build, and ship to production with no separation-of-duties gate. Evidence: branch protection state, required reviewer counts, build-and-deploy approval separation, pipeline-definition repository protection.

CICD-SEC-2: Inadequate Identity and Access Management

A pipeline where service accounts and human identities are over-permissioned, long-lived, or shared across environments. Evidence: PAT inventory with scope and age, service principal inventory with attached roles, shared-bot account inventory, group membership audit.

CICD-SEC-3: Dependency Chain Abuse

A pipeline that lets an attacker substitute a malicious package via dependency confusion, typosquatting, brand-jacking, or unverified package signatures. Evidence: registry resolution policy, scoped private registry configuration, dependency hash pinning, internal mirror with allowlist.

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

A pipeline whose definition is influenced by attacker-controlled input triggering an elevated build. Evidence: PR-triggered build configuration, secret access scope per trigger, untrusted-runner isolation, pipeline-as-code review discipline.

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

A pipeline where runtime steps run with more privilege than the work they do requires. Evidence: runner agent role inventory, per-step secret scope, ephemeral runner credentials, downstream pipeline credential inheritance.

CICD-SEC-6: Insufficient Credential Hygiene

A pipeline that handles secrets in a way that lets them leak, persist, or escape. Evidence: secret store inventory, secrets-in-source-code scan, environment variable logging exposure, container layer secret check, rotation cadence record.

CICD-SEC-7: Insecure System Configuration

A pipeline where the runner host, the build agent, the tooling, or the package proxy is misconfigured. Evidence: runner image versioning, runner network segmentation, build-agent hardening baseline, concurrent-job isolation.

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

A pipeline that integrates third-party actions, plugins, or services without a vetting record. Evidence: third-party action allowlist, action pin policy (tag vs hash), publisher verification policy, secret-access scope of integrations.

CICD-SEC-9: Improper Artefact Integrity Validation

A pipeline that produces or consumes build artefacts without a verifiable integrity signal. Evidence: artefact signing record, container image signing record, SBOM attachment per release, SLSA provenance attestation, downstream signature verification policy.

CICD-SEC-10: Insufficient Logging and Visibility

A pipeline whose security-relevant events are not logged, not retained, or not correlatable with the artefacts they produced. Evidence: pipeline configuration edit history, runner agent log retention, build-to-artefact correlation, log integrity record, anomalous-pipeline-behaviour alerting.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Finding overrides that survive every scan cycle

Find vulnerabilities before they ship

Repository connections for SAST and SCA

Bulk finding import bring your scanner data with you

Document management for every security engagement

AI-powered reports in seconds, not days

Compliance tracking without a full GRC platform

Verify fixes and track reopens on the same finding record

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Encrypted credential storage for authenticated scans

Run a CI/CD Top 10 engagement on one workspace

Anchor each finding to a CICD-SEC risk class identifier, a named pipeline platform, a named repository, a named runner environment, and an evidence pointer. Carry the same engagement record across NIST SSDF, ISO 27001 Annex A 8.25 to 8.33, SOC 2 CC6 and CC8, PCI DSS Requirement 6, NIST SP 800-53 SA and CM families, CIS Controls v8.1 Control 16, DORA Article 9, and NIS2 Article 21 without rebuilding the evidence pack per audit. Start free.