Taxonomy of Attacks on Open-Source Software Supply Chains

Motivation

• Open-source supply chain attacks inject malicious code into components to compromise downstream users, with incidents demonstrating substantial reach and impact.SolarWinds Orion was downloaded by approximately 18,000 customers, including government agencies and critical-infrastructure providers.Source: §I · p. 1

Research gap

• Existing research lacks a comprehensive, comprehensible, and general description of how attackers inject malicious code into OSS projects across technologies and stakeholders.Source: §I · p. 1

Research questions

• The study asks which general attack vectors and safeguards exist, how attack vectors can be represented usefully, and how safeguards are assessed and used.Source: §I · p. 1

Contributions

• The work contributes a taxonomy of 107 unique OSS supply-chain attack vectors represented as an attack tree and validated by 17 domain experts.Source: §I · pp. 1–2
• It also provides 33 safeguards assessed by experts and reports a qualitative assessment by 134 developers of attack awareness and protection.Source: §I · p. 2

Systems

• The modeled systems are VCSs, build systems, and package repositories, which may be roles implemented by one host or third-party service.Source: A. Systems · p. 2
• VCSs host project code and metadata, build systems transform code into binary artifacts while resolving dependencies, and distribution platforms deliver artifacts to downstream users.Source: A. Systems · p. 2

Stakeholders

• Stakeholder roles include maintainers, contributors, consumers, and system or service administrators, with multiple roles potentially held by one individual.Source: B. Stakeholders · pp. 2–3

Consumption

• Package managers automate OSS downloads and installation, including resolution of transitive dependencies, across the technology stack and development lifecycle.Source: C. Risks of Open-Source Software… · p. 3

Attack surface

• Unknown stakeholders, distributed systems, limited consumer visibility, and many dependencies multiply the attack surface and make rigorous consumer review impractical.Source: C. Risks of Open-Source Software… · p. 3

Attack-tree model

• Attack trees refine an attacker’s top-level goal into subgoals, with leaves representing increasingly concrete and actionable tasks.Source: D. Attack Tree · p. 3
• The taxonomy assumes disjunctive refinement, so child nodes represent alternative ways to reach a parent goal.Source: D. Attack Tree · p. 3

Attacker model

• The attacker’s goal is to place malicious code in OSS artifacts so it executes in downstream projects, while insider attacks and privileged access are out of scope.Source: E. Attacker Model · p. 3

Methodology

• The methodology has three phases: literature review, taxonomy and safeguard modeling, and validation through expert and developer surveys.Source: §III · p. 3

Systematic Literature Review

• The systematic literature review searched four digital libraries, reduced 1,025 deduplicated results to 99 included papers, and added 84 studies through snowballing.Source: Search Strategy · p. 4

Literature analysis

• The selected scientific literature comprised 183 works reviewed for common threats, attack vectors, and related safeguards.Source: Data Extraction · p. 4
• Grey literature was added to cover real-world attacks and vulnerabilities, using searches, filtering criteria, and snowballing.Source: B. Grey Literature · p. 4

Attack modeling

• Attack vectors were classified by analyzing OSS supply-chain stakeholders, systems, and relationships before attack-tree modeling.Source: C. Analysis and Modeling of the Attack… · p. 4
• Closed card-sorting and tree-testing supported construction of the attack-tree taxonomy using an attack-centric methodology.Source: C. Analysis and Modeling of the Attack… · pp. 4–5
• The resulting structure identified 107 attack vectors instead of 19, organized by ecosystem interference, supply-chain stage, and involved systems or stakeholders.Source: C. Analysis and Modeling of the Attack… · p. 5

Safeguard mapping

• Safeguards were classified by control type and stakeholder involvement, then mapped to the shallowest attack-tree nodes they partially or fully mitigate.Source: D. Identification and Classification… · p. 5

Survey audiences

• 17 experts validated the attack taxonomy and assessed safeguard utility and costs, while developers rated attack awareness and perceived protection.Developers could optionally assess taxonomy comprehensibility, usefulness, and safeguard use from an open-source consumer perspective.Source: E. Survey Methodology · p. 5

Taxonomy

• Tree-testing assessed how easily experts assigned attack vectors to first-level nodes before they explored the complete taxonomy.The expert questionnaire then collected ratings of structure, node names, coverage, and usefulness.Source: Questionnaire Design and Development · p. 5

Safeguards

• Experts assessed selected safeguards’ utility and costs, whereas developers rated safeguards relevant to their roles, including use and perceived costs when opting in.Safeguards were presented according to stakeholder roles involved in implementation.Source: Questionnaire Design and Development · p. 5

Survey refinement

• The surveys were refined through user-research interviews and pretests involving 37 researchers and 14 master students.Feedback focused on shortening texts and improving presentation, especially for tree-testing content.Source: Pilot Survey and Pretest · p. 5

Sampling

• Snowball sampling recruited participants through professional networks, emails, LinkedIn, and presentations, so response rates could not be computed.The expert pool included relevant academic and industry experts; developers were recruited from practitioner networks.Source: Sampling · p. 5

Timing and participation

• The expert survey ran from 22 July 2021 and the developer survey from 19 October 2021, with both closing on 24 November 2021.The campaigns reached 17 experts and 134 developers.Source: Sampling · p. 5

Taxonomy scope

• The analysis describes the taxonomy as built from 107 unique attack vectors collected through scientific and grey literature.The section also summarizes validation by experts and developers regarding awareness, understandability, and usefulness.Source: §IV · p. 6

Attacker goal

• The attacker’s goal is to inject malicious code into OSS artifacts so downstream users download and execute it during installation or runtime.Targets may include libraries, word processors, direct consumers, or selected victims through conditional execution.Source: A. Taxonomy of Attacks on OSS Supply… · p. 6

Taxonomy structure

• The attack tree’s first-level nodes represent different degrees of interference with existing packages.The tree unfolds below the high-level goal described for downstream execution.Source: A. Taxonomy of Attacks on OSS Supply… · p. 6

Distinct malicious packages

• Developing and advertising a distinct malicious package involves creating an OSS project for malware distribution and attracting victims through repositories such as PyPI, npm, Docker Hub, or NuGet.Real-world examples affect all four named platforms.Source: A. Taxonomy of Attacks on OSS Supply… · p. 6

Name confusion

• Name-confusion attacks deploy artifacts whose names resemble legitimate projects, suggest trustworthy authors, or exploit common naming patterns.Sub-techniques include combosquatting, altered word order, manipulated separators, and typosquatting.Source: A. Taxonomy of Attacks on OSS Supply… · p. 6

Legitimate-package compromise

• Subverting a legitimate package requires corrupting one or more project resources, producing a larger subtree with repeated user and system compromise branches.The section then focuses on sub-techniques of this first-level category.Source: A. Taxonomy of Attacks on OSS Supply… · p. 6

Codebase tampering

• Codebase injection can affect downstream users of both source and pre-built binary artifacts because malicious code becomes part of project builds and distribution.Attackers may contribute hypocrite merge requests, hide code through IDE-rendering weaknesses, or obtain maintainer privileges.Source: Inject into Sources of Legitimate… · p. 6
• Attackers can bypass contribution workflows by tampering with version-control systems through compromised accounts or configuration and software vulnerabilities.These paths provide insecure access to the legitimate project’s codebase.Source: Inject into Sources of Legitimate… · p. 6

Build-time injection

• Pre-built components can receive malicious code during build before publication, making detection more difficult, especially for compiled languages.Compared with source injection, this route has more limited spread but can conceal malicious code inside compiled packages.Source: Inject During the Build of Legitimate… · p. 8

Package distribution

• Distribution attacks tamper with package repositories, mirrors, CDNs, proxies, or other systems involved in hosting and downloading pre-built packages.The taxonomy includes mechanisms affecting package distribution and download across public and narrower-scope repositories.Source: Distribute Malicious Version of… · p. 8

Taxonomy basis

• 107 unique attack vectors were generalized from 183 scientific papers and grey literature, supported by 94 real-world attacks or vulnerabilities.The taxonomy was subsequently refined using domain-expert feedback.Source: Distribute Malicious Version of… · p. 8

Expert validation

• 234 of 311 expert tree-test assignments matched the initial structure, corresponding to 75% agreement.The test evaluated assignment of attack vectors to first-level nodes before experts saw the full taxonomy.Source: Validation · p. 8
• 14 of 17 experts, or 82%, rated the overall taxonomy structure 4 or 5 on a five-point scale.The authors suggest that some node names may have been insufficiently self-explanatory without context.Source: Validation · p. 8
• 12 of 17 experts, or 71%, agreed that the attack tree was complete.This result concerns expert assessment of attack-tree completeness.Source: Validation · p. 8

Usefulness

• 15 experts, or 88%, rated the taxonomy useful for understanding the OSS supply-chain attack surface, while 12, or 71%, did so for attacker tactics and techniques.Only 5 experts, or 29%, considered it useful for understanding attackers’ cost-benefit considerations.Source: Usefulness and Use-Cases · p. 8
• Threat modeling, awareness and training, and risk assessment were the experts’ top three proposed use cases.The authors also mention penetration-test scoping as an additional possible use.Source: Usefulness and Use-Cases · p. 8

Developer survey

• 134 developers assessed awareness of high-level attack vectors and whether they or their organizations used mitigating safeguards.Optional questions covered taxonomy understandability and usefulness from the perspective of open-source consumers.Source: C. Validation and Assessment by… · p. 8

Awareness

• Awareness ranged from 120 developers, or 90%, for developing and advertising a distinct malicious package to 86, or 64%, for build-time injection.These figures concern the two highest and lowest awareness values reported.Source: Awareness about Attack Vectors · p. 9

Perceived protection

• For all but one vector, most developers did not know whether they were protected; for distinct malicious packages, 52% believed protection existed.For build-time injection and malicious-version distribution, 19 developers, or 14%, were sure no protection existed.Source: Awareness about Attack Vectors · p. 9

Taxonomy assessment

• 53 of 134 developers, or 40%, completed the optional taxonomy assessment; 41, or 77%, found it understandable and 46, or 87%, found it useful for awareness.The ratings use scores of 4 or 5.Source: Taxonomy Understandability and Utility… · p. 9

Validation conclusion

• The taxonomy’s validation showed overall agreement among experts and developers regarding structure, naming, comprehensiveness, comprehensibility, and suitability for threat modeling, awareness, training, and risk assessment.This is the reported response to RQ1.2.Source: Taxonomy Understandability and Utility… · p. 9

Safeguards

• Safeguard selection, combination, and implementation require balancing security levels against potentially nonnegligible costs.Costs depend partly on the programming languages and ecosystems involved.Source: A. List of Safeguards · p. 9

Safeguard categories

• Safeguards span common stakeholder-wide measures, maintainer and administrator controls, project-maintainer practices, administrator and consumer controls, and consumer countermeasures.Examples include SBOMs, secure authentication, merge-request review, dedicated build services, source builds, isolation, sandboxing, and vetted mirrors.Source: A. List of Safeguards · p. 9

Safeguards

• 33 general safeguards were identified, mostly detective or preventive, and mapped to attack-tree nodes they partially or fully mitigate.The safeguards are intended for maintainers, contributors, consumers, and administrators.Source: A. List of Safeguards · p. 9

• Most safeguards received medium-to-high utility ratings, while mean cost ratings ranged from 2.0 to 4.8.Source: B. Experts Validation and Assessment · p. 9
• Merge Request Reviews received the highest average utility rating at 4.6.Source: B. Experts Validation and Assessment · p. 10
• 17 experts qualitatively assessed the utility and costs of 33 safeguards.Source: B. Experts Validation and Assessment · p. 10
• Protect production branch, Remove un-used dependencies, and Version pinning had the best utility-to-cost ratios.Source: B. Experts Validation and Assessment · p. 10
• Build Dependencies from Sources had the lowest utility-to-cost ratio and a mean and median utility rating of 3.0.Source: B. Experts Validation and Assessment · p. 10
• 70% of developers knew about Create Name Confusion, but only a minority used its corresponding safeguards.Source: C. Developers Validation and Assessment · p. 10
• Among 134 developers, the most-used safeguards were Remove un-used dependencies, Version pinning, and integrating an open-source vulnerability scanner into the CI/CD pipeline.Source: C. Developers Validation and Assessment · p. 10

Differences between Ecosystems

• Many attack techniques, including Take-over Legitimate Account and Become Maintainer, are independent of ecosystems and programming languages.Source: 1) Differences between Ecosystems · p. 10
• Dependency-resolution attacks depend on package-manager behavior: Maven, npm, pip, NuGet, and Composer were affected by dependency confusion, whereas Go and Cargo were not.Source: 1) Differences between Ecosystems · p. 10
• Installation hooks commonly trigger malicious code in Python and Node.js, while compiled-language ecosystems more often rely on runtime payloads or poisoned test routines.Source: 1) Differences between Ecosystems · pp. 10, 12
• Safeguards are usually cross-ecosystem, but specific controls include Scoped packages for Node.js and Prevent script execution for Python and Node.js.Source: 1) Differences between Ecosystems · p. 12

Benefits of the Taxonomy for Future Research

• The taxonomy offers a common reference and terminology for systematizing OSS supply-chain security knowledge.Source: 2) Benefits of the Taxonomy for Future… · p. 12
• Its attack-vector and safeguard lists can support comparative security assessments across projects, ecosystems, and time.Source: 2) Benefits of the Taxonomy for Future… · p. 12
• Reproducible builds address source-to-binary analysis challenges but are not commonly applied, are considered costly, and require substantial effort for complex projects.Source: 2) Benefits of the Taxonomy for Future… · p. 12

• 17 expert respondents were knowledgeable in supply-chain security and actively participated in OSS projects.Source: Domain Experts · p. 12
• 134 developer respondents were surveyed, and 121 respondents, or 90%, reported using open-source components in their daily jobs.Source: Developers · p. 12
• The literature review included works addressing specific technologies, systems, stakeholder interactions, and broader supply-chain coverage.Source: §VIII · p. 12
• Prior work covered commit-based injection detection, social-engineering susceptibility, subverted compilers, and source-to-binary correspondence.Source: §VIII · pp. 12–13
• Earlier general works included attack trees for malicious packages and frameworks addressing secure software-artifact distribution.Source: §VIII · p. 13
• The taxonomy was positively assessed for comprehensiveness, comprehensibility, and usefulness, but reflects the current state of the art and is expected to evolve with supply-chain technologies.Source: §IX · p. 13
• The authors systematically reviewed literature and security news, then used expert feedback to assess completeness, while acknowledging that new attacks are likely to be discovered.Source: §IX · p. 13
• The taxonomy can serve as a central reference, while mapped safeguards can help assess stakeholder exposure and optimize limited security budgets.Source: §X · p. 13

• The systematic literature review queried Google Scholar, arXiv, IEEE Xplore, and the ACM Digital Library.Source: Appendix B · p. 17
• Table II lists safeguards, their control types, involved stakeholders, and mappings to mitigated attack vectors.Source: Table II · p. 18
• The review also used Microsoft and Google whitepapers and security-project materials from SLSA, sigstore, TUF, in-toto, and OSSF Scorecard.Source: Appendix B · p. 18
• Additional sources included security-news aggregators, package-repository and vendor blogs, security researchers, and cybersecurity-conference keynotes.Source: Appendix B · p. 18
• Grey-literature sources included MITRE CAPEC, the IQT Lab Software Supply Chain Compromises dataset, and the Backstabber’s Knife Dataset.Source: Appendix B · pp. 17–18