Why a CI/CD pipeline security review matters before a launch or audit
A CI/CD pipeline security review tests whether the systems that build, sign and deploy your software can be trusted, and it gives you written findings you can show a customer, an assessor or an insurer. A framework, a customer questionnaire, a launch or a due diligence request usually asks how software is built and released, not only what the application does. The pipeline is part of that answer. It is in scope alongside source code and open-source dependencies, because a build system with weak controls can alter software that passed every other check. Measuring the review against NIST SP 800-218, the Secure Software Development Framework, and the OWASP Top 10 CI/CD Security Risks gives the findings a common vocabulary that security and compliance reviewers already recognize.
The review focuses on four risks that most often appear in pipelines under time pressure. A compromised runner can read secrets, tamper with build output or move laterally into the network, especially when self-hosted runners are shared between projects. A poisoned workflow occurs when an untrusted contributor, pull request or third-party action can change what runs in a privileged job. Leaked deployment credentials sit in environment variables, logs or long-lived tokens that outlive the person or job that created them. Unverified artifacts reach production because nothing checks where a build came from or whether it matches the reviewed source. Each risk maps to a category in the OWASP list, such as CICD-SEC-4 Poisoned Pipeline Execution, CICD-SEC-6 Insufficient Credential Hygiene and CICD-SEC-9 Improper Artifact Integrity Validation.
Before commissioning the review, confirm which pipelines, repositories, runners and deployment targets are included, and who on your side can grant read access to workflow definitions, branch protection settings and audit logs. Ask the provider to state which SLSA Build level and Source track requirements the review will test against, since that determines the evidence you need to collect. If an auditor will rely on the output, agree in advance how findings map to your control set, for example ISO/IEC 27001:2022 control A.8.29 on security testing in development. Starting these conversations early reduces the risk that a launch date slips because the evidence was never collected.
What a CI/CD pipeline security review covers
A pipeline review follows the path from source code to deployed artifact, because a weakness at any stage can let an attacker change what ships. The cards below name the components a review can include, then the decisions the client makes before testing starts.
Source hosting and branch protection
We review how repositories are hosted, who can push to protected branches, and whether merges require review and passing checks. Weak flow control here is the usual route by which unreviewed code reaches a build. We check branch protection rules, required reviewers, force-push and deletion settings, and who can change those settings. Ask the client to confirm which hosting platform and plan features are in use, since available controls differ.
Pipeline definitions and reusable templates
Workflow files and shared templates decide what runs, with which triggers and permissions. We review whether untrusted input, such as pull request titles or branch names, can reach commands, whether workflows that run on forks can access secrets, and whether shared templates are versioned and owned. Changes to these files should go through the same review as application code.
Build runners, hosted and self-hosted
Runners execute pipeline jobs and often hold credentials and network access. For hosted runners we check isolation between jobs and what the job can reach. For self-hosted runners we review whether they are ephemeral, whether they are shared across repositories, and whether a compromised job can persist on the host or reach internal networks. Confirm with the client which runner types are used and who administers them.
Secrets and credential stores
We check where pipeline credentials are stored, how they are scoped, and how long they live. Review covers repository and organization secrets, environment-level secrets, cloud federation for short-lived tokens, and whether secrets are exposed in logs or artifacts. The aim is to find long-lived static keys with broad access that a single compromised job could use.
Third-party actions and plugins
Pipelines often pull in marketplace actions, plugins or images that run with the same privileges as the build. We review which external components are used, whether they are pinned to a full commit hash or a mutable tag, who maintains them, and whether the organization approves them before use. OpenSSF Scorecard checks such as Pinned-Dependencies and Dangerous-Workflow give a useful baseline for this review.
Artifact registries and deployment stages
We review how build outputs are stored, signed, and promoted to each environment. Checks include whether artifacts are tied to the commit and build that produced them, whether deployment jobs verify provenance before release, and who can push to production registries or approve production deployments. Reviewing this stage against SLSA build levels helps show how strong the chain of custody is.
How a CI/CD pipeline security review runs, phase by phase
The sequence moves from a written scope to evidence-backed findings that engineers have confirmed and that can be retested. Each phase closes with a defined output, so the client knows what it has received before the next phase begins.
Agree scope and rules in writing
The reviewer and the client agree in writing which pipelines, repositories, runners, registries and deployment targets are in scope, who the named contacts are, and what access the review needs. The agreement also states that the work is defensive: weaknesses are confirmed through configuration, logs and evidence, and the review does not run exploits or attack production build or deployment systems. The step closes when both parties have signed the scope and the access plan.
Inventory pipelines, runners and access paths
The reviewer collects an inventory of every pipeline definition, trigger, reusable workflow, self-hosted and hosted runner, service account, token type, secrets store and artifact registry in scope. Client platform engineers provide read-only access or exports, and the reviewer maps who can change pipeline code and who can approve a release. The step closes with a written inventory that the client confirms is complete, since gaps here shape every later finding.
Review configuration against OWASP CI/CD risks
The reviewer checks each pipeline against the ten OWASP Top 10 CI/CD Security Risks, CICD-SEC-1 to CICD-SEC-10. Typical checks cover branch protection and required reviews (CICD-SEC-1), token and role scope (CICD-SEC-2, CICD-SEC-5), handling of secrets in logs and variables (CICD-SEC-6), runner isolation and hardening (CICD-SEC-7), and pinning and vetting of third-party actions and services (CICD-SEC-3, CICD-SEC-8). Each suspected weakness is recorded with the configuration line or setting that shows it. The step closes with a risk-mapped list of candidate findings.
Assess build provenance and integrity
The reviewer compares how artifacts are built and released with the SLSA levels, from L0 to L3 on the Build track, and with the Source track's requirements for source code management. The review asks whether builds run on a hosted or isolated platform, whether provenance is generated and signed, whether artifacts can be traced to a specific source revision, and whether consumers verify signatures before deployment. This maps to CICD-SEC-9. The step closes with a statement of the current level the evidence supports and the gaps to the next level.
Run tool-assisted checks where agreed
Where repositories are open source, or where the client agrees, the reviewer runs tool-assisted checks such as OpenSSF Scorecard. Scorecard scores checks including Branch-Protection, Dangerous-Workflow, Pinned-Dependencies and Token-Permissions from 0 to 10 and combines them into a weighted aggregate. The reviewer treats these scores as prompts for investigation, not as verdicts, and confirms each relevant result manually against the configuration. The step closes with tool output that is annotated with what was confirmed, what was a false positive, and what needs client context.
Validate findings with client engineers
The reviewer walks through each candidate finding with the pipeline owners and security engineers who maintain it. The client may show that a control exists elsewhere, that a setting is intentional, or that a risk is accepted, and the reviewer records each outcome with the evidence. Severity is then set against the client's actual exposure, including which branches, environments and secrets are reachable. The step closes when every finding is either confirmed, disputed with evidence, or marked for risk acceptance by an accountable owner.
Deliver the report and remediation plan
The reviewer delivers a written report that lists confirmed findings with the OWASP CI/CD risk and, where relevant, the SLSA requirement each one affects. Each finding includes the evidence, the affected pipeline, a recommended fix and its owner. The report also states the scope and limits of the review, including what was not reviewed. The report can serve as supporting evidence for an internal assessment or a customer review, but it is not an audit opinion, and the client's auditor decides how it is used. The step closes with a client-accepted report.
Retest fixes and confirm closure
Once the client has applied fixes, the reviewer repeats the relevant configuration checks and inspects the changed pipeline definitions, permissions and provenance output. Each finding is marked closed, partially closed or open, with the evidence used to decide. Retesting scope and timing are agreed in the original written scope or in a separate change to it. The step closes with a retest record that shows which findings were verified as fixed and which remain open.
Which CI/CD pipeline weaknesses the OWASP risks describe
This table maps each OWASP Top 10 CI/CD Security Risk to how the weakness typically appears in a build or deployment pipeline and why it matters to the buyer. Read each row as a review question: if the pattern exists in your pipelines, the risk applies and the review should test it. The main takeaway is that most of these risks come from configuration and trust decisions, so they are often found through review of pipeline definitions, not only through scanning the application.
| OWASP risk | What it typically looks like in a pipeline | Why it matters to the buyer |
|---|---|---|
| CICD-SEC-1 Insufficient flow control mechanisms | Production deployments can be triggered without a second reviewer, protected branches allow direct pushes, or a single account can change code and approve its own release. | Without enforced review gates, one compromised or careless account can ship unreviewed code to production, which undermines any change-control evidence an auditor requests. |
| CICD-SEC-2 Inadequate identity and access management | Pipeline service accounts and human users hold broad rights across repositories, environments and cloud accounts, and nobody reviews those grants on a regular basis. | Excess identity rights turn a single pipeline compromise into access to many systems, and access reviews are a common assessor request. |
| CICD-SEC-3 Dependency chain abuse | Builds pull packages, base images or build tools without pinning versions or verifying sources, and internal package names can be confused with public ones. | Build inputs that are not controlled let altered or malicious dependencies enter released software, which links directly to SBOM accuracy and supplier risk. |
| CICD-SEC-4 Poisoned pipeline execution | Workflows triggered by untrusted contributions, such as external pull requests or forks, run with access to secrets or privileged runners, or pipeline definitions can be changed by the code being built. | A build that executes untrusted input with privileged access can expose credentials and alter outputs, so reviewers should check trigger rules and what each job can reach. |
| CICD-SEC-5 Insufficient PBAC (pipeline-based access controls) | Access tokens for pipeline jobs are broader than the job needs, for example one token with write access used for both tests and deployment, or permissions that are never narrowed per workflow. | Overly broad pipeline permissions mean any job failure or injected step has more reach than required, and least-privilege evidence is hard to produce without per-job scoping. |
| CICD-SEC-6 Insufficient credential hygiene | Long-lived cloud keys or passwords are stored as pipeline variables, printed in logs, shared across projects, or never rotated after staff changes. | Stored credentials are a frequent route to cloud and production access, and buyers should ask how secrets are issued, scoped, rotated and revoked. |
| CICD-SEC-7 Insecure system configuration | Self-hosted runners or build servers are shared across teams and trust levels, run with root or administrator rights, lack patching, or keep leftover workspaces between jobs. | Shared build infrastructure lets one project affect another, and runner isolation is a question assessors and customers ask about directly. |
| CICD-SEC-8 Ungoverned usage of third-party services | Third-party actions, plugins or hosted services are referenced by mutable tags or branches, added without an approval process, or granted full repository access. | Each external service joins the trust boundary of your release process, so an inventory, version pinning and approval record are needed to show governance. |
| CICD-SEC-9 Improper artifact integrity validation | Build outputs are not signed or verified, provenance is not recorded, and artifacts are promoted between environments by name or tag rather than by verified digest. | Without integrity checks, a tampered artifact can reach production unnoticed; SLSA Build track levels describe how strong these guarantees should be, and reviewers can compare current state against them. |
| CICD-SEC-10 Insufficient logging and visibility | Pipeline runs, permission changes, secret access and workflow edits are not logged centrally, or logs are kept only for short periods and never reviewed. | Without logs, an incident in the build chain cannot be reconstructed, and monitoring evidence is commonly requested under incident response and audit controls. |
What drives the cost of a CI/CD pipeline security review
This table compares the factors that change the effort of a pipeline review and shows how each one can be scoped efficiently. Read it before requesting a quote, because the rows show which details the provider needs in writing. Most of the cost sits in reviewer time for scoping, testing, reporting and retest, so clear access and a defined provenance target matter as much as the size of the estate.
| Driver | Why it changes effort | How to scope efficiently |
|---|---|---|
| Number of repositories and pipelines | Each repository adds workflow files, branch rules, release jobs and environment settings to read and test. Reusable templates shared across many repositories can be reviewed once and then checked for inheritance. | List repositories by business criticality and release path. Group similar pipelines and agree which ones receive full review and which receive a configuration check. |
| Number and type of runners | Hosted runners are managed by the platform, while self-hosted runners need host hardening, network placement and isolation checks. Shared runners that serve several projects raise cross-project exposure questions. | State the count of hosted and self-hosted runners, whether each is ephemeral or persistent, and which projects share them. Confirm which runner groups are in scope. |
| Third-party actions, plugins and reusable templates | Each external action or plugin is a dependency that runs with pipeline privileges. Pinning, provenance and maintainer history need checking for each one that is in scope. | Provide an inventory or a pipeline export that lists external references, with version pinning as it stands. Agree a sampling approach if the list is very long. |
| Deployment environments and cloud accounts in scope | Every environment the pipeline can deploy to, and every cloud role it can assume, extends the review into identity and access configuration. Production paths usually need the most attention. | Name the environments and accounts, and state which are production. Confirm whether review covers the configuration of the target accounts or only the pipeline's trust and permissions. |
| Depth of build provenance review against target SLSA levels | Checking that build outputs carry signed provenance and that the build platform is isolated from user-defined steps requires more evidence than a configuration review. The level targeted in the SLSA Build track sets how deep this goes. Reaching a higher level usually means checking more controls. | Name the SLSA Build level the client aims to demonstrate, and whether the Source track also applies. Ask the provider to separate provenance checks from general hardening in the quote. |
| Access constraints and pipeline exports | When the reviewer can read workflow files, settings exports, audit logs and runner configurations directly, less time goes to reconstruction. Restricted access or manual screenshots add time for both sides. | Confirm which artifacts the team can provide, such as workflow files, branch protection settings, environment rules and logs, and the format. Agree who will supply them and within what time. |
| Number of retest rounds | Each retest needs the reviewer to recheck fixed findings and confirm that the change did not introduce new weaknesses. Fixes that touch shared templates or runner builds can widen the retest. | Ask for the number of retest rounds to be written into the scope, with the conditions for a round, such as a set of named findings or a change window. |
| One-time review or retainer | A one-time review produces a point-in-time report. A retainer covers repeated checks as workflows change, new actions are adopted and runners are rebuilt. Recurring work is a separate line from the initial review. | Decide whether the need is an assessment for an audit or customer review, or ongoing assurance. Ask for the one-time and recurring elements to be priced separately in the quote. |
Which frameworks expect CI/CD pipeline security review evidence
Several frameworks buyers already work under expect evidence that build and release pipelines are controlled, not only the application code they produce. NIST SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1, is the most useful starting point because it groups practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Pipeline review maps mainly to PS and PW, where the questions are who can change the build, how the software is protected from tampering, and whether the release process verifies what it ships. Buyers can ask for the practices they expect to see, the evidence behind each one and the gaps the review found, using the SSDF as the common vocabulary. The framework is published at NIST SP 800-218.
ISO/IEC 27001:2022 expects security testing to be built into development and acceptance. Control A.8.29, Security testing in development and acceptance, asks for testing processes to be defined and implemented across the development life cycle, and A.8.28, Secure coding, sits beside it. For a pipeline review, the practical evidence is a documented definition of which tests run where, who approves changes to the pipeline, and how results gate a release. Under the EU's DORA, Article 25(1) of Regulation (EU) 2022/2554 lists source code reviews where feasible among the tests in a digital operational resilience testing programme, alongside vulnerability assessments, open source analyses and penetration testing. Financial entities in scope should confirm with their competent authority and internal audit how they plan to evidence this.
The CMMC Assessment Guide Level 2 says custom-developed software may need penetration testing or source code scanning when an assessor examines vulnerability scanning requirement 3.11.2, so defense contractors building their own software should expect questions about how that code is tested before it ships. DeployOpen plans, prepares and documents security testing and the controls and evidence that support a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent assessors and certification bodies make those determinations. Before scoping a review, ask your assessor or auditor which artifacts they accept, such as pipeline configuration exports, approval records, scan outputs or a written testing procedure, and in what form they need them.
What a CI/CD pipeline security review report contains
A pipeline review report is built so that leadership, engineers and the client's own assessors can each act on it. The components below connect findings to the OWASP CI/CD risk IDs and SLSA build levels, and show whether each issue has been closed.
Executive summary for leadership
A short narrative for executives and risk owners that states what was reviewed, the overall exposure, the highest-priority findings and the decisions needed from leadership. It avoids pipeline-level detail so that budget holders can judge business impact. Ask for the summary to name the pipelines in scope, the review dates and any areas that were not tested, so that the summary cannot be read as broader than the work performed.
Findings register mapped to risk IDs
The core of the report is a register where each finding is tagged with the matching CICD-SEC identifier from the OWASP Top 10 CI/CD Security Risks and with the SLSA build level it affects. Mapping lets a reader see, for example, whether unpinned third-party actions fall under dependency chain abuse or poisoned pipeline execution. Check that each finding names the affected pipeline, repository and job, not only a general theme.
Severity ratings and method
Each finding carries a severity rating. The rating method, such as the scale and the factors used to assign it, should be agreed during scoping and written into the report so that results can be compared across retests. Ask the reviewer to explain how exploitability in your environment, such as whether a branch can be pushed by an external contributor, changed the rating. A rating without a stated method is hard to defend to an auditor.
Evidence references for each finding
Each finding points to evidence such as a workflow file path, a permissions block, a runner configuration setting or a branch protection rule. Evidence should be configuration excerpts and pipeline settings, not exploit output. Confirm with the reviewer that sensitive values such as tokens and internal hostnames are redacted before the report leaves the review team, and that each reference can be reproduced by your engineers from the repository or platform console.
Prioritized remediation guidance
Remediation advice is ordered by risk and effort, with specific changes such as scoping job tokens to read-only, moving secrets to a managed store, isolating self-hosted runners or enforcing signed artifacts. Each item notes which SLSA build requirement it moves the pipeline toward. Ask for owners and a sequence that your platform team can plan against, since some fixes touch shared templates used by many repositories.
Retest results and closure status
After remediation, the reviewer retests the original findings and records each as closed, partially closed or still open, with the evidence used to decide. Retest results show whether the pipeline changed, not only whether the team reports a fix. Agree in scoping whether retesting is included and how many rounds it covers, because this determines what the final report can state.
Shareable letter and auditor support
A summary letter describes the scope, method and results in terms the client can share with customers, partners or assessors. It is a report from the reviewer that supports your own assessment. It does not replace an auditor's opinion, and it is not a certification. Confirm with your auditor or customer which evidence they accept, since frameworks such as the NIST SSDF and ISO/IEC 27001 expect your own processes and records as well.
How to prepare for a CI/CD pipeline security review
The most useful preparation is naming two people before testing starts: a technical contact who can explain how pipelines are built and deployed, and a security contact who can make decisions about scope, findings and access. Without both, review sessions stall on questions nobody can answer. Agree who signs off on access requests and who receives interim findings, and confirm that the contacts can be reached during the agreed window. Engineers who own the pipelines also need protected time for validation calls, because many OWASP CI/CD risks, such as flow control and token scope, only show up when someone walks the reviewer through how a real merge reaches production.
Next, provide read-only access to what the reviewer needs to evaluate: source repositories, workflow definitions (for example, .github/workflows files or equivalent pipeline definitions), runner configuration, and branch protection and environment settings. For secrets, share names, scopes and owners only, never values. Pair this with a list of every third-party action, template, shared library and external service the pipelines call, including the versions or commit references pinned. Also list the deployment environments and cloud accounts in scope, and state which ones are production. If the reviewer will validate settings against live pipelines, agree a change freeze or a defined test window in writing so that a pipeline edit made during testing does not invalidate the evidence.
Finally, gather the records that shorten the review. Collect existing security policies, the last review's findings and their remediation status, and any SBOM or build provenance records already produced. Ask the team whether provenance is generated and where it is stored, since that determines which SLSA build level claims can be checked rather than assumed. Confirm with your own engineers which controls are documented and which are informal practice, and say so in the kickoff. Reviewers can then test what is claimed and flag what is not, which keeps the report accurate for your auditor or customer.
What to ask a provider before buying a CI/CD pipeline security review
A pipeline review is only as useful as the reviewer's understanding of your build and deploy systems. The criteria below help you test a provider's experience, method and deliverables before you sign, and confirm that the output will be accepted by your auditor or customer.
Experience with the platforms you run
Ask which CI/CD systems the provider has reviewed in depth, such as GitHub Actions, GitLab CI, Jenkins, Azure DevOps or self-hosted runners, and how those reviews were scoped. Each platform has its own permission model, trigger types and runner design, so a generic checklist will miss platform-specific flaws. Ask how they would confirm workflow triggers, token scopes and cache behavior on your exact stack before the work starts.
Mapping findings to OWASP and SLSA
Ask how each finding will be mapped to the OWASP Top 10 CI/CD Security Risks (CICD-SEC-1 to CICD-SEC-10) and to the SLSA Build track level it affects. A good mapping lets your team prioritize and lets an assessor trace the finding to a recognized risk. Request a sample finding that shows the risk ID, the affected pipeline stage, the evidence and the recommended control.
Written scope and deliverables
Confirm that the engagement is fixed-scope, with the pipelines, repositories, environments and runners in scope listed by name, along with exclusions. Ask for the deliverables and acceptance criteria in writing before signing. Vague scopes such as "review our pipelines" make it hard to tell whether a gap was missed or never in scope. Ask whether the scope covers both the configuration of the pipeline and the code paths that trigger it.
Access granted and limited
Ask what access the reviewer needs, such as read-only repository access, workflow files, pipeline configuration exports, runner details and a named contact on the platform team. Confirm that secrets are never copied out of your systems, that any test credentials are time-limited and revoked at the end, and that all activity is logged. Access should be the minimum needed for the agreed scope, documented in the statement of work.
Report format and a redacted sample
Ask for a redacted sample report before you commit. Check that it includes an executive summary, a risk-rated finding list, reproducible evidence described at a defensive level, affected pipeline components, remediation guidance and a retest status column. Confirm whether the report can be shared with your auditor, customer or insurer, and whether it needs any statement of limitations. Do not assume any assessor will accept it until you have confirmed that with them.
Retest pricing, timing and framework fit
Ask whether retest is included, how it is priced and how soon it can run after fixes are deployed. Clarify whether the retest covers only the original findings or also new changes. Finally, ask whether the provider has supported your specific framework or customer request, such as a supplier security questionnaire or a control set referenced in your contracts. Confirm with your auditor which SSDF, SLSA or ISO/IEC 27001 control evidence they will accept.
How long does a CI/CD pipeline security review take and what does it need from us
What drives the cost of a CI/CD pipeline security review?
The number of pipelines, repositories, runners and deployment targets in scope drives most of the effort, followed by how much the pipeline logic is customized. A review of a small set of pipelines with standard configuration takes far less work than one covering dozens of repositories, shared workflow libraries, self-hosted runners and several production deployment paths. Other factors include whether the review covers only configuration or also the code that runs during builds, how many third-party actions or plugins are referenced, and whether retesting is included. Ask for a quote that lists each pipeline platform, the number of repositories and runners in scope, the mapping to the OWASP Top 10 CI/CD Security Risks and SLSA build levels, and which deliverables are one-time and which recur if you choose a retainer. The price follows from the written scope, and DeployOpen does not publish a price list.
How long does a CI/CD pipeline security review take?
The duration is set in the written scope, and it depends on the same factors that drive cost: how many pipelines and repositories are included, how complex the build and deployment logic is, how quickly access and walkthroughs are arranged, and how many review rounds are needed to confirm findings. Time spent on evidence gathering is often larger than expected, because each control, such as branch protection, environment approvals and runner isolation, needs both configuration and a sample of run history to confirm it operates as described. Delays usually come from access approvals or unclear ownership of pipeline definitions rather than from the testing itself. Your statement of work should state the start date, the review window, the reporting date and any dependency on your team's availability, so the timeline can be checked against your release or audit deadline.
What access and people does a pipeline review need from our team?
A useful review needs read access to pipeline definitions, repository settings, branch protection rules, environment and secret configuration metadata, runner configuration and recent run logs. Read-only access is usually sufficient for assessment, and you should confirm the exact permissions with your platform administrators before work starts. You will also need named contacts who can explain how builds are released, who approves production deployments, how runners are provisioned and where secrets are stored. Expect to involve the platform or DevOps lead, one or two engineers who maintain the pipelines, a security contact who owns the policy, and someone who can answer questions about third-party actions and internal shared workflows. Agree in writing how credentials used during the review are issued, rotated and removed afterward.
Can our internal team review our pipelines alone, and what would it miss?
An internal team can review its own pipelines, and many organizations do this regularly with the OWASP Top 10 CI/CD Security Risks as a checklist. The gap is usually independence and breadth. Teams that build a pipeline tend to accept its design decisions, and they may not check every trust boundary, such as which workflows run untrusted pull request code, which tokens a job receives by default, or whether a shared action can change under a moving reference. Internal reviewers also may not have time to trace artifact signing and provenance across every environment. Automated scanners such as the OpenSSF Scorecard checks cover some items, including branch protection, dangerous workflow patterns, pinned dependencies and token permissions, but they do not judge how your organization's release process actually behaves. A hybrid approach often works: internal staff fix known issues and an outside reviewer tests the design and the exceptions.
Do we need to align our pipelines with SLSA or the OWASP CI/CD risks?
Alignment is required only when a contract, regulator, framework or customer questionnaire names it. Otherwise, both are useful reference points rather than mandatory standards. The OWASP Top 10 CI/CD Security Risks give a shared vocabulary for findings, such as insufficient flow control, poisoned pipeline execution and improper artifact integrity validation. SLSA describes build levels, from L0 to L3 in the Build track, that express increasing guarantees that artifacts have not been tampered with and can be traced to their source. Many compliance programs ask for secure development practices in general terms, which are often mapped to NIST SP 800-218 groups. Confirm with your auditor or customer which references they expect, and ask the reviewer to report the target SLSA level for each pipeline so you can see the gap.
How does retesting work after we fix the findings?
Retesting checks whether each agreed finding has been fixed and whether the fix did not introduce a new weakness, such as a relaxed permission in another workflow. The retest scope, number of rounds and whether it is included in the original price should be written into the scope before work starts. Typically, you provide the changed pipeline definitions, configuration evidence and run logs, and the reviewer verifies them against the original finding. Findings that you decide to accept as risk should be recorded with an owner, a justification and a review date, so the auditor or customer can see the decision. Ask whether the final report will show the status of each finding as open, fixed, accepted or not verified.
Can a CI/CD pipeline review be repeated as our pipelines change?
Yes, a review can be repeated, and repetition is the practical answer for pipelines that change often. A one-time review shows the state of pipelines on a given date, so new workflows, new third-party actions, runner changes and changes to deployment approvals can introduce gaps afterward. Options include a periodic review scheduled against release cycles, a targeted review when a major pipeline or runner change is made, and automated checks in the repository that flag new risky patterns between reviews. DeployOpen offers ongoing support and continuous testing as retainers, and these can be scoped to cover recurring pipeline reviews. Ask for the retainer terms, the triggers for an extra review and how changes to shared workflows are handled, since a single change to a shared library can affect many repositories.
How DeployOpen scopes, tests and retests CI/CD pipelines
DeployOpen reviews CI/CD pipelines against the OWASP Top 10 CI/CD Security Risks and SLSA build levels, starting from a written scope agreed before work begins. The work covers pipeline permissions, secrets, runner isolation, third-party actions and artifact integrity, and the findings are handed over in a form your engineering and assurance teams can act on.
How we scope
- Agree in writing which pipelines, repositories, runners and deployment targets are in scope.
- Confirm which CI/CD platform and hosting model apply, including self-hosted runners and shared templates.
- Record access needed, such as pipeline configuration, workflow files and read-only tokens, before testing starts.
How we test
- Map each pipeline against the OWASP CI/CD risk categories, from flow control to logging and visibility.
- Review workflow permissions, secret handling, runner isolation and third-party action pinning against those categories.
- Check whether build outputs can be traced to source and verified, measured against the SLSA Build track levels.
How we hand over
- Deliver a written report with each finding mapped to its OWASP CI/CD risk ID and affected pipeline.
- Provide prioritized remediation steps that engineering teams can apply to their own workflow files and configuration.
- Document evidence and control mapping that your auditor or customer security team can review directly.
How we support
- Retest agreed findings after fixes are applied and record the outcome against each original finding.
- Offer ongoing support and continuous pipeline review as a retainer, scoped in writing separately from the initial test.
- Confirm with us during scoping how retesting and any follow-up work will be quoted and recorded.
