What Is Secure Design Analysis for CI/CD Security?

Secure design analysis is the practice of examining a CI/CD pipeline’s architecture, trust boundaries, and privilege flows before and as it’s built, rather than only scanning the code and artifacts that pass through it. It’s advanced threat modeling applied specifically to build and deployment infrastructure: instead of asking “does this pipeline have secrets scanning enabled,” it asks “if this specific runner is compromised, what can it reach, and does that map to a real, costly consequence.” That distinction matters more than it used to, because the pipeline itself, not just the code it builds, has become one of the most attacked parts of modern software delivery.

What Secure Design Analysis Actually Examines

A secure design analysis of a CI/CD pipeline looks at the trust relationships between stages, not just the presence or absence of individual controls. That includes which runners have access to which secrets and for how long, whether a given runner is ephemeral or persistent, what a third-party action or plugin is actually permitted to do once it executes inside the pipeline, how artifacts are signed and verified between build and deployment, and what blast radius exists if any single stage is compromised. These are design questions, answered by understanding the architecture, not by findings a scanner produces by checking a pipeline configuration against a known-bad pattern list.

Why This Differs From a Checklist-Based Pipeline Review

A checklist-based review asks binary questions: is secrets scanning enabled, yes or no; are third-party actions pinned to a commit hash, yes or no. These questions are useful, but answering “yes” to all of them doesn’t tell you whether the pipeline’s overall trust architecture actually holds up. A runner can have secrets scanning enabled and still hold long-lived, overly broad credentials that a single compromised dependency can exfiltrate in full. Secure design analysis treats the checklist items as inputs to a broader question, not the answer itself: given everything this pipeline is permitted to do, what’s the worst realistic outcome if any one trusted component inside it turns out not to be trustworthy.

The Data Behind Why This Matters Now

CI/CD infrastructure has become attackers’ preferred target specifically because of how much standing trust and privilege it concentrates in one place. GitGuardian’s 2026 State of Secrets Sprawl report found that 59 percent of machines with compromised credentials in 2025 were CI/CD runners, not developer workstations, a reversal of where this kind of compromise used to concentrate.

The same report found more than 29 million new secrets exposed in public GitHub repositories in 2025, a 34 percent year-over-year increase, and that 64 percent of secrets confirmed valid in 2022 were still valid and unrevoked as of January 2026.

This isn’t abstract. In March 2025, attackers compromised the widely used tj-actions/changed-files GitHub Action by retroactively redirecting its version tags, exposing secrets across more than 23,000 repositories. In March 2026, a threat actor publicly tracked as TeamPCP ran a coordinated campaign compromising multiple trusted CI/CD security tools, exfiltrating more than 78,000 secrets from over 2,100 organizations in five days. Both incidents exploited design-level trust assumptions, that a widely used action or tool can be trusted implicitly once adopted, rather than a simple missing control a checklist would have flagged.

What This Looks Like in Practice: Four Design Questions

Applied concretely, secure design analysis for a CI/CD pipeline works through four questions in sequence. What triggers this pipeline to run, and can that trigger be influenced by an untrusted input, such as a pull request from an external contributor? What can each stage reach once it’s running, in terms of secrets, cloud permissions, and adjacent systems, and is that access scoped to only what the stage actually needs? How is trust established with anything external the pipeline depends on, third-party actions, base images, or plugins, and what happens if one of those dependencies is compromised rather than simply outdated? What’s the actual blast radius if a credential inside this pipeline leaks, meaning how long does it remain valid, and what could it be used for beyond its original purpose?

Industry data suggests most organizations haven’t fully closed the gap these questions are meant to surface. OIDC-based authentication, which eliminates long-lived credentials in favor of short-lived, scoped tokens, remained under 15 percent of eligible pipeline adoption at the time of the tj-actions breach, and separate research found 35 percent of enterprises still run non-ephemeral, self-hosted runners with weaker default configurations.

How This Fits as Advanced Threat Modeling

Secure design analysis is a specific application of the same logic that distinguishes advanced, risk-centric threat modeling from a generic checklist more broadly: findings are only useful once they’re weighed against actual consequence, not just matched against a known pattern. PASTA (Process for Attack Simulation and Threat Analysis), the methodology this broader approach is most associated with, applies that same sequence, understanding what matters and what’s exposed before ranking findings, to an application generally. Applying it specifically to CI/CD pipeline architecture is a natural extension, since the pipeline is itself a system with its own trust boundaries, privileges, and failure modes, not just a conduit the application passes through.

Limitations and Open Questions

Secure design analysis addresses architecture and trust boundary questions; it doesn’t replace runtime monitoring, which is still necessary to catch a design flaw being actively exploited or a misconfiguration introduced after the design was reviewed. A pipeline can be well-designed on paper and still be implemented incorrectly, so design analysis works best paired with validation that the actual configuration matches the intended architecture. Finally, the low measured adoption of practices like OIDC and ephemeral runners suggests that for most organizations, the gap this analysis is meant to close isn’t a lack of awareness of best practice; it’s that implementing the redesign these findings call for is a larger undertaking than enabling an additional scanning tool, which is a real adoption barrier this piece doesn’t have data to fully explain.

Frequently Asked Questions