STRIDE Threat Modeling for CI/CD

Updated 14 March 2026

The paper presents a systematic STRIDE-based methodology to enumerate and prioritize CI/CD threats.
It details mapping of security risks to concrete controls aligned with NIST, OWASP, and SLSA standards.
It offers a practical roadmap for integrating security-as-code and automated risk mitigation in DevOps pipelines.

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 (Dhandapani, 6 Jun 2025, Wong et al., 2021, Reichert et al., 2022).

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 1 in (Dhandapani, 6 Jun 2025) 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$ (Dhandapani, 6 Jun 2025). For example, T1 (credential compromise) is assessed $L=3$ , $I=5$ , yielding $Risk=15$ (high).

This model aligns with the containerized pipeline taxonomy in (Wong et al., 2021) (Stages: Source, Build, Registry, Runtime) and the five-stage abstraction (Integration, CI, IaC, Deployment, Release) in (Reichert et al., 2022).

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 ((Dhandapani, 6 Jun 2025), 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 (Dhandapani, 6 Jun 2025).

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 (Dhandapani, 6 Jun 2025).

6. Roadmap for STRIDE-Based Pipeline Hardening

A practical, nine-step checklist operationalizes the threat modeling approach (Dhandapani, 6 Jun 2025):

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

This methodology is closely echoed in (Wong et al., 2021), where container ecosystem threat modeling adopts the same stage-wise STRIDE application, and in (Reichert et al., 2022), which confirms the adaptability of the approach to both generic and case-specific pipelines.

STRIDE-based modeling for CI/CD supply chains is compatible with broader threat matrices in the container ecosystem (Wong et al., 2021), as well as with integrity-focused models for software development pipelines (Reichert et al., 2022). 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 (Reichert et al., 2022) sometimes omits Information Disclosure and Denial of Service threats, the more comprehensive approaches (Dhandapani, 6 Jun 2025, Wong et al., 2021) 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 (Dhandapani, 6 Jun 2025, Wong et al., 2021, Reichert et al., 2022).