---
title: STRIDE Threat Modeling for CI/CD
url: https://www.emergentmind.com/topics/stride-based-threat-modeling-of-ci-cd-pipelines
type: topic
---

# STRIDE Threat Modeling for CI/CD

STRIDE-based threat modeling is a systematic approach for enumerating, prioritizing, and mitigating security threats within Continuous Integration and Continuous Deployment (CI/CD) pipelines, leveraging the STRIDE mnemonic—Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. In modern DevOps practices, where software supply chain attacks have escalating impact, STRIDE-based modeling enables both theoretical rigor and practical pipeline hardening. It provides a framework for tracing threats across pipeline stages, selecting controls proportional to business risk, and aligning mitigations with industry standards such as NIST SSDF, OWASP Top 10 CI/CD, and the SLSA framework [2506.06478][2111.11475][2211.06249].

## 1. CI/CD Pipeline Architecture and Asset Modeling

Canonical CI/CD pipelines are decomposed into discrete architectural stages, each constituting its own asset and trust boundary:

- **Source (SCM):** Source code, secrets, and CI/CD configuration, typically managed in GitHub; critical assets include AS1 (credentials), AS2 (code), AS3 (CI config), and AS4 (secrets).
- **Build & Test:** Build scripts, execution environments (Jenkins, GitHub Actions), temporary binaries, and secrets (AS3, AS4, AS5).
- **Containerization & Signing:** Docker, Sigstore/Cosign integration; artifacts include signed images and SBOMs.
- **Artifact Storage:** Registries like Artifactory, ECR, or GCR, holding immutable container images and metadata.
- **Deployment & Orchestration:** Kubernetes via Helm/ArgoCD, with assets including deployment manifests and cluster configurations.

Figure 3 in [2506.06478] illustrates the primary data flows and trust boundaries, specifying the interactions between Developers, SCM tools, CI runners, artifact repositories, and Kubernetes clusters.

## 2. STRIDE Threat Taxonomy Across Pipeline Stages

STRIDE is applied at each pipeline stage to systematically enumerate threats, each with distinct threat agents, vectors, and evaluated impact and likelihood. Representative threats are organized by stage:

| Stage            | S (Spoofing)                  | T (Tampering)                 | R (Repudiation)                                  | I (Info Disclosure)      | D (DoS)                                            | E (Privilege Escalation)                      |
|------------------|-------------------------------|-------------------------------|--------------------------------------------------|--------------------------|----------------------------------------------------|-----------------------------------------------|
| **Source (GitHub)** | T1: Stolen credentials        | T5: CI/CD config tampering     | –                                                | T4: Secrets in source    | –                                                  | T11: Malicious 3rd-party app                  |
| **Build/Test**      | –                             | T3: Unreviewed code auto-merge | T14: Artifact ops (also non-repudiation absence) | T8: Secret exfiltration | –                                                  | T12: Artifact tampering in transit            |
| **Container/Storage** | –                          | T14: Unsigned image replaced   | T14: Audit trail absence                         | T7: Malicious public layer | T9: Registry storage exhaustion                     | T2: Untrusted base image, container escapes   |
| **Deployment (K8s)** | –                          | T10: Unauthorized prod deploy  | –                                                | –                        | –                                                  | T13: K8s manifest drift/config misprivilege   |
| **Monitoring**       | –                           | T6: Log tampering/missing      | –                                                | –                        | –                                                  | –                                             |

Each threat is assigned likelihood ($L$) and impact ($I$) scores $\in\{1,3,5\}$, and overall risk is computed as $Risk = L \times I$ [2506.06478]. For example, T1 (credential compromise) is assessed $L=3$, $I=5$, yielding $Risk=15$ (high).

This model aligns with the containerized pipeline taxonomy in [2111.11475] (Stages: Source, Build, Registry, Runtime) and the five-stage abstraction (Integration, CI, IaC, Deployment, Release) in [2211.06249].

## 3. Threat→Control Traceability and Quantitative Risk Metrics

Every identified threat is traced to concrete mitigating controls, mapped to NIST SP 800-218 (SSDF) practices, OWASP CI/CD risks, and SLSA levels.

For example, in the Source stage ([2506.06478], Table 4):

| T#  | Description                 | OWASP Risk  | Controls                               | SLSA L | SSDF Practice   |
|-----|-----------------------------|-------------|----------------------------------------|--------|-----------------|
| T1  | Stolen SCM creds            | A01, A07    | MFA, RBAC, IDP-only, login rate-limit  | –      | PO.1.1, PS.1.1  |
| T4  | Hard-coded secrets          | A02, A04    | Pre-commit scanning (Gitleaks)         | –      | PS.1.1, PW.4.1  |
| T5  | CI config tamper            | A04, A08    | OPA policy, branch protection, epheremal runners | L3–L4 | PO.2.3, PW.7.2 |
| T11 | Malicious 3rd-party app     | A05, A08    | App allow-list, scope review           | –      | PO.1.3, RV.1.1  |

Risk scoring for each threat follows $Risk = L \times I$; organizations can prioritize mitigations for high-risk items. The provenance “trust score” is formulated as

\[
\mathrm{TrustScore} = \frac{\sum_{c\in \mathrm{Controls}} w_c \cdot \mathbf{1}_{\{c~\mathrm{enabled}\}}}{\sum_{c}w_c}
\]

which expresses the proportion of weighted controls enabled at a given pipeline stage.

## 4. Controls and SLSA Maturity Levels

Control strength is directly mapped against SLSA levels (L1–L4):

\[
\begin{array}{|l|c|c|c|c|}
\hline
\textbf{Control / STRIDE}        & \textbf{L1} & \textbf{L2} & \textbf{L3} & \textbf{L4} \\
\hline
Artifact Signing (T12, T14)      & \times & \checkmark & \checkmark & \checkmark \\
Build Provenance (in-toto)       & \times & \checkmark & \checkmark & \checkmark \\
Hermetic Builds                  & \times & \times      & \checkmark & \checkmark \\
Branch Protection                & \times & \times      & \checkmark & \checkmark \\
IAM/RBAC Hardening               & \times & \times      & \times      & \checkmark \\
\hline
\end{array}
\]

At L1, only scripted builds may exist. L2 integrates hosted build provenance, L3 enforces strong cryptographic signatures, and L4 mandates strict identity and sharing restrictions. As controls are incrementally adopted, the provenance trust score approaches unity ($1.0$), indicating maximal supply chain resilience [2506.06478].

## 5. Security-as-Code, Shift-Left, and Shield-Right Implementation

Practical integration of STRIDE-driven controls emphasizes “Security-as-Code”—encoding policies and guardrails directly within pipeline configuration. This includes:

- **OPA/Rego policies** to block dangerous build patterns (e.g., disallowing `echo $SECRET` in pipeline steps);
- **Branch protection policies** and PR review requirements enforced in Jenkinsfile or GitHub Actions YAML;
- **Shift-Left mechanisms** such as pre-commit secret scanning with Gitleaks, dependency scanning (e.g., Dependabot), and enforced signed commits;
- **Shield-Right mechanisms** leveraging runtime syscall anomaly detection (Falco), network egress restrictions, and SIEM-based audit log monitoring.

Security toolchains are mapped for each stage: Trivy (scanning), Checkov (policy enforcement), Cosign (signing), in-toto (provenance), Vault (secrets), OPA (policy gates), Kubernetes admission controllers (deployment gating), and centralized SIEMs for monitoring [2506.06478].

## 6. Roadmap for STRIDE-Based Pipeline Hardening

A practical, nine-step checklist operationalizes the threat modeling approach [2506.06478]:

1. **Scope & Model:** Construct DFDs, enumerate assets and threat agents.
2. **STRIDE Workshops:** Apply STRIDE per stage to systematically generate threat scenarios.
3. **Risk Assessment:** Assign likelihood/impact, compute and prioritize risks.
4. **Control Mapping:** Select mitigations from SLSA, SSDF, OWASP matrices.
5. **Policy-as-Code:** Write and embed automation policy scripts (OPA/Rego, Jenkinsfile).
6. **Toolchain Integration:** Deploy scanning, signing, access control, and provenance tools.
7. **SLSA Maturity Progression:** Start from L1, progress sequentially to L4.
8. **Monitoring & Feedback:** Centralize logs, deploy runtime detectors, conduct red-team exercises.
9. **Continuous Improvement:** Revisit and update STRIDE model and controls biannually or after major pipeline changes.

This methodology is closely echoed in [2111.11475], where container ecosystem threat modeling adopts the same stage-wise STRIDE application, and in [2211.06249], which confirms the adaptability of the approach to both generic and case-specific pipelines.

## 7. Comparative Analysis and Integration with Related Threat Models

STRIDE-based modeling for CI/CD supply chains is compatible with broader threat matrices in the container ecosystem ([2111.11475]), as well as with integrity-focused models for software development pipelines ([2211.06249]). All models stress the mapping between pipeline architectural decomposition, asset ownership, trust boundary identification, and the disciplined enumeration of threats.

While the integrity focus in [2211.06249] sometimes omits Information Disclosure and Denial of Service threats, the more comprehensive approaches [2506.06478][2111.11475] enumerate all STRIDE categories, advocating controls such as MFA for repository access, signature verification, immutable logging, least privilege, vulnerability scanning, and audit trail assurance at every stage.

A plausible implication is that effective STRIDE-based modeling for CI/CD pipelines integrates both procedural (workshop-based, DFD-driven) and automatic (Security-as-Code, toolchain orchestration) elements, with continuous realignment to evolving standards and attacker tactics. The resulting defense-in-depth posture addresses both supply chain and runtime threats, demonstrating adaptable rigor across diverse deployment contexts [2506.06478][2111.11475][2211.06249].

Source: https://www.emergentmind.com/topics/stride-based-threat-modeling-of-ci-cd-pipelines