Towards Socio-Technical Topology-Aware Adaptive Threat Detection in Software Supply Chains

Brynj\'olfur Stef\'ansson; Helmut Neukirchen; Krist\'ofer Finnsson; Thomas Welsh

REVIEW 3 major objections 4 minor 42 references

Towards Socio-Technical Topology-Aware Adaptive Threat Detection in Software Supply Chains

T0 review · 3 major / 4 minor · reviewed 2026-08-04 · deepseek-v4-flash

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

Pith's one-line read This position paper argues that monitoring both the technical and social activity around open-source code—commit sizes, influence, timing, sentiment, and writing style—can flag developing supply-chain attacks early enough to focus vulnerabi

desk verdict Position paper with a novel STT formalization and an interesting but unvalidated XZ case study; the vision is worth engaging, but the evidence doesn't yet support the specificity claim. read the letter →

arxiv 2510.21452 v1 pith:QKOTIMBD submitted 2025-10-24 cs.SE cs.CRcs.SI

Thomas Welsh , Kristófer Finnsson , Brynjólfur Stefánsson , Helmut Neukirchen This is my paper · ORCID

classification cs.SEcs.CRcs.SI

keywords softwaresupplychainsocio-technicalmodelingthreatdetectionanomalydeveloperbehaviorMAPE-Kcommitanalysissocialengineering

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

The paper argues that the technical and social activity around open-source software can be monitored together to detect the early signs of a supply-chain subversion before a backdoor is shipped. Using the 2024 backdoor in a widely used compression library as a case study, the authors show that the attacker's account exhibited measurable anomalies: unusually large per-file changes, rising influence over the code base, commits at unusual times of day, declining sentiment, and a writing style that clustered into two distinct voices. On this basis they propose a framework that builds a 'socio-technical topology'—a graph tying files, dependencies, authors, relationships, and influence metrics—and runs it through an adaptive monitor-analyse-plan-execute loop that filters components where social and technical changes coincide, then sends those components to deep vulnerability testing. The payoff, if the approach works, is that scarce audit effort is concentrated on the components actually trending toward an insecure state, rather than spread evenly across a supply chain too large to fully inspect.

What carries the argument

The formal engine is the socio-technical topology, defined as a tuple of sets and functions (sources, dependency edges, authors, author relationships, relationship parameters, relationship weights, maintainer-file membership, activity kinds, and per-activity influence counts). The approach compares topology snapshots over time (ΔSTT) and applies two filters—one selecting files tied to changed author relationships with weight above a threshold, one selecting files whose influence scores changed above a threshold—and only the intersection is escalated to vulnerability feasibility analysis, reachability tracing, and testing. The MAPE-K adaptive loop is the control mechanism that keeps the topol

What would settle it

Apply the same indicator set prospectively to a large corpus of open-source repositories without knowledge of any attack outcomes: if a comparable fraction of healthy projects shows the same combination of peaks in commit size, centrality, off-hours commits, negative sentiment, and multiple writing clusters, the claim would fail; conversely, a blind test that ranks the compromised compression-library project near the top before the backdoor's public disclosure would support it.

Watch

Extended reading notes

Core claim

The paper's central claim is that integrating technical and social data and analysing their trends can flag anomalous developer behaviour that indicates subversion and threats. In the motivating case, a malicious contributor gained maintainer trust over two years and then inserted an obfuscated backdoor; the authors' retrospective measurements show that during the escalation and backdoor stages, that contributor's commit sizes became both larger and more variable than a legitimate maintainer's, their network centrality in the repository's file-author graph spiked, commits appeared at atypical times of day, communication sentiment turned negative, and a clustering of lexical and syntactic fea

Load-bearing premise

The analysis is retrospective: the indicators were selected after the attack was known, and the paper assumes that the same anomalies would have stood out as suspicious in real time and that they appear rarely enough in healthy open-source projects to be useful.

Editorial extensions

If this is right

Vulnerability auditing can shift from scanning everything to inspecting a small set of components where social and technical signals move together.
Supply-chain monitors that already collect commit and issue data can add sentiment and writing-style analysis to their indicator set.
The same topology model could be extended to trace reachability of a suspected vulnerability both upstream and downstream of the flagged component.
Because the framework is adaptive, it can respond to changes in project structure and developer population over time, not just static snapshots.
A controlled test bed spanning design to deployment would be needed to compare adaptive socio-technical detection against non-adaptive baselines.

Reading between the lines

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

The indicator set could be tested prospectively against earlier supply-chain attacks (for example, the event-stream or ua-parser-js incidents) to see whether the same signature of trust-building plus abrupt influence spikes recurs; the paper does not run this check.
A determined attacker who knows these signals could adapt—normalizing commit sizes, writing in a single consistent style, and keeping regular hours—so the approach's long-term value depends on whether the adversary is unaware or unable to mimic the baseline.
The paper treats 'nominal behaviour' as learnable per project, but the thresholds are project-specific; an implicit testable prediction is that cross-project transfer of thresholds will perform poorly, so each repository needs its own calibration period.
The falsifiable core is that the joint distribution of these signals differs between malicious and benign development; that difference is asserted from a single retrospective case and is the natural target for a large-scale corpus study.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Colleague,

You should know this paper is a position piece, not an empirical validation. The XZ Utils analysis is a motivating example, and the authors are clear about that. What's actually new: they extend their earlier topology-aware adaptive inspection from cyber-physical supply chains to software supply chains, add a formal STT tuple (source files, dependencies, authors, relationships, weights, maintainer-file influence), and run a multi-signal case study on XZ Utils – commit size, centrality, commit timing, sentiment, and writing-style clustering – that suggests the 'Jia Tan' account may have been used by more than one person. That specific combination is not in the prior literature.

The paper is well-written and honest. It flags its own limitations: thresholds W and I are deferred to learning 'nominal behaviour,' the clustering k is chosen experimentally, and it acknowledges that off-hours commits alone appeared during benign periods. The limitations section also calls for a testbed and says sparse attack data makes evaluation hard. That kind of candor is appreciated.

The soft spots are real but proportionate to the genre. The case study is retrospective with no baseline or control projects, so the false-positive rate of the indicators is unmeasured. Without a comparison to benign projects, the central claim that these signals can 'target' intensive vulnerability assessment is suggestive, not demonstrated. The k=2 clustering was picked because it 'separated clusters best,' which is post hoc. Sentiment analysis relies on very few data points. These are not fatal for a position paper, but they do mean the empirical weight is low.

Who benefits? Researchers working on supply-chain security who want a clear research agenda and a set of testable hypotheses. It's not a result paper, and it shouldn't be read as one. The central vision – adaptively combining social and technical signals to prioritize analysis – is plausible, but this paper doesn't show it works.

I'd send it to peer review: a serious referee could push the authors to either add a benign-project control or explicitly label the case study as anecdotal. For a workshop or a vision track, it's near-acceptable as is; for a full archival journal, the empirical gap would need more work.

Recommendation: engage with it, but don't treat the XZ analysis as evidence until there's a control.

Referee Report

3 major / 4 minor

Summary. This paper presents a position and research vision for 'Socio-Technical Adaptive SSC Threat Detection' in software supply chains. The authors propose building and monitoring multi-dimensional socio-technical topologies that combine technical data (commits, file changes, dependency structure) with social data (author relationships, communication sentiment, writing style). The motivation is a retrospective analysis of the XZ Utils attack, focusing on the attacker 'Jia Tan'. The analysis reports elevated commit change volumes, rising centrality, atypical commit times, and a k=2 writing-style clustering that the authors interpret as evidence of multiple actors. On this basis they claim that monitoring such integrated signals 'might be used' to identify anomalous developer behaviour and direct targeted vulnerability assessment. The paper then sketches an adaptive MAPE-K framework with a formal topology tuple, filtering equations (Eq. 1-2), and a set of open research challenges, including the need for a supply-chain test bed.

Significance. The paper targets an important and current problem: software supply chain attacks, such as XZ Utils, have demonstrated the difficulty of detecting social-engineering attacks through purely technical measures. The proposed integration of social and technical signals in a topology-aware adaptive monitor is a plausible and original direction, building on the authors' prior work on cyber-physical supply chains (Ref. [7]). The paper is honestly hedged: it calls the analysis an 'initial analysis', explicitly identifies limitations (e.g., limited mailing-list data), and formulates concrete research questions. It does not, however, provide code, data, or reproducible scripts for the analysis, and the empirical grounding is a single post-hoc case study without baselines or statistical tests. The formal topology definition and MAPE-K mapping are useful starting points, but the central claim—that the identified trends can indicate suspicious behaviour—is not yet supported with evidence sufficient to distinguish malicious from benign behaviour. If the authors add a control analysis and refine the empirical claims, the paper would make a stronger contribution.

major comments (3)

[Section III-B, Table I and Figures 1-3] The analysis is entirely retrospective and lacks a control comparison. The central inference—that Jia Tan's commit behaviour is 'anomalous'—is based on comparison with a single legitimate maintainer (Lasse Collin) and on visual inspection of time series. No statistical tests, effect sizes, or confidence intervals are reported for the differences in Table I, and no baseline from benign projects or from the project's own pre-attack history is provided. The paper itself notes (Section III-B) that atypical commit times occurred in benign periods (2023-01), indicating that at least one of the four signals is not specific. Without a control group or a prediction of the attack before it was known, the claim that 'monitoring technical and social data can identify trends which indicate suspicious behaviour' is unsupported.
[Section III-B, Figure 5] The k=2 clustering is chosen post hoc after 'experimenting with different k values'. No model-selection statistic (silhouette, gap, etc.) is given, and no robustness check (e.g., different feature sets, different clustering algorithms) is reported. The inference that two different authors shared the Jia Tan account is therefore not justified. Because the multiple-author signal is one of the pillars of the socio-technical threat indicator set, this weakens the motivating analysis.
[Section IV, Eqs. (1)-(2)] The adaptive detection scheme depends on thresholds W_threshold and I_threshold to filter suspect components. The paper states these 'would need to be determined through monitoring the nominal behaviour of the system', but offers no evidence that stable nominal behaviour can be learned for OSS projects, nor that deviations from such baselines correlate with insecure states. This is a load-bearing assumption: if the thresholds are arbitrary or highly variable across projects, the approach would inherit the false-positive problems attributed to ML-based techniques in Section II. The paper should either present preliminary evidence of learnable baselines or explicitly reframe the framework as a hypothesis to be tested, not a demonstrated method.

minor comments (4)

[Section III-B, Fig. 2] Please specify which centrality measure (degree, betweenness, etc.) is computed and how the author-file network is constructed. Without this, the reader cannot interpret the peaks.
[Section III-B, Table I] The word 'delections' should be 'deletions'. Also, the period ends in June 2024, while the backdoor was exposed in March 2024; clarify whether this period includes post-exposure cleanup commits.
[Section IV, formal model] The tuple STT defines W, I, K, etc., but the time-dependence is introduced only via ΔSTT = STT(t2) − STT(t1). It would help to add a time index to the tuple components or to explain how the model is updated over time.
[Section III-B, final paragraph] Typo: 'it can be see that' should be 'it can be seen that'.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the XZ analysis is retrospective but not fitted to the outcome, and thresholds are explicitly deferred.

full rationale

The paper's central claim is that monitoring social and technical data can identify trends that indicate suspicious behaviour, informing targeted vulnerability assessment. This is motivated by a post-hoc analysis of the XZ Utils attack. No parameter is fitted to the known attack and then reported as a prediction: the proposed thresholds W_threshold and I_threshold are explicitly deferred ('would need to be determined through monitoring the nominal behaviour of the system'), so the framework is not defined in terms of the XZ outcome. The analysis itself is exploratory, and the paper even acknowledges that off-hours commits alone are not anomalous ('benign code had occasionally been submitted at atypical times of day (e.g. 2023-01), so alone, these results might not be seen as anomalous'). The k-means cluster count is chosen by experimentation, but this is not presented as an independent prediction. The self-citation to [7] supplies background for topology-aware adaptive inspection and a resource-allocation motivation, but the paper's contribution—socio-technical indicators for SSC threat detection—does not reduce to that prior work by construction. No definitional identity, fitted-input-as-prediction, or load-bearing self-citation chain is present, so there is no significant circularity.

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

The paper introduces the STT tuple as a formal model but no new physical or conceptual entities (no new particles, forces, etc.). The main free parameters are the clustering k and two detection thresholds. The axioms are domain assumptions about the diagnostic value of socio-technical metrics and the representativeness of the XZ case.

free parameters (3)

k (number of writing-style clusters) = 2
Section III-B: 'k=2 separated clusters best' — chosen post hoc to maximize separation in the data, not from a priori reasoning.
W_threshold
Eq. (1): 'W_threshold and I_threshold would need to be determined through monitoring the nominal behaviour of the system' — a free parameter deferred to future work.
I_threshold
Eq. (2): as above, another deferred threshold for selecting suspicious files based on maintainer influence.

assumptions (4)

domain assumption k-means clustering on syntactic and lexical writing features can separate distinct authors of a shared account
Section III-B applies k-means to sentiment polarity, subjectivity, lexical richness, punctuation frequency, readability, and average sentence length, assuming these features are meaningful author discriminators.
domain assumption Network centrality (unstated variety) of an author in a commit-to-file network measures influence over the codebase
Section III-B and Fig. 2 compute author centrality to infer 'importance' and 'influence' without specifying the centrality measure or its normalization.
domain assumption The XZ Utils attack is representative of socio-technical attacks on software supply chains
The entire motivation is built on one incident; the paper assumes the observed indicator patterns generalize across projects and attack types.
ad hoc to paper Normal behavioral baselines for OSS projects are learnable and stable enough to set thresholds
Section IV.1 states thresholds would be determined by 'monitoring the nominal behaviour of the system' — this presumes the existence of a separable nominal distribution for socio-technical metrics.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Towards Socio-Technical Topology-Aware Adaptive Threat Detection in Software Supply Chains." pith.science (2026). https://pith.science/paper/QKOTIMBD

@misc{pith2026251021452,
  author       = {Pith},
  title        = {Pith review of: Towards Socio-Technical Topology-Aware Adaptive Threat Detection in Software Supply Chains},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QKOTIMBD}},
  note         = {Machine review of arXiv:2510.21452}
}

read the original abstract

Software supply chains (SSCs) are complex systems composed of dynamic, heterogeneous technical and social components which collectively achieve the production and maintenance of software artefacts. Attacks on SSCs are increasing, yet pervasive vulnerability analysis is challenging due to their complexity. Therefore, threat detection must be targeted, to account for the large and dynamic structure, and adaptive, to account for its change and diversity. While current work focuses on technical approaches for monitoring supply chain dependencies and establishing component controls, approaches which inform threat detection through understanding the socio-technical dynamics are lacking. We outline a position and research vision to develop and investigate the use of socio-technical models to support adaptive threat detection of SSCs. We motivate this approach through an analysis of the XZ Utils attack whereby malicious actors undermined the maintainers' trust via the project's GitHub and mailing lists. We highlight that monitoring technical and social data can identify trends which indicate suspicious behaviour to then inform targeted and intensive vulnerability assessment. We identify challenges and research directions to achieve this vision considering techniques for developer and software analysis, decentralised adaptation and the need for a test bed for software supply chain security research.

Figures

Figures reproduced from arXiv: 2510.21452 by the authors.

**Figure 2.** Centrality of author Jia Tan commit times (see later discussion of [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 5.** Author Jia Tan issues’ are clustered (yellow/purple) according to [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

42 extracted references · 1 linked inside Pith

[7]

Topology-aware adaptive inspection for fraud in I4.0 supply chains,

T. Welsh, F. Alrimawi, A. Farahani, D. Hassett, A. Zisman, and B. Nuseibeh, “Topology-aware adaptive inspection for fraud in I4.0 supply chains,”IEEE Trans. Ind. Inform., vol. 19, no. 4, 2022

2022
[1]

SoK: Analysis of software supply chain security by establishing secure design properties,

C. Okafor, T. R. Schorlemmer, S. Torres-Arias, and J. C. Davis, “SoK: Analysis of software supply chain security by establishing secure design properties,” inProc. 2022 ACM Workshop Soft. Supply Chain Offensive Res. and Ecosyst. Defenses, 2022

2022
[2]

(2024) 10th annual state of the software supply chain

Sonatype. (2024) 10th annual state of the software supply chain. Accessed: 2025-03-08. [Online]. Available: https://www.sonatype.com/ state-of-the-software-supply-chain/introduction

2024
[3]

Top five challenges in software supply chain security: Observations from 30 industry and government organizations,

W. Enck and L. Williams, “Top five challenges in software supply chain security: Observations from 30 industry and government organizations,” IEEE Secur. Priv., vol. 20, no. 2, 2022

2022
[4]

Solar winds hack: In-depth analysis and countermeasures,

R. Alkhadra, J. Abuzaid, M. AlShammari, and N. Mohammad, “Solar winds hack: In-depth analysis and countermeasures,” in2021 12th Int. Conf. Computing Commun. Netw. Technologies (ICCCNT). IEEE, 2021

2021
[5]

Defense-in-depth security strategy in log4j vulnerability analysis,

S. Feng and M. Lubis, “Defense-in-depth security strategy in log4j vulnerability analysis,” in2022 Int. Conf. Adv. Data Science, E-learning Inf. Syst. (ICADEIS). IEEE, 2022

2022
[6]

Research directions in software supply chain security,

L. Williamset al., “Research directions in software supply chain security,”ACM Trans. Softw. Eng. Methodol., vol. 34, no. 5, 2025

2025
[8]

Wolves in the repository: A software engineering analysis of the xz utils supply chain attack,

P. Przymus and T. Durieux, “Wolves in the repository: A software engineering analysis of the xz utils supply chain attack,” in2025 IEEE/ACM 22nd Int. Conf. Min. Softw. Repositories (MSR). IEEE, 2025

2025

Show all 42 references

[9]

BOMS away! Inside the minds of stakeholders: A comprehensive study of bills of materials for software systems,

T. Stalnakeret al., “BOMS away! Inside the minds of stakeholders: A comprehensive study of bills of materials for software systems,” inProc. 46th IEEE/ACM Int. Conf.Softw. Eng., 2024

2024
[10]

SoK: Taxonomy of attacks on open-source software supply chains,

P. Ladisa, H. Plate, M. Martinez, and O. Barais, “SoK: Taxonomy of attacks on open-source software supply chains,” in2023 IEEE Symposium Secur. Priv. (SP). IEEE, 2023

2023
[11]

On the critical path to implant backdoors and the effectiveness of potential mitigation techniques: Early learnings from XZ,

M. Lins, R. Mayrhofer, M. Roland, D. Hofer, and M. Schwaighofer, “On the critical path to implant backdoors and the effectiveness of potential mitigation techniques: Early learnings from XZ,”ArXiv e-print 2404.08987, 2024

2024 arXiv
[12]

The secret life of software vulnerabilities: A large-scale empirical study,

E. Iannone, R. Guadagni, F. Ferrucci, A. De Lucia, and F. Palomba, “The secret life of software vulnerabilities: A large-scale empirical study,” IEEE Trans. Softw. Eng., vol. 49, no. 1, 2022

2022
[13]

Influences of developers’ perspectives on their engage- ment with security in code,

I. Raufet al., “Influences of developers’ perspectives on their engage- ment with security in code,” inProc. 15th Int. Conf. Coop. Hum. Asp. Softw. Eng., 2022

2022
[14]

Recog- nizing the known unknowns; the interaction between reflective thinking and optimism for uncertainty among software developer’s security perceptions,

M. Ivory, J. Towse, M. Sturdee, M. Levine, and B. Nuseibeh, “Recog- nizing the known unknowns; the interaction between reflective thinking and optimism for uncertainty among software developer’s security perceptions,”Technol. Mind Behav., vol. 4, no. 3, 2023

2023
[15]

Perceval: software project data at your will,

S. Due ˜nas, V . Cosentino, G. Robles, and J. M. Gonzalez-Barahona, “Perceval: software project data at your will,” inProc. 40th Int. Conf. Softw. Eng.: companion proceeedings, 2018

2018
[16]

Continuously mining distributed version control systems: an empirical study of how Linux uses Git,

D. M. German, B. Adams, and A. E. Hassan, “Continuously mining distributed version control systems: an empirical study of how Linux uses Git,”Empir. Softw. Eng., vol. 21, 2016

2016
[17]

Text filtering and ranking for security bug report prediction,

F. Peters, T. T. Tun, Y . Yu, and B. Nuseibeh, “Text filtering and ranking for security bug report prediction,”IEEE Trans. Softw. Eng., vol. 45, no. 6, 2017

2017
[18]

An anatomy of security conversations in Stack Overflow,

T. Lopez, T. Tun, A. Bandara, L. Mark, B. Nuseibeh, and H. Sharp, “An anatomy of security conversations in Stack Overflow,” in2019 IEEE/ACM 41st Int. Conf. on Softw. Eng.: Softw. Eng. in Soc. (ICSE- SEIS). IEEE, 2019

2019
[19]

Engaging developers in open source software projects: harnessing social and technical data mining to improve software devel- opment,

P. E. Carlson, “Engaging developers in open source software projects: harnessing social and technical data mining to improve software devel- opment,” Ph.D. dissertation, Iowa State University, 2015

2015
[20]

Chat activity is a better predictor than chat sentiment on software developers productivity,

M. Kuutila, M. V . M ˜antyl˜a, and M. Claes, “Chat activity is a better predictor than chat sentiment on software developers productivity,” in Proc. IEEE/ACM 42nd Int. Conf. Softw. Eng., 2020

2020
[21]

Software vulnerability analysis and discovery using machine-learning and data-mining techniques: A survey,

S. M. Ghaffarian and H. R. Shahriari, “Software vulnerability analysis and discovery using machine-learning and data-mining techniques: A survey,”ACM Comput. Surv., vol. 50, no. 4, Aug. 2017. [Online]. Available: https://doi.org/10.1145/3092566

2017 doi
[22]

Quantum machine learning for software supply chain attacks: How far can we go?

M. Masumet al., “Quantum machine learning for software supply chain attacks: How far can we go?” in2022 IEEE 46th Annual Comput., Softw. Appl. Conf. (COMPSAC). IEEE, 2022

2022
[23]

A socio-technical framework for threat modeling a software supply chain,

B. Al Sabbagh and S. Kowalski, “A socio-technical framework for threat modeling a software supply chain,”IEEE Secur. Priv., vol. 13, no. 4, 2015

2015
[24]

Socio-technical systems: From design methods to systems engineering,

G. Baxter and I. Sommerville, “Socio-technical systems: From design methods to systems engineering,”Interact. Comput., vol. 23, no. 1, 2011

2011
[25]

Social engineering attacks prevention: A systematic literature review,

W. Syafitri, Z. Shukur, U. A. Mokhtar, R. Sulaiman, and M. A. Ibrahim, “Social engineering attacks prevention: A systematic literature review,” IEEE access, vol. 10, 2022

2022
[26]

Prepare to fail: creating an incident management plan,

T. Caldwell, “Prepare to fail: creating an incident management plan,” Comput. Fraud Secur., vol. 2012, no. 11, 2012

2012
[27]

Cybersecurity culture: an ill-defined problem,

N. Gcaza and R. V on Solms, “Cybersecurity culture: an ill-defined problem,” inInf. Secur. Edu. Glob. Digital Soc.: 10th IFIP World Conf. Proc. 10. Springer, 2017

2017
[28]

Entanglements and exploits: Sociotechnical security as an analytic framework,

M. Goerzen, E. A. Watkins, and G. Lim, “Entanglements and exploits: Sociotechnical security as an analytic framework,” in9th USENIX Workshop Free Open Commun Internet (FOCI 19), 2019

2019
[29]

Modelling dynamical processes in complex socio- technical systems,

A. Vespignani, “Modelling dynamical processes in complex socio- technical systems,”Nat. Phys., vol. 8, no. 1, 2012

2012
[30]

Estrada,The structure of complex networks: theory and applications

E. Estrada,The structure of complex networks: theory and applications. American Chemical Society, 2012

2012
[31]

Inequality is rising where social network segregation interacts with urban topology,

G. T ´othet al., “Inequality is rising where social network segregation interacts with urban topology,”Nat. Commun., vol. 12, no. 1, 2021

2021
[32]

On the automated man- agement of security incidents in smart spaces,

F. Alrimawi, L. Pasquale, and B. Nuseibeh, “On the automated man- agement of security incidents in smart spaces,”IEEE Access, vol. 7, 2019

2019
[33]

Decentralized self-adaptive systems: A mapping study,

F. Quin, D. Weyns, and O. Gheibi, “Decentralized self-adaptive systems: A mapping study,” in2021 Int. Symposium Softw. Eng. Adaptive Self- Managing Systems (SEAMS). IEEE, 2021

2021
[34]

XZ timeline,

R. Cox, “XZ timeline,” 2024, accessed: 2025-03-07. [Online]. Available: https://research.swtch.com/xz-timeline

2024
[35]

XZ backdoor story, part 2: Social engineering,

Kaspersky Securelist, “XZ backdoor story, part 2: Social engineering,” 2024, accessed: 2025-03-07. [Online]. Available: https://securelist.com/ xz-backdoor-story-part-2-social-engineering/112476

2024
[36]

CVE-2024-3094,

MITRE, “CVE-2024-3094,” 2024, accessed: 2025-03-07. [Online]. Available: https://www.cve.org/CVERecord?id=CVE-2024-3094

2024
[37]

(2025) XZ Utils

The Tukaani Project. (2025) XZ Utils. GitHub repository https://github. com/tukaani-project/xz. Accessed: 2025-03-11

2025
[38]

(2025) XZ Utils mailing list archives

——. (2025) XZ Utils mailing list archives. https://www.mail-archive. com/xz-devel@tukaani.org/. Accessed: 2025-03-11

2025
[39]

Centrality and network flow,

S. P. Borgatti, “Centrality and network flow,”Soc. Netw., vol. 27, no. 1, 2005

2005
[40]

S. Bird, E. Klein, and E. Loper,Natural language processing with Python: analyzing text with the natural language toolkit. O’Reilly Media, Inc., 2009

2009
[41]

S. Loria. (2018) TextBlob documentation. Release 0.15. [Online]. Available: https://textblob.readthedocs.io

2018
[42]

Scikit-learn: Machine learning in Python,

F. Pedregosaet al., “Scikit-learn: Machine learning in Python,”J. Mach. Learn. Res., vol. 12, 2011

2011

Pith tools

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

[1] [7]

Topology-aware adaptive inspection for fraud in I4.0 supply chains,

T. Welsh, F. Alrimawi, A. Farahani, D. Hassett, A. Zisman, and B. Nuseibeh, “Topology-aware adaptive inspection for fraud in I4.0 supply chains,”IEEE Trans. Ind. Inform., vol. 19, no. 4, 2022

2022

[2] [1]

SoK: Analysis of software supply chain security by establishing secure design properties,

C. Okafor, T. R. Schorlemmer, S. Torres-Arias, and J. C. Davis, “SoK: Analysis of software supply chain security by establishing secure design properties,” inProc. 2022 ACM Workshop Soft. Supply Chain Offensive Res. and Ecosyst. Defenses, 2022

2022

[3] [2]

(2024) 10th annual state of the software supply chain

Sonatype. (2024) 10th annual state of the software supply chain. Accessed: 2025-03-08. [Online]. Available: https://www.sonatype.com/ state-of-the-software-supply-chain/introduction

2024

[4] [3]

Top five challenges in software supply chain security: Observations from 30 industry and government organizations,

W. Enck and L. Williams, “Top five challenges in software supply chain security: Observations from 30 industry and government organizations,” IEEE Secur. Priv., vol. 20, no. 2, 2022

2022

[5] [4]

Solar winds hack: In-depth analysis and countermeasures,

R. Alkhadra, J. Abuzaid, M. AlShammari, and N. Mohammad, “Solar winds hack: In-depth analysis and countermeasures,” in2021 12th Int. Conf. Computing Commun. Netw. Technologies (ICCCNT). IEEE, 2021

2021

[6] [5]

Defense-in-depth security strategy in log4j vulnerability analysis,

S. Feng and M. Lubis, “Defense-in-depth security strategy in log4j vulnerability analysis,” in2022 Int. Conf. Adv. Data Science, E-learning Inf. Syst. (ICADEIS). IEEE, 2022

2022

[7] [6]

Research directions in software supply chain security,

L. Williamset al., “Research directions in software supply chain security,”ACM Trans. Softw. Eng. Methodol., vol. 34, no. 5, 2025

2025

[8] [8]

Wolves in the repository: A software engineering analysis of the xz utils supply chain attack,

P. Przymus and T. Durieux, “Wolves in the repository: A software engineering analysis of the xz utils supply chain attack,” in2025 IEEE/ACM 22nd Int. Conf. Min. Softw. Repositories (MSR). IEEE, 2025

2025