Pith. sign in

REVIEW 4 major objections 6 minor 25 references

Enhancing Software Supply Chain Security Through STRIDE-Based Threat Modelling of CI/CD Pipelines

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Applying STRIDE threat modeling to a representative CI/CD pipeline and mapping each threat to SLSA and SSDF controls gives organizations a layered, traceable way to cover software supply chain risks from source code through deployment.

desk verdict Useful applied STRIDE+SLSA+SSDF synthesis with a solid gap table, undercut only by an over-broad 'end-to-end' claim and no empirical validation. read the letter →

arxiv 2506.06478 v1 pith:6VFKHHG4 submitted 2025-06-06 cs.SE

Sowmiya Dhandapani This is my paper
classification cs.SE
keywords SoftwareSupplyChainSecurityCI/CDPipelineThreatModelingSTRIDEDevSecOpsSecurity-as-CodeSLSAFrameworkSSDF
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that securing a CI/CD pipeline requires more than artifact provenance, and that a structured threat model fills the gap. It applies the STRIDE threat categories to a representative pipeline built on GitHub, Jenkins, Docker, and Kubernetes, then maps each identified threat to concrete controls drawn from the SLSA maturity model and the SSDF secure-development practices. The result is a stage-by-stage traceability matrix that connects assets, threat agents, STRIDE categories, and controls, showing where SLSA alone leaves coverage gaps such as denial of service, developer identity spoofing, and privilege escalation. If the mappings hold, organizations gain a defensible, risk-prioritized way to harden pipelines against supply chain attacks.

What carries the argument

The central object is the STRIDE threat categorization—Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege—applied to a Data Flow Diagram of the CI/CD pipeline. The argument works through a traceability matrix that assigns each pipeline asset an identifier, each threat agent a class, and each threat a control mapped to SLSA maturity levels and SSDF practices; this matrix is what exposes SLSA's blind spots and justifies where controls should be placed.

What would settle it

Take the paper's traceability matrix and test its 14 threat scenarios against the historical incidents it lists in Table 1: for each incident, check whether the mapped SLSA/SSDF control would actually have prevented or detected the attack. If a significant number of incidents would still succeed despite the mapped controls, such as the SolarWinds build tampering or the Codecov script modification, then the claim of end-to-end coverage is falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that SLSA and STRIDE are complementary: SLSA offers a prescriptive maturity model focused on provenance and artifact integrity, while STRIDE provides a structured method for identifying and analyzing threats across the whole development lifecycle. Together, the paper argues, they enable end-to-end threat coverage from source to deployment, with SSDF supplying the operational practices that secure the pre-build and developer side of the pipeline. The paper demonstrates this by evaluating SLSA levels against each STRIDE category and showing that threats such as DoS on build runners, spoofing of developer identities or tokens, secrets leaking through logs, and broader privilege escalation are not fully addressed by SLSA alone. It then builds a composite framework, STRIDE plus SLSA plus SSDF, anchored by an asset inventory and a threat-to-control traceability matrix.

Load-bearing premise

The framework's threat-to-control mappings are assumed to be correct and complete for real-world pipelines, even though the paper itself states that empirical testing in diverse organizational settings is still needed.

Editorial extensions

If this is right

  • Teams that adopt the framework can see exactly which STRIDE categories a given SLSA level covers and which it leaves open, so they can add controls for the uncovered threats rather than assuming provenance is enough.
  • The stage-wise mapping tells teams where to enforce each control: MFA and secret scanning at the source stage, signing and provenance checks at build, policy approvals and drift detection at deployment, and audit logging and monitoring throughout.
  • Because every control references either a SLSA level or an SSDF practice, the resulting pipeline posture can be documented and audited against SP 800-218 and SLSA expectations without a separate security exercise.
  • The toolchain integration shows the controls are implementable with existing DevSecOps tools, so Security-as-Code and shift-left/shield-right can be operationalized rather than remaining abstract principles.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • One implication the paper leaves implicit is that its traceability matrix could be encoded as machine-readable policy, such as OPA/Rego rules or CI linters, so that a pipeline step is blocked automatically when the required control is absent, turning the framework into an executable compliance gate.
  • A testable extension follows from the paper's gap analysis: pipelines that apply STRIDE-derived controls before adopting SLSA provenance should experience fewer realized supply-chain compromises than pipelines that rely on SLSA alone, and a comparative case study across comparable projects could measure this.
  • Because the STRIDE categories are generic, the asset inventory and threat-agent tables could carry over to adjacent ecosystems such as package registries, cloud-native runtime environments, and AI model supply chains, although the paper only lists these as future work.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes a STRIDE-based threat-modeling framework for CI/CD pipelines, using a representative architecture (GitHub, Jenkins, Docker, Kubernetes). It contributes a Data Flow Diagram with an asset inventory and threat-agent taxonomy, a stage-wise threat-to-control traceability matrix, SLSA and SSDF alignment, and a toolchain integration strategy. The central claim is that combining STRIDE with SLSA and SSDF enables end-to-end threat coverage across the CI/CD lifecycle. The evaluation in §9 is a qualitative self-assessment; §9.4 explicitly acknowledges the need for empirical testing.

Significance. If the threat-control mappings are sound, the framework provides a useful structured catalog for practitioners: it systematically walks through source, build, deployment, and monitoring stages, connects concrete threats (e.g., stolen SCM credentials, dependency confusion, artifact tampering) to both SLSA maturity levels and SSDF practices, and gives a practical toolchain mapping. The paper's strengths include a detailed asset/threat-agent inventory, the real-world incident mapping in Table 1, and a traceable presentation that is easy to adapt. However, the central 'end-to-end coverage' claim is not supported by the paper's own traceability matrices, and the evaluation is not empirical. As a conceptual proposal, the work is a reasonable starting point, but its scientific claims need to be substantially qualified.

major comments (4)
  1. [§5.1.3, §7.4.2, Tables 3, 7–10] The claim that STRIDE and SLSA 'together enable end-to-end threat coverage across the CI/CD lifecycle' is contradicted by the paper's own data. Table 3 states that Denial of Service is not addressed by SLSA at any level, and the traceability matrix (Tables 7–10) contains only one DoS-flagged threat, T14, which appears twice under different descriptions and is assigned to build/artifact storage and monitoring, not to source or deployment stages where Table 4 lists DoS as typical. Repudiation is also thin: only a handful of rows are R-flagged, and seven threats (T1, T2, T4, T6, T8, T9, T13) have 'SLSA: None'. The union of STRIDE+SLSA does not demonstrate full STRIDE coverage. I recommend adding an explicit coverage matrix that shows, for each STRIDE category and each pipeline stage, which framework(s) provide controls and where residual gaps remain, or softening the §5.1.3 claim to 'complementary coverage with identified residual gaps'.
  2. [§7.4.2, Tables 8–9, Table 11] The traceability matrix uses duplicate threat IDs inconsistently. T14 in Table 8 ('Malicious artifact pushed or deleted from repository') has STRIDE flags including R, I, D, E, while T14 in Table 9 ('Lack of logging or monitoring...') has a different description and different STRIDE flags. Table 11 also lists T14 four times (artifact signing, RBAC, immutability, audit logs) and T9 twice. This breaks the promised traceability from threat to control and means the matrices cannot be audited as a unique mapping. All threat IDs should be unique, with consistent descriptions, STRIDE classifications, and references across Tables 7–11.
  3. [§7.4.1] The 'control-centric' threat-to-stage assignment is problematic for the end-to-end coverage claim. By assigning each threat to the stage where a control can be applied rather than the stage where the threat originates or manifests, the matrix can create the appearance of coverage at a stage even when the threat is not detected or prevented there. For example, a source-originated threat assigned to the build stage does not actually provide source-stage visibility. The paper should distinguish 'threat origin' from 'control placement' in the matrix, and the coverage analysis should be based on origin stage, not only control stage.
  4. [§9, §9.4] The section titled 'Evaluation and Discussion' does not contain an evaluation in the empirical sense; §9.1 is a self-assessment of the framework's own mappings, and §9.4 explicitly concedes 'Need for empirical testing.' Given this, the abstract and conclusion should not imply demonstrated effectiveness. The contributions should be reframed as a proposed, yet-to-be-validated framework and catalog, or the paper should include at least a pilot study or case-based validation. This is not a fatal flaw for a qualitative proposal, but the current wording overstates the evidence.
minor comments (6)
  1. [Abstract, Keywords] There are formatting artifacts such as 'STRIDE-B ased' in the title and 'threat modelling' vs. 'threat modeling' inconsistently used throughout; the keywords line also appears to have spacing issues.
  2. [§4.1] Typo: 'Continuos Integration' should be 'Continuous Integration'.
  3. [General, Tables 7–10] The OWASP references are written as 'OW ASP' with an extra space in many places; also the STRIDE checklists use tick/cross symbols that should be explained in a table legend.
  4. [§10] The section is labeled 'VIII. Conclusion and Future Work' but the paper has not used Roman numerals elsewhere; this appears to be a leftover from a different template.
  5. [References] Several references are incomplete, missing venue, year, or consistent formatting (e.g., [3], [5], [7] are given as 'Accessed: 2025-05-27' with no publication venue). The paper would benefit from a consistent citation style.
  6. [Figure/Table numbering] Tables 7–10 are introduced in §7.4.2 but §7.4.3 refers to a 'summary' that is not presented as a table; consider adding a summary coverage table to make the traceability conclusions easier to verify.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper presents a qualitative threat-modeling and control-mapping framework with no fitted parameters, self-citation chain, or derivation that reduces to its own inputs.

full rationale

The paper does not contain a mathematical derivation chain or fitted predictive model. Its method is a structured qualitative analysis: define a representative CI/CD pipeline, apply the externally defined STRIDE threat categories, map threats to controls from SLSA, SSDF, and OWASP, and present a traceability matrix. None of the STRIDE categories, SLSA levels, or SSDF practices are defined by the paper in terms of its own conclusions; they are imported from independent, external sources. The central claim that STRIDE and SLSA 'together enable end-to-end threat coverage' is a design assertion based on the constructed mapping, not a result derived from data or from a self-citation. The paper includes no self-citations by the author, and its evaluation in Section 9.1 is a self-assessment of the framework's own matrix rather than an empirical test. While this self-referential validation is a methodological limitation, it is not circularity: the paper explicitly acknowledges in Section 9.4 the 'Need for empirical testing' and calls for 'further testing in diverse organizational settings.' No step in the paper reduces a prediction to a fitted input or defines a premise in terms of its conclusion, so no circular step is present.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no free parameters or invented entities; it is a qualitative synthesis of existing frameworks. The central claim rests on four domain assumptions: the validity of STRIDE, the accuracy of SLSA/SSDF, the representativeness of the modeled pipeline, and the effectiveness of the proposed control mappings. The last is an ad hoc assumption to the paper, explicitly acknowledged as unvalidated in §9.4.

assumptions (4)
  • domain assumption STRIDE is a valid and sufficient threat modeling methodology for CI/CD pipelines.
    The paper applies STRIDE categories (Spoofing, Tampering, Repudiation, etc.) without comparing to other methodologies (PASTA, LINDDUN, etc.). See §3.2 and §4.2.
  • domain assumption SLSA levels 1-4 and SSDF practices accurately capture supply chain security controls.
    The control mappings in §7.4 rely on the frameworks as given, without questioning their validity. See §4.3 and §4.4.
  • domain assumption The representative pipeline (GitHub, Jenkins, Docker, Kubernetes) is representative of common industry practice.
    The threat analysis generalizes from one modeled architecture to CI/CD pipelines broadly. See §3.1.
  • ad hoc to paper The proposed controls effectively mitigate the identified threats when implemented.
    This is the central thesis; the paper provides no empirical evidence, and §9.4 calls for 'empirical testing'.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Enhancing Software Supply Chain Security Through STRIDE-Based Threat Modelling of CI/CD Pipelines." pith.science (2026). https://pith.science/paper/6VFKHHG4

@misc{pith2026250606478,
  author       = {Pith},
  title        = {Pith review of: Enhancing Software Supply Chain Security Through STRIDE-Based Threat Modelling of CI/CD Pipelines},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6VFKHHG4}},
  note         = {Machine review of arXiv:2506.06478}
}
read the original abstract

With the increasing adoption of Continuous Integration and Continuous Deployment pipelines, securing software supply chains has become a critical challenge for modern DevOps teams. This study addresses these challenges by applying a structured threat modeling approach to identify and mitigate risks throughout the CI/CD lifecycle. By modeling a representative pipeline architecture incorporating tools such as GitHub, Jenkins, Docker, and Kubernetes and applying the STRIDE framework, we systematically analyze vulnerabilities at each stage, from source code management to deployment. Threats are documented and mapped to comprehensive security controls drawn from standards like NIST SP 800-218, OWASP Top 10 CI/CD risks, and the SLSA framework. Controls are further evaluated against SLSA maturity levels to assess improvements in trust and provenance. To operationalize these findings, the study outlines a practical security toolchain integration strategy grounded in Security as Code and Shift Left-Shield Right principles, enabling automated, enforceable security across the pipeline. This approach provides a pragmatic roadmap for enhancing CI/CD pipeline security against evolving software supply chain threats.

Figures

Figures reproduced from arXiv: 2506.06478 by the authors.

Figure 1
Figure 1. Typical CI/CD Pipeline A typical CI/CD pipeline in [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Proposed Composite (STRIDE+SLSA+SSDF) Framework [PITH_FULL_IMAGE:figures/full_fig_p012_2.png] view at source ↗
Figure 3
Figure 3. CI/CD Pipeline Data Flow Diagram 7.2 Asset Inventory Based on the DFD, we identified critical assets that represent potential targets for adversaries. Each asset is assigned a unique identifier (e.g., AS#) to facilitate cross-referencing in the threat traceability and control mapping tables that follow [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages

  1. [1]

    SLSA: Supply-chain Levels for Software Artifacts

    “SLSA: Supply-chain Levels for Software Artifacts.” https://slsa.dev. Accessed: 2025-05-27

    work page 2025

  2. [2]

    in-toto: Providing farm-to-table guarantees for bits and bytes,

    S. Torres-Arias et al. , “in-toto: Providing farm-to-table guarantees for bits and bytes,” in USENIX Security Symposium, 2019

    work page 2019

  3. [3]

    An integrity-focused threat model for software development pipelines,

    B. M. Reichert and R. R. Obelheiro, “An integrity-focused threat model for software development pipelines,” 2022. Accessed: 2025-05-27

    work page 2022

  4. [4]

    Ambush from all sides: Understanding security threats in open-source software ci/cd pipelines,

    Z. Pan et al., “Ambush from all sides: Understanding security threats in open-source software ci/cd pipelines,” IEEE Transactions on Dependable and Secure Computing , vol. 21, no. 1, pp. 403–418, 2024

    work page 2024

  5. [5]

    Analyzing challenges in deployment of the slsa framework for software supply chain security,

    M. Tamanna, S. Hamer, M. Tran, S. Fahl, Y . Acar, and L. Williams, “Analyzing challenges in deployment of the slsa framework for software supply chain security,” 2024. Accessed: 2025-05-27

    work page 2024

  6. [6]

    Argo-slsa: Software supply chain security in argo workflows,

    M. Thariq and I. Ekanayake, “Argo-slsa: Software supply chain security in argo workflows,” 2024. Preprint. 19 Enhancing Software Supply Chain Security through STRIDE-Based Threat Modelling of CI/CD Pipelines

    work page 2024

  7. [7]

    An industry interview study of software signing for supply chain security,

    K. G. Kalu, T. Singla, C. Okafor, S. Torres-Arias, and J. C. Davis, “An industry interview study of software signing for supply chain security,” 2024. Accessed: 2025-05-27

    work page 2024

  8. [8]

    Research directions in software supply chain security,

    L. Williams et al. , “Research directions in software supply chain security,” ACM Transactions on Software Engineering and Methodology, 2025

    work page 2025

Show all 25 references
  1. [9]

    Codecov bash uploader security update

    Codecov, “Codecov bash uploader security update.”https://about.codecov.io/apr-2021-post-mortem/ , 2021

    2021

  2. [10]

    January 4, 2023 - security alert

    CircleCI, “January 4, 2023 - security alert.” https://circleci.com/blog/ jan-4-2023-incident-report/ , 2023

    2023

  3. [11]

    Xcodeghost malware analysis

    Palo Alto Networks, “Xcodeghost malware analysis.” https://unit42.paloaltonetworks.com/ novel-malware-xcodeghost-modifies-xcode-infects-apple-ios-apps-and-hits-app-store/ , 2015

    2015

  4. [12]

    Sunburst malware technical analysis

    CrowdStrike, “Sunburst malware technical analysis.” https://www.crowdstrike.com/en-us/blog/ sunspot-malware-technical-analysis/ , 2020

    2020

  5. [13]

    Php git server breach

    PHP Internals, “Php git server breach.” https://news-web.php.net/php.internals/113838, 2021

    2021

  6. [14]

    Security incident disclosure

    Homebrew, “Security incident disclosure.” https://brew.sh/2021/04/21/ security-incident-disclosure/ , 2021

    2021

  7. [15]

    Event-stream npm supply chain attack

    Event-Stream Incident Report, “Event-stream npm supply chain attack.” https://es-incident.github.io/ paper.html, 2018

    2018

  8. [16]

    Jetbrains teamcity servers under attack

    SCWorld, “Jetbrains teamcity servers under attack.” https://www.scworld.com/news/ echoes-of-solarwinds-jetbrains-teamcity-servers-under-attack-by-russia-backed-hackers , 2020

    2020

  9. [17]

    Uber aws credentials leak

    Breaches Cloud, “Uber aws credentials leak.” https://www.breaches.cloud/incidents/uber/, 2016

    2016

  10. [18]

    Github oauth compromise

    Cycode, “Github oauth compromise.”https://cycode.com/blog/github-oauth-compromise-affecting-heroku-and-travis-ci-users/ , 2022

    2022

  11. [19]

    Slack github token breach

    Cybersecurity Dive, “Slack github token breach.” https://www.cybersecuritydive.com/news/ slack-tokens-stolen-github-breached/639721/ , 2015

    2015

  12. [20]

    Crypto mining via github actions

    Security Affairs, “Crypto mining via github actions.” https://securityaffairs.com/133125/malware/ cryptocurrency-mining-cloud-infrastructure.html , 2021

    2021

  13. [21]

    Malicious campaigns overwhelm npm

    SCWorld, “Malicious campaigns overwhelm npm.” https://www.scworld.com/analysis/ malicious-campaigns-overwhelm-open-source-ecosystems-dos-npm , 2022

    2022

  14. [22]

    Pypi flooding attack

    Sonatype, “Pypi flooding attack.” https://www.sonatype.com/blog/ attacker-floods-pypi-with-450-malicious-packages-that-drop-windows-trojan-via-dropbox , 2022

    2022

  15. [23]

    Github actions pull_request_target rce

    Endor Labs, “Github actions pull_request_target rce.” https://www.endorlabs.com/learn/ pwn-request-threat-a-hidden-danger-in-github-actions , 2021

    2021

  16. [24]

    Travis ci misconfigured permissions

    Aqua Security, “Travis ci misconfigured permissions.” https://www.aquasec.com/blog/ travis-ci-security/, 2021

    2021

  17. [25]

    Azure devops zero click ci/cd vulnerability

    Legit Security, “Azure devops zero click ci/cd vulnerability.” https://www.legitsecurity.com/blog/ azure-devops-zero-click-ci/cd-vulnerability , 2022. 20

    2022

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.