Research and analysis

A study of cybersecurity literature on open-source software and AI

Published 7 September 2026

1. Executive summary

Background and purpose

Open-source software underpins most global digital infrastructure; the OSSRA reports open-source components in 96% of commercial codebases, including government, critical services, and AI pipelines. For decades this dependency was governed inconsistently, until incidents such as Log4Shell (2021)^{[footnote 1]} and the XZ Utils backdoor (2024)^{[footnote 2]} made its risks undeniable. Open-source AI has sharpened the challenge: model weights, open datasets, and inference tooling are now infrastructure, yet frameworks built for traditional software do not transfer cleanly to AI artefacts such as weights, training data, and fine-tuning pipelines. The Department for Digital, Culture, Media & Sport (DCMS) commissioned this review to assess the cybersecurity landscape for open-source software (OSS) and open-source AI (OSAI), map global frameworks and practices, identify security gaps and emerging risks, and provide actionable early recommendations.

Methodology

Two parallel searches using the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA)^{[footnote 3]} framework were conducted. The academic search spanned eight databases, screening 14,561 records to 43 high-relevance studies. The grey literature search produced a final corpus of 172 records from national cyber authorities, standards bodies, international organisations, industry associations, and ecosystem stewards, supplemented by platform analysis of GitHub and Hugging Face. Full details are in Appendices A (academic literature) and B (grey literature).

Key findings

1. Definitions of both OSS and OSAI remain inconsistent across governments, industry, and academia, and that inconsistency is itself a governance risk.

For OSS, the Open-Source Initiative’s Open-Source Definition (OSD) is the most widely adopted reference point, used in variants by the National Cyber Security Centre (NCSC), the US Cybersecurity and Infrastructure Security Agency (CISA), and the National Institute of Standards and Technology (NIST). For OSAI no equivalent consensus exists and three framings compete: a software-centric view (code access), an open-weight view (model parameters), and an emerging supply-chain view (data, pipelines, tooling). Where the definition stops, security responsibility disappears.

2. The literature on how open-source AI is defined, governed, documented, and distributed before deployment is sparse.

The academic base is strong on downstream risks such as intrusion detection and adversarial robustness, but near-silent on upstream questions: how models are trained, what data they use, how weights are distributed, and what documentation should apply. A UK framework will need to go beyond what the current evidence base can support.

3. The most comprehensive definition available is the Open-Source AI Definition 1.0 (OSAID).

Published in October 2024, it requires that a genuinely open-source AI system make available its training data information, source code, and model parameters together, clarifying that openness should mean transparency across the full artefact chain, not just code access. UK policy should engage with it explicitly.

4. Most widely used models described as “open-source” do not meet the OSAID, creating real governance risk.

Systems including Llama 2 (Meta), Grok (X), Phi-2 (Microsoft), and Mixtral (Mistral) do not qualify, each withholding training data, code, or use rights. Only a small set fully satisfies it (Pythia, OLMo, Amber, CrystalCoder, T5); what these share is provenance, not scale, coming from research institutes and non-profit consortia that release data, code, and weights together as a matter of mission. The dividing line is the releasing organisation’s incentives, not model size or specialism. This “open-washing” is consequential under the EU AI Act, where open-source status confers exemptions; three independent frameworks (the Linux Foundation’s Model Openness Framework, the European Open-Source AI Index, and the Stanford Foundation Model Transparency Index) converge on this finding.

5. The main security risks differ significantly between OSS and OSAI, and strategies for OSAI-specific risks are not yet mature.

For OSS, supply-chain attacks (dependency confusion, malicious package injection, maintenance abandonment) are the dominant, best-evidenced risk, with mature mitigations: Software Bill of Materials (SBOMs)^{[footnote 4]}, secure-by-design principles, dependency scanning, and vulnerability disclosure. For OSAI the response lags: dataset poisoning, weight tampering, insecure fine-tuning, and absent provenance introduce vulnerabilities undetectable through conventional review. Of the 10,000 most downloaded Hugging Face models, only 15 (fewer than 0.2%) carried security-relevant documentation; of around 2,000 AI-related GitHub repositories, only 131 (around 6%) contained substantive security content. Users in regulated sectors cannot currently make informed security assessments of what they adopt.

Recommendations

Four priority areas are recommended.

1. Establish working definitions of OSS and OSAI.

Adopt the OSD explicitly, including for OSS used as an input to AI systems, and anchor the OSAI definition in the OSAID, distinguishing fully open-source systems, open-weight models, and partially open configurations, with obligations calibrated to each.

2. Lead development of provenance and documentation standards.

Extend and more consistently mandate Software Bill Of Materials (SBOMs), and lead development of an AI Bill of Materials (AI BoM)^{[footnote 5]} covering training data provenance, model lineage, fine-tuning history, and known vulnerabilities, building on the Linux Foundation’s AIBOM work with SPDX 3.0 and the G7’s 2025 SBOM-for-AI guidelines^{[footnote 6]}.

3. Engage with platform operators on governance requirements.

Hugging Face and GitHub are the primary distribution infrastructure, yet documentation standards, contributor verification, and model integrity validation are absent and voluntary adoption has not produced them.

4. Engage in shaping international norms.

Through the International Organization for Standardization and International Electrotechnical Commission’s Joint Technical Committee 1, Subcommittee 42 (ISO/IEC JTC 1/SC 42), which develops international AI standards, and the European Telecommunications Standards Institute (ETSI), which develops AI security standards, governments and policymakers (the UK among them) can shape norms while unsettled, building on convergence around secure-by-design and provenance transparency across EU, US, and international frameworks.

2. Introduction

Open-source software underpins the vast majority of digital infrastructure from operating systems and cloud platforms to AI development frameworks and critical services. Open-source AI has expanded rapidly since 2020, with the public release of large language model weights, open training datasets, and open inference tooling creating new opportunities and new risks simultaneously.

Existing cybersecurity frameworks were designed for a world in which software was the primary open-source artefact and in which source code availability defined openness. The emergence of open-source AI introduces a different set of artefacts such as model weights, training data, fine-tuning pipelines, inference tooling and a different set of risks that existing frameworks do not fully address. At the same time, supply-chain incidents affecting traditional OSS have continued to grow in scale and sophistication. The evidence base for governing both domains is uneven: mature in some areas, almost entirely absent in others.

Existing cybersecurity frameworks were designed for a world in which software was the primary open-source artefact and in which source code availability defined openness. The emergence of open-source AI introduces a different set of artefacts such as model weights, training data, fine-tuning pipelines, inference tooling and a different set of risks that existing frameworks do not fully address. At the same time, supply-chain incidents affecting traditional OSS have continued to grow in scale and sophistication. The evidence base for governing both domains is uneven: mature in some areas, almost entirely absent in others.

This review maps that evidence base systematically. It identifies what is known, where key gaps persist, and where the evidence is or is not strong enough to inform future policy decisions. The review adds to and contextualises evidence alongside Department for Science, Innovation and Technology (DSIT)^{[footnote 7]} - DSIT’s Forward Digital paper^{[footnote 8]}, covering the period from 2020 to 2026 and centred around 5 research questions:

• RQ1: How are governments, industry, and academia defining open-source software and open-source AI?
• RQ2: What are the main risks, bad outcomes, opportunities, and proposed mitigations?
• RQ3: How effectively do current strategies address these risks?
• RQ4: How far do OSS security practices translate to AI systems?
• RQ5: In what ways do global frameworks and regulations differ, and what opportunities exist for harmonisation?

These questions are interconnected. How open-source AI is defined (RQ1) determines which systems fall within scope for risk assessment (RQ2), which security practices apply (RQ3 and RQ4), and which regulatory regimes are relevant (RQ5). The review covers both open-source software and open-source AI security in equal scope.

The review covers both open-source software and open-source AI security in equal scope. For open-source software, the evidence base is relatively mature as supply-chain risks, vulnerability management, and secure development practices are well-documented and the subject of established frameworks. The review therefore focuses on synthesising and mapping that evidence to inform policy considerations rather than restating work that is already well-established. For open-source AI, the evidence base is considerably thinner, and the policy need more acute. The review pays particular attention to the following AI-specific upstream risks, because these are the areas where existing frameworks are least developed and where a UK policy framework would need to do the most work:

• Model weight tampering: unauthorised post-training modification of an AI model’s learned parameters, altering behaviour without visible changes to source code.
• Dataset contamination: the introduction of corrupt, biased, or adversarial data into training datasets, shaping model behaviour at its source.
• Insecure model distribution: dissemination of AI models without integrity checks or provenance assurances, preventing verification of authenticity.
• Insufficient provenance mechanisms: lack of traceability across a model’s data sources, development history, and subsequent modifications.
• Supply-chain vulnerabilities specific to AI development pipelines: weaknesses across the tools, libraries, platforms, and processes used to develop, deploy, and operate AI systems.

The review draws on 43 peer-reviewed academic studies and 126 grey literature records. The findings are intended to inform the development of interventions in open-source software and open-source AI security.

3. Scope

The review covers security risks associated specifically with OSS and OSAI. It does not address general AI development or broader cybersecurity topics except where directly relevant. Sources are from 2020 to 2026 (Nov), reflecting the period during which open-source AI artefacts, particularly open-weight large language models became a significant governance concern rather than a primarily academic one.

Two bodies of evidence were reviewed:

• Peer-reviewed academic literature across computer science, cybersecurity, AI, and software engineering, accessed via Scopus, Web of Science, IEEE Xplore, ACM Digital Library, arXiv, SSRN, SpringerLink, and ScienceDirect.
• Grey literature (covering material published outside traditional academic channels, such as government reports, standards, and industry guidance) from national cyber authorities (NCSC, CISA, DCMS); standards bodies (NIST, Open Web Application Security Project -OWASP, Centre for Internet Security- CIS); international organisations (European Network and Information Security Agency - ENISA, European Union Joint Research Centre - EU JRC, Organisation for Economic Co-operation and Development - OECD); industry associations and cloud security providers (TechUK, OpenUK, Synk, SonaType, Mandiant, Google Cloud); open-source ecosystem stewards (OpenSSF, Linux Foundation, Cloud Native Computing Foundation(CNCF)); and think tanks and research institutions (RAND Corporation, Brookings Institution); supplemented by API-driven platform analysis of GitHub and Hugging Face.

The review covers open-source components used in AI systems; open-weight model release and distribution; dataset governance and provenance; risks arising from dependency chains and community contributions; and alignment with standards and regulatory contexts across jurisdictions, for both OSS and OSAI.

4. Methodology

For the purposes of search scope, this review treated open-source AI as any system in which one or more of source code, model weights, training data, training pipelines, or inference tooling is made publicly available under open terms. The terms under which these artefacts are published vary significantly: source code is typically released under OSI-approved licences^{[footnote 9]} such as MIT, Apache 2.0, or GNU General Public Licence (GPL), which govern what users may do with the code; model weights and datasets are typically licensed under open data licences such as Creative Commons^{[footnote 10]} or Community Data Licence Agreement (CDLA)^{[footnote 11]} variants, since they are data artefacts rather than software and standard code licences do not straightforwardly apply to them; and training pipelines and inference tooling may be released under any combination of the above, or under bespoke model licences such as those used by Meta for Llama^{[footnote 12]} that restrict commercial use or redistribution in ways that are incompatible with genuine open-source principles. This variation in licensing terms is itself a source of definitional confusion documented throughout the evidence base.

4.1 Search and screening: academic literature

Searches followed PRISMA guidance across eight platforms, targeting the intersection of three domains: OSS and OSAI (licensing, repositories, model weights, datasets); AI and machine learning systems (models, pipelines, deployment); and security (vulnerabilities, adversarial attacks, supply chain, governance). 14,561 records were identified. A multistage screening process reduced this to 43 included studies. Exclusion criteria removed work irrelevant to OSS or OSAI security, non-empirical studies, and papers focused exclusively on proprietary systems. Full details, including inclusion and exclusion criteria and screening steps, are in Appendix A.

4.2 Search and screening: grey literature

Grey literature was identified through four complementary methods: institutional repository searches; Google searches restricted to relevant domains; API-driven searches of GitHub and Hugging Face; and targeted searches of key organisations. The same three-domain keyword logic was applied. 193 records were identified across six institutional categories; multi-stage screening produced a final corpus of 172 records. Full details are in Appendix B.

4.3 Bibliometric and network analysis

VOSviewer was used to map keyword co-occurrence, co-authorship networks, and thematic clusters across the 43 academic studies. These visualisations provided in Appendix C show where the field is well-connected (indicating mature research) and where it is sparse or absent (indicating gaps relevant to DCMS). Key outputs are described in plain terms throughout the findings below.

5. Findings

This section presents findings thematically across six areas, covering both open-source software (OSS) and open-source AI (OSAI). The themes are drawn from the combined academic and grey literature evidence base, noting where there is a convergence and divergence across the literature strands. The grey literature is more developed on governance while academic literature is more developed on technical mechanisms.

5.1 Definitions: what open-source software and open-source AI actually mean

For open-source software, the definitional landscape is relatively settled. The Open Source Initiative’s Open Source Definition (OSD)^{[footnote 13]} — specifying ten criteria including free redistribution, access to source code, and no discrimination against persons, groups, or fields of endeavour — provides the most widely adopted international reference point. The UK NCSC, CISA, NIST, and OpenSSF all work within variants of it. Licensing obligations and community governance nuances remain, but the core definition is not contested.

For open-source AI, no equivalent consensus exists. Three distinct framings appear across the evidence, each capturing part of the picture but none sufficient on its own.

The software-centric view

This equates openness with access to source code and ML libraries such as PyTorch and TensorFlow. This is the dominant framing in the academic literature, particularly across intrusion-detection and adversarial-ML studies. Its strength is that it maps directly onto established OSS governance: code licences, dependency management, and vulnerability disclosure all apply cleanly. Its weakness is that it leaves the most consequential AI-specific artefacts entirely ungoverned: a model whose code is open, but whose training data and weights are proprietary is treated as fully open under this framing, even though a user cannot reproduce, audit, or meaningfully assess it.

The open-weight view

This defines openness by the public availability of model parameters which are the numerical values that encode what a model has learned. This framing is used by AISI, many grey literature sources, and a growing share of practitioners. Its strength lies in capturing the artefact most distinctive to AI systems, while also enabling replication and fine-tuning. Its weakness, however, is that it says nothing about how the weights were produced: a model can release its weights whilst withholding training data, data processing methodology, and intermediate checkpoints, making independent verification of its behaviour impossible. A further consequence which is explored in the risks section, is that once weights are publicly released, safeguards cannot be enforced retrospectively, and the release cannot be recalled.

The supply-chain view

This is an emerging framing that extends OSS supply-chain thinking to the full AI development pipeline, covering data collection, preprocessing, training infrastructure, and inference tooling alongside code and weights. Its strength is that it is the most comprehensive of the three, treating AI development as a lifecycle rather than a single artefact. Its weakness is that it is the least operationalised: no established standards, documentation requirements, or governance mechanisms have yet been built around it.

The OSAID attempts to address all three gaps simultaneously. Published by the Open-Source Initiative in October 2024, it specifies that a genuinely open-source AI system must make available data information, code, and parameters together not any one in isolation. It goes beyond code (software-centric), beyond weights alone (open-weight), and provides a concrete specification for what supply-chain transparency requires. Applied to widely used models, it reveals how far current practice falls short: only Pythia (EleutherAI), OLMo (AI2), Amber and CrystalCoder (LLM360), and T5 (Google) fully satisfy it. Llama 2 (Meta), Grok (X/Twitter), Phi-2 (Microsoft), and Mixtral (Mistral) do not. Before the OSAID, the governance problem was difficult to articulate precisely: “open source” meant different things to different actors, and there was no agreed basis for assessing whether any given system was open or not. The OSAID changes this. By specifying exactly what full openness requires, it provides a policy anchor against which systems can be assessed. What it does not do is specify what obligations apply to the majority of systems that fall short of that standard. The governance challenge for policymakers is therefore not definitional, the OSAID has largely resolved that, but operational: what security requirements apply to partially open systems, and who is responsible for enforcing them?

Three independent frameworks operationalise this assessment in practice. The Linux Foundation’s Model Openness Framework (MOF; White et al., 2024)^{[footnote 14]} rates models across 17 lifecycle components under a three-tier classification, explicitly noting that conventional open-source licences designed for code are not appropriate for model parameters, which as data artefacts require open data licences. The European Open-Source AI Index (Liesenfeld and Dingemanse, 2024)^{[footnote 15]} scores models across availability, documentation, and access dimensions, and directly addresses open-washing in the context of the EU AI Act — where open-source status confers regulatory exemptions, creating incentives for organisations to claim openness strategically. The Stanford Foundation Model Transparency Index (Bommasani et al., 2023)^{[footnote 16]} assesses major developers against 100 transparency indicators, with an average score of 37 out of 100 in earlier assessments. All three converge: the majority of widely described open-source models do not meet comprehensive openness criteria.

The academic literature provides almost no multidimensional definitional analysis. Al-Kharusi et al. (2024) the one paper directly addressing open-source AI privacy and security as a combined topic, describes threats including model inversion, membership inference, data leakage, and backdoor attacks, but does not engage with the OSAID or articulate what “open” should encompass for governance purposes. The bibliometric keyword co-occurrence map (Appendix C, Figure 1) illustrates this graphically: terms such as “open-source AI”, “model weights”, “training data provenance”, and “dataset governance” are absent from the dense, well-connected nodes of the academic network. The field’s definitional conversation is not taking place in peer-reviewed research.

What the OSAID leaves unresolved and what a governance framework needs in addition

The OSAID resolves the definitional problem but creates a usability challenge for policymakers. As a binary standard, systems either meet all three requirements or do not qualify as open source AI, and in practice, almost none do. That binary framing is useful for identifying open-washing, but it is not useful for a government trying to assign security obligations across a landscape where the vast majority of systems are partially open in different ways. A model that releases weights but not training data is not open-source under the OSAID but it is also not proprietary. It occupies a distinct risk category, with specific security implications, that the OSAID has no mechanism to govern.

A governance framework needs three things the OSAID does not provide. First, it must acknowledge partial openness as a category in its own right, with obligations calibrated to what is and is not open rather than treating partial openness as simply a failure to qualify. Second, it must connect openness categories to specific security obligations explicitly: the OSAID defines what openness means but does not specify what security requirements follow from each level. Third, it must be actionable within a specific national governance architecture, compatible with existing frameworks and institutional remits rather than serving as a universal definitional standard.

Implications

The evidence base does not currently support any single, universally adopted definition of open-source AI. Government should consider establishing, for UK policy purposes, a working definition anchored in the OSAID framework and specifying what security obligations attach to each type of open artefact that includes code, weights, data, pipelines, and tooling. For open-source software, existing definitional frameworks are more settled, though governance of OSS as an input to AI systems requires the same provenance and lifecycle thinking now being applied to OSAI specifically.

Towards a working definition for UK policy purposes

Drawing on the OSAID, the OSD, and the three-framing analysis above, and building on what each framing captures and misses, this review proposes the following as a working definition:

Open-source AI is any AI system in which one or more of the following are made available under terms permitting use, study, modification, and redistribution: source code used to train and run the system; sufficiently detailed information about training data to allow independent reproduction; and model parameters including weights and configuration settings. Where one or more of these components is withheld or released under terms restricting use, the system is partially open. Security obligations should be calibrated to what is open: systems open across all three layers carry full obligations; systems open only at the weight layer carry the specific obligations associated with open-weight risk; systems open only at the code layer carry OSS supply-chain obligations without the additional artefact-specific requirements that apply to weights and data.

This definition is not in competition with the OSAID, it operationalises it. While the OSAID defines the criteria for full openness, this definition sets out how systems that fall short of that threshold, but are not proprietary, should be treated in practice. It is consistent with the OSAID, with the OSD for software components, and with AISI’s operational framing of open-weight risk. It provides the graduated governance structure that any coherent UK framework needs.

The chardet case: what definitional ambiguity produces in practice

In March 2026, the maintainer of chardet, a widely used Python library for detecting character encoding, originally licensed under the GNU Lesser General Public Licence (LGPL)^{[footnote 17]}, used AI tooling to rewrite the codebase and released the result under the MIT^{[footnote 18]} licence, a more permissive licence with fewer obligations on users and derivative works. The original author disputed this, arguing that the maintainer’s extensive prior exposure to the original code made a genuine clean-room implementation^{[footnote 19]} legally untenable, and that LGPL obligations therefore persisted.

The case remains unresolved. Its significance is not in its outcome, but in what caused it: no established framework determines what licensing obligations attach to AI-generated code when the generating model was trained on the original licensed work. That gap is a direct consequence of the upstream definitional absence: where definitions stop, responsibility disappears. As AI-assisted development becomes routine, disputes of this kind will multiply. The legal system will resolve individual cases; the governance question is whether clearer definitional frameworks, established upstream, could prevent them.

5.2 Security risks: what the evidence shows, organised by risk type

The combined evidence base identifies four categories of risk for both OSS and OSAI. The first two are established risks, well-evidenced across multiple sources, with documented real-world incidents and mature mitigation guidance. The second two are emerging risks, identified primarily through grey literature and platform analysis, with limited academic evidence and no equivalent mitigation maturity.

Established risk 1: Supply-chain compromise - OSS and OSAI

Software supply-chain attacks exploit the structural characteristics of open-source ecosystems: the depth of dependency chains, the reliance on small volunteer maintainer teams, and the absence of centralised integrity verification. Three attack vectors are consistently documented across CISA, NIST, OpenSSF, and the academic literature:

Dependency confusion

This involves substituting malicious packages for legitimate ones by exploiting how package managers resolve package names across public and private registries. An attacker publishes a public package with the same name as a private internal dependency, causing automated build systems to pull the malicious version. Nguyen et al. (2025) demonstrated machine learning-based detection of malicious packages in npm^{[footnote 20]} repositories, achieving high accuracy, but detection after publication does not prevent the initial compromise.

Malicious package injection

This involves publishing packages that execute harmful code on installation, often masquerading as legitimate utilities. These may remain dormant until triggered by specific conditions, making detection through standard review difficult.

Maintenance abandonment and account takeover

This involves targeting packages whose original maintainers have become inactive. Once a maintainer account is compromised or transferred, an attacker with commit access can introduce vulnerabilities into widely depended-upon code. Wu et al. (2021) built DeepVuler specifically to address the detection gap here by identifying vulnerability signals in OSS communities, days or weeks ahead of official CVE disclosure, reducing the window of unpatched exposure. Wang et al. (2021) addressed the related problem of silent security patches: fixes that resolve vulnerabilities without disclosing them as security-relevant, which attackers can reverse-engineer to identify and exploit unpatched downstream systems. Nguyen et al. (2022) developed VULCURATOR to detect vulnerability-fixing commits across large codebases, improving the speed and accuracy of security-relevant change identification.

Three case studies from the grey literature illustrate these mechanisms at real-world scale:

Log4Shell (2021)

A critical vulnerability in Log4j which is a widely used open-source Java logging library maintained by a small volunteer team was disclosed in December 2021 and exploited globally within hours. The vulnerability affected hundreds of millions of systems across virtually every sector. It illustrated the structural fragility of OSS dependency chains: a single component, embedded invisibly across thousands of downstream products, created systemic exposure that organisations could not assess or remediate quickly because they did not know the library was present. Documented in CISA’s supply chain security guidance and NIST’s software supply chain risk management frameworks (SP 800-161r1)^{[footnote 21]}.

XZ Utils backdoor (2024)

A deliberately introduced backdoor in XZ Utils which is a widely used open-source data compression library embedded in most Linux distributions was discovered only by accident when a Microsoft engineer noticed anomalous SSH login performance. The attacker spent approximately two years building trust as a contributor before introducing the backdoor in a routine release. The case illustrates the near impossibility of detecting sophisticated insider threats in OSS supply chains through standard review processes, and the particular vulnerability of small, critical projects with limited maintainer oversight. Documented in CISA’s open-source security guidance and OpenSSF’s secure open-source software frameworks.

Chardet relicensing (2026)

As described in the definitions section, the chardet case illustrates a new class of supply-chain governance risk created by AI-assisted development, where the boundary between original and derivative work becomes legally ambiguous. Unlike Log4Shell and XZ Utils, which exploited code vulnerabilities, chardet represents a governance failure with no established resolution mechanism in existing intellectual property or licensing frameworks.

These risks extend directly to open‑source AI. Most AI systems are built on open‑source infrastructure such as PyTorch, TensorFlow, and Hugging Face Transformers. They rely on large dependency trees that are subject to the same supply‑chain attack vectors described above. A compromised dependency in an AI training framework can corrupt model weights during training without any change to the model code itself.

Established risk 2: Adversarial attacks on deployed AI systems

The largest cluster of academic literature concerns adversarial attacks on AI systems already in deployment. These are well-evidenced technically but have limited direct policy relevance for this review’s specific scope, for reasons explained below. This emphasis is mirrored in the grey literature, where major government and standards bodies treat adversarial attacks as established operational risks rather than unresolved governance questions.

Three distinct attack types appear across the literature, and it is important to distinguish them because they occur at different lifecycle stages and require different responses:

Evasion attacks occur during deployment

Inputs are crafted to cause an already-trained model to misclassify or produce incorrect outputs. Sedar et al. (2024) addresses adversarial evasion in vehicular communication systems; Kakani et al. (2025) examines adversarial attacks on open radio access network (O-RAN) architectures; Paltun and Fuladi (2024) address intrusion detection system evasion. Grey literature frameworks from ENISA, NCSC, DCMS, and CISA discuss these attacks primarily in the context of post deployment robustness, detection, monitoring, and resilience controls.

Model extraction also occurs post-deployment

A model’s behaviour is reverse engineered from its outputs to reconstruct a functional replica without access to the original weights or training data. Government and industry guidance treats this risk chiefly as an issue of misuse, intellectual property exposure, and operational security, without distinguishing between open‑source and proprietary systems.

Poisoning attacks occur during training, not deployment

Malicious data is introduced into the training pipeline to shape the model’s learned behaviour before it is released. A system in deployment is not simultaneously in training; these are distinct lifecycle risks. Grey‑literature sources consistently treat poisoning as a technical integrity risk to be mitigated through secure‑by‑design development practices and lifecycle controls, rather than through openness‑specific governance mechanisms.

These attacks apply to AI systems generally, not specifically to open-source ones. The adversarial attack literature is technically rigorous but does not differentiate meaningfully between open-source and proprietary deployment contexts. This position is consistent across the grey‑literature reviewed, which almost universally discusses adversarial threats without reference to licensing model or degree of openness. Its governance relevance for this review is therefore limited: these papers address risks to already-deployed systems rather than the upstream governance questions: how models are defined, developed, documented, and distributed. This is a consideration that open-source-focused frameworks may need to address, and one that would benefit from wider discussion.

Emerging risk 1: AI-specific upstream risks

AI systems introduce artefacts such as model weights, training datasets, fine-tuning pipelines, that have no direct equivalent in traditional OSS. Existing supply-chain security thinking addresses the software layer of AI systems adequately but does not reach these artefacts. The following upstream risks are identified across ENISA’s cybersecurity of AI guidance, DSIT’s open-weight model risk documentation, and AISI’s evaluation work; the academic literature addresses these risks only partially, and this gap is itself a finding.

Dataset poisoning involves the deliberate introduction of malicious data into the training pipeline to alter model behaviour at source. Al-Kharusi et al. (2024) identifies this as a primary AI-specific threat, noting that unlike code injection it is undetectable through source code review; the effect is statistical rather than syntactic. ENISA’s cybersecurity of AI guidance documents dataset poisoning as a systemic risk in open training pipelines where data provenance is not verified.

Model weight tampering involves modifying model parameters after training to introduce backdoors, alter outputs for targeted inputs, or degrade performance selectively. AISI’s evaluation work makes the governance consequence concrete: once weights are publicly released, any recipient can make these modifications and redistribute the tampered version. Unlike a software vulnerability, there is no patch mechanism; the compromised version remains in circulation permanently alongside the original.

Insecure fine-tuning pipelines introduce manipulation opportunities at every stage of the process by which pre-trained models are adapted for specific tasks. Lee and Yoo (2025) propose a supply-chain security model for generative AI that explicitly maps these pipeline risks, identifying governance gaps at data preprocessing, training configuration, evaluation, and deployment stages. No standardised governance mechanisms for fine-tuning provenance currently exist.

Checkpoint integrity failures occur when intermediate training checkpoints which are saved versions of a model at different stages of training are modified or replaced without detection. DSIT’s guidance on open-weight model risks identifies checkpoint integrity as an unaddressed vulnerability in current model distribution workflows.

These risks are not exclusively open-source; proprietary AI systems face them too. What makes them specifically acute for open-source AI is a combination of three factors. First, there is no central authority that can mandate documentation standards or recall flawed artefacts after release. Second, users have no alternative channel for the assurance that proprietary vendor accountability would provide. Third, distribution at scale without governance creates systemic risk across the entire downstream user base simultaneously.

AISI’s evaluation work quantifies the severity: universal jailbreaks, techniques that bypass safety constraints across a wide range of harmful request types, have been found in every open-weight model tested. A research collaboration^{[footnote 22]} between AISI, EleutherAI, and the University of Oxford found training data filtering to be over ten times more effective at resisting malicious fine-tuning than post-training defences, without significant performance costs. This finding has direct implications for what obligations are meaningful at which lifecycle stage: governance must reach the training data layer, not only the deployment layer.

Vibe coding and AI-assisted development as an upstream OSS risk

A further emerging risk sits at the intersection of AI tools and OSS supply chains. AI-assisted code generation including through workflows informally described as “vibe coding”. It refers to the process where developers use AI tools to write, rewrite, or adapt code with minimal manual review and this may introduce vulnerabilities that propagate through open-source dependency chains. The NCSC’s 2025 analysis of vulnerability disclosure adaptation for AI safeguards identifies AI-generated code as a novel supply-chain risk: code produced by models trained on existing open-source codebases may replicate known vulnerability patterns, introduce insecure logic, or carry licensing obligations that are not surfaced by standard review. The chardet case in the definitions section above is one documented instance. The academic literature has not yet engaged systematically with this risk category; it is flagged here as an emerging area requiring further research and monitoring.

Agentic AI and open-source systems

OpenUK’s 2025 report “From Agentic to Public Good” identifies open-source agentic AI systems that are capable of taking autonomous actions on external environments as an emerging governance concern. Unlike standard inference models, agentic systems can interact with infrastructure, process sensitive data, and trigger downstream actions without direct human oversight. The security implications of open-source agentic models are qualitatively different from those of standard open-weight models: the “use for any purpose” freedom that open-source implies takes on different significance when that use involves autonomous action rather than inference. Existing definitions, including the OSAID, do not address agentic systems specifically, and no security governance framework yet covers open-source agentic AI. This is an area requiring dedicated further research; the current evidence base does not support a comprehensive treatment. Agentic autonomy cuts across openness categories rather than emerging from them. Whether a system is fully open, partially open, or proprietary does not determine whether it can act autonomously. For this reason, agentic AI raises governance questions that cannot be resolved through openness-based definitions alone.

A concrete illustration emerged in April 2026, when Anthropic disclosed that one of its frontier models, operated agentically, had autonomously identified and exploited previously unknown vulnerabilities across widely used open-source software^{[footnote 23]}. The company stated that this was why it had chosen not to release the model’s weights generally, making the system available instead through a graduated access arrangement: first to selected technology, security, and open-source partners, and later through controlled commercial availability. The capability claims are vendor-reported and not independently verified, and this review takes no position on them. What the episode illustrates is that two governance approaches are now available for frontier AI systems with cybersecurity-relevant capabilities, and existing definitions of open-source AI accommodate only one. Open-weight release is irreversible: once weights are distributed, there is no mechanism to assess their capabilities beforehand, the concern AISI’s analysis describes. Graduated proprietary release preserves the possibility of pre-release assessment but concentrates it within a single commercial actor, whose decisions on access, terms, and timing carry no external audit or public accountability. Both approaches raise significant but different governance concerns. The episode makes visible that openness definitions as currently framed, including the OSAID, do not yet provide the vocabulary to describe this choice, still less to evaluate it; that gap is one any governance framework for open-source AI will need to address.

Emerging risk 2: Platform and distribution risks - OSS and OSAI

A second emerging risk category concerns the platforms through which open-source software and models are distributed at scale. Hugging Face and GitHub are the primary distribution infrastructure for both OSS and OSAI, and both publish guidance on documentation and security practices. On Hugging Face, the model card framework specifies fields for intended use, limitations, and risks. On GitHub, the security advisory and dependency scanning features are documented and recommended by NCSC and CISA. The analysis below shows that these voluntary guidelines have not produced meaningful adoption for either platform.

Of the 10,000 most downloaded models on Hugging Face with permissive open-source licences, only 15 included security-relevant content in their model cards, fewer than 0.2%. A developer selecting from the most widely used open-source AI models has approximately a 1-in-667 chance of finding any security information at all about what they are downloading.

The GitHub analysis identified approximately 2,000 repositories where AI and security keywords both appeared. Of those, 131 contained substantive content addressing both AI functionality and security practice. The remaining repositories contained no meaningful security documentation. The search focused on repositories at the intersection of open‑source software, artificial intelligence, and security documentation. Repositories that were open‑source but not AI‑related, AI‑related but not open‑source, or security‑related without an AI component were outside the scope of this review.

To understand why these proportions are concerning, it is necessary to be specific about what “security documentation” means and what a developer cannot do without it. Security documentation here refers to information that would allow a developer to determine: whether a model’s training data included personal or sensitive data that could be extracted through model inversion attacks; whether known vulnerabilities have been identified and addressed since the model’s release; whether the weights available for download are identical to those evaluated and released by the original developer, or have been modified; and what the model’s intended use case and known failure modes are. Without this information, a developer adopting an open-source AI model for a production system, including in regulated sectors such as healthcare, finance, or critical infrastructure, is doing so blind. In traditional software, this kind of information would appear in a security advisory, a CVE entry, or an SBOM. For open-source AI model distribution, no equivalent mechanism exists at meaningful scale.

This information gap applies to both OSS components and OSAI models, though it is more acute for AI. The broader OSS ecosystem has imperfect but established documentation norms such as security advisories, CVE tracking, and SBOM adoption are present even if unevenly applied. For AI model distribution, these mechanisms have no equivalents at all. No market mechanism is generating this information, and voluntary adoption of the platforms’ own stated documentation standards has not produced it.

Implications

The evidence base is sufficiently mature to support governance action on open source software supply chain risks. This is a well evidenced area with established, actionable frameworks. For AI specific upstream risks, the grey literature provides sufficient evidence to identify risk categories and to specify the types of documentation and provenance obligations that governance frameworks would need to cover, while the academic literature alone remains insufficient. Platform level risks are clearly evidenced across both open source software and open source AI. Adversarial attack risks are well understood technically but are not specific to open source systems and do not generate the governance recommendations most relevant to the scope of this review. Emerging risks, including AI assisted development practices and agentic AI, are credible and warrant monitoring, but the current evidence base does not yet support prescriptive governance interventions.

5.3 Mitigations: what exists, what works, and what is missing

The mitigation landscape for OSS and OSAI looks fundamentally different depending on which domain is being examined. For OSS, a mature, evidence-backed set of practices exists, underpinned by well-tested frameworks and operationally validated tools. For OSAI, the equivalent infrastructure is almost entirely absent.

OSS mitigations: a mature but incomplete picture

For traditional software supply-chain security, mitigation guidance is well-developed and operationally tested across three areas.

Transparency and inventory

The Software Bill of Materials (SBOM) is a structured, machine-readable list of every component, library, and dependency used in a piece of software. When a vulnerability is discovered in a component, an SBOM allows an organisation to immediately identify every system that includes it and prioritise remediation accordingly. Without an SBOM, organisations often discover their exposure only after an incident, as Log4Shell demonstrated at scale. CISA and NIST have both issued detailed SBOM adoption guidance, and NIST’s SP 800-161r1 integrates SBOM requirements into its supply chain risk management framework.

Detection and monitoring

Three academic tools directly address the detection gap in OSS security practice. VULCURATOR (Nguyen et al., 2022) uses deep learning to identify vulnerability-fixing commits across large repositories, improving the speed and accuracy of security-relevant change identification. DeepVuler (Wu et al., 2021) detects vulnerability signals in open-source communities, days or weeks ahead of official CVE disclosure, reducing the window between silent fix and active exploitation. PatchRNN (Wang et al., 2021) addresses the specific problem of undisclosed security patches; fixes that resolve vulnerabilities without labelling them as security-relevant, which attackers routinely reverse-engineer to exploit unpatched downstream systems.

Vulnerability management

Walkowski et al. (2021) provides an open-source vulnerability management framework using context-aware CVSS scoring, empirically validated across real environments and demonstrating that systematic, risk-prioritised vulnerability management outperforms generic commercial tools in practice.

One further finding cuts across all three areas: the open-source tools used to implement security practices are themselves subject to the same risks they are designed to address. Saad et al. assessed eight open-source Automated Machine Learning (AutoML)^{[footnote 24]} frameworks across cybersecurity datasets, finding substantial performance variability between frameworks, vulnerability to adversarial manipulation, and model drift under real-world conditions. The implication is not that these tools should not be used; it is that governance frameworks must include the security tooling layer, not only the systems that tooling is applied to.

OSAI mitigations: where the evidence base runs out

Contrast the picture above with the state of mitigation evidence for open-source AI, and the gap is stark. Across the 43 academic studies reviewed, not one provides an empirically validated governance-level mitigation specifically for open-source AI artefacts. The mitigations that appear are primarily algorithmic such as adversarial training, anomaly detection, and blockchain-secured metadata and they apply to AI systems generally, not specifically to the open-source context. Several papers propose blockchain mechanisms for AI pipeline integrity: Li et al. (2023) on decentralised retrieval-augmented generation with blockchain-secured source reliability scoring; Alohali et al. (2025) on blockchain-integrated explainable AI for IoT threat detection; Salzano and Pareschi (2023) on NLP-based blockchain security monitoring; and Hussain et al. (2025) on blockchain-enabled deep learning for industrial IoT networks. These are technically interesting contributions, but none has been evaluated at the scale or in the governance contexts relevant to open-source AI distribution.

The reason these algorithmic mitigations do not translate to the open-source context is specific and important: they cannot be enforced after model release. Once weights are publicly available, any recipient can modify the model, remove safeguards, bypass mitigations, and redistribute the result, without restriction and without oversight. In a closed-weight deployment, a provider can enforce content filters, access controls, and usage policies. In an open-weight deployment, none of these mechanisms survives redistribution. This is not a gap in the literature’s technical sophistication; it is a structural property of open-weight distribution that no algorithmic mitigation can address.

The strongest current evidence on OSAI-specific mitigations comes from AISI’s evaluation work^{[footnote 25]} and it reinforces this conclusion. These findings are of particular relevance to open-source AI, rather than to AI systems in general, because the mitigations they identify must be applied before weights are released. The key results are:

• Training data filtering at the pretraining stage is over ten times more effective at resisting malicious fine-tuning than post-training defences, without significant performance costs. This is an open-source-specific finding: it is the one mitigation that must be applied before weights are released, making it the only intervention point that survives open redistribution.
• Full-access audits where evaluators have unrestricted access to model weights, training data, and configuration. These are currently the most reliable mechanism for measuring risk before release. However, this too is open-source specific: it requires access to the full artefact chain that only fully open systems make possible.
• No current technique provides hard safety guarantees for open-weight models once released. This is the ceiling of what the current evidence base can support for OSAI mitigation.

The SBOM gap and what is being done about it

For OSS, the SBOM provides the foundational transparency mechanism: a structured record of what a system contains, enabling vulnerability tracking, incident response, and supply-chain accountability. SBOMs are not specific to open-source software. They apply equally to proprietary systems and are commonly required in commercial procurement and in regulated sectors. Their relevance to this review is that the open-source ecosystem is where their absence has the most significant consequences, because open-source components have no commercial supplier that downstream users could hold accountable for providing the equivalent information. For open-source AI, no equivalent exists. An AI system’s components such as training data, model lineage, fine-tuning history, known vulnerabilities, configuration settings are not captured in any standardised, auditable form.

This gap is not entirely unaddressed. The Linux Foundation’s Implementing AI Bill of Materials (AI BOM ) with SPDX 3.0 (2024)^{[footnote 26]} provides a concrete technical framework for AI provenance documentation, extending the SBOM concept to cover AI-specific artefacts. Like SBOMs, AIBOMs are not an open-source-specific mechanism - the need for AI provenance documentation applies to proprietary AI systems as well, and the Linux Foundation’s technical framework is designed to cover both contexts. What is distinctive about the open-source AI case is the absence of any alternative channel through which downstream users could obtain the same information. G7 discussions have engaged with AIBOM concepts as part of broader AI security coordination. These initiatives are nascent but represent a foundation that policymakers should build on rather than duplicate. The AIBOM concept is directly relevant to the working definition proposed in the definitions section: a system that is partially open, releasing weights but not training data, would under an AIBOM framework be required to document what it does and does not disclose, making the governance obligations of partial openness concrete and auditable.

Where governance-level evidence is absent for both domains

One finding applies equally to OSS and OSAI: neither the academic nor the grey literature provides empirical evaluation of whether governance interventions work. For OSS, we have strong evidence that tools like VULCURATOR and DeepVuler improve detection capability in controlled settings. There is no evidence that SBOM mandates reduce incident rates at population level, that secure-by-design requirements change developer behaviour across the ecosystem, or that vulnerability disclosure frameworks produce faster remediation in practice. For OSAI, the gap is even more acute: no study evaluates whether documentation standards reduce security incidents, whether platform governance mechanisms improve outcomes, or whether any regulatory requirement produces measurable change in how models are developed or distributed.

Policymakers will therefore need to draw on regulatory analogy, expert judgement, and international comparison rather than empirical research when designing documentation requirements or platform obligations. This is not a reason for inaction, it is a reason to build evaluation mechanisms into any framework from the outset, so that the evidence base strengthens as the framework operates.

Implications

For OSS supply-chain security, policymakers can rely on mature evidence base when recommending SBOMs, dependency scanning, secure-by-design principles, and vulnerability disclosure frameworks. For OSAI, AISI’s training data filtering and full-access audit findings are the strongest current evidence and should inform what obligations are placed on model developers; specifically, that meaningful governance must reach the training data layer, not only the deployment layer. The AIBOM work by the Linux Foundation provides the foundation for a provenance documentation standard; policymakers should engage with it directly rather than starting from scratch. Industry should treat the absence of governance-level effectiveness evidence as a signal to build monitoring and evaluation into any practices adopted from the outset.

5.4 Regulatory landscape: divergence, convergence, and what it means

Open-source software and AI are distributed globally without jurisdictional boundaries. A model released in one country is downloaded and deployed in others; a library published under a US-originated licence governs its use in the EU, the UK, and beyond. Yet the frameworks governing their security are national, and they diverge substantially in scope, mandate, and philosophy. That divergence creates three concrete problems: compliance complexity for organisations operating across borders; regulatory arbitrage for those seeking to minimise obligations by choosing where to publish or deploy; and fragmentation of what could otherwise be shared governance infrastructure. Understanding where frameworks align and where they do not is a precondition for designing a new framework that works in an interconnected ecosystem.

The evidence presented in earlier sections sharpens this: the definitional fragmentation, the upstream risk gaps, and the mitigation immaturity all have regulatory dimensions. A framework that cannot agree on what open-source AI is cannot coherently assign compliance obligations. A regulatory approach that focuses only on deployed systems will not reach the upstream risks that matter most. And a voluntary framework, as the platform evidence shows, will not produce documentation norms that the market has failed to generate on its own.

The European approach

The EU has moved furthest towards mandatory requirements. The Cyber Resilience Act (CRA) imposes security obligations on products containing digital elements placed on the EU market, including in certain commercial deployment scenarios, products that incorporate open-source components. Organisations that integrate OSS into commercial products and distribute them in the EU must demonstrate conformity with security requirements, maintain vulnerability disclosure processes, and provide security updates for the product’s expected lifetime. The practical implication for UK organisations is direct: any commercial product incorporating OSS components and sold into the EU market is within CRA scope, regardless of where the organisation is based.

The EU AI Act introduces a tiered risk framework for AI systems, with mandatory obligations for high-risk applications including conformity assessment, technical documentation, and post-market monitoring, and conditional exemptions for open-source foundation models. The exemption lapses if a model is determined to present systemic risks, but the threshold for that determination remains undefined in implementing guidance. This creates a live governance ambiguity: open-weight models widely described as open-source may claim exemptions they do not merit or may lose exemptions without clear prior notice. The open-washing dynamic documented in the definitions section is therefore directly consequential under the AI Act; the regulatory benefit of open-source status creates incentives for strategic misrepresentation that the Act’s current implementing guidance does not resolve.

Together, the CRA and AI Act represent the most comprehensive attempt by any jurisdiction to bring digital product security and AI security under a unified framework. Their direct implications for UK organisations include: compliance obligations for any OSS-incorporating commercial products distributed in the EU; documentation and conformity requirements for high-risk AI deployments serving EU users; and the need to monitor implementing guidance on the systemic risk threshold, which will determine which open-weight models lose their exemptions.

The US approach

United States policy for both OSS and OSAI relies on voluntary frameworks. NIST’s AI Risk Management Framework provides structured guidance for managing AI risk across the development lifecycle. NIST’s SP 800-161r1 addresses software supply-chain security specifically, including OSS components. CISA has published an Open-Source Software Security Roadmap^{[footnote 27]} setting out four priority areas: establishing CISA’s role in supporting OSS security; driving visibility into OSS usage and risk; reducing prevalent vulnerabilities; and hardening the broader OSS ecosystem. These are detailed, operationally useful frameworks. They do not, however, impose legal requirements.

CISA’s roadmap is notable precisely because it is OSS-specific; it treats OSS security as a distinct domain requiring dedicated attention rather than subsuming it within general software security. This is the closest the US has come to a policy position on OSS security governance, and it represents a more operationally developed OSS-specific stance than most other jurisdictions. Its limitation is the same as all US frameworks in this space: it depends entirely on voluntary adoption. The platform evidence in this review demonstrates what voluntary adoption produces: fewer than 0.2% of the most downloaded open-source AI models include security documentation. The US framework is well-designed; the adoption mechanism is insufficient.

The UK approach

The UK has adopted a pro-innovation, risk-based approach to the governance of open-source software and AI security - prioritising innovation enablement whilst managing identified risks through guidance, codes of practice, and sector-specific regulation rather than horizontal mandatory requirements. AISI contributes to the UK’s understanding of AI and open-source model risk through research, model evaluation, and international engagement, rather than through regulatory enforcement. The NCSC’s guidance addresses open-source software primarily through a code-focused lens, with its supply-chain security and secure development frameworks applying most directly to the OSS layer of AI systems. DSIT’s Code of Practice for the Cyber Security of AI (January 2025)^{[footnote 28]} is the most AI-specific UK governmental contribution to date, setting out guidelines for secure AI system development, deployment, and maintenance.

Two standards development processes are particularly relevant to how the UK approach will evolve. The ISO/IEC JTC 1/SC 42 work programme^{[footnote 29]} is developing international standards for AI trustworthiness and security, including requirements for transparency, robustness, and lifecycle governance. The ETSI standard on securing AI systems against adversarial attacks^{[footnote 30]}, EN 304 223, provides a technical framework directly relevant to open-weight model security. As these standards become embedded in procurement requirements and regulatory technical specifications, open-source projects that do not meet them risk exclusion from regulated markets, creating de facto governance pressure that voluntary adoption has not produced. For the open-source AI landscape specifically, this means that standards compliance, even where not legally mandated, may become a practical prerequisite for adoption in public sector, critical infrastructure, and regulated industry contexts.

Beyond the EU, US, and UK

The grey literature corpus reveals significant international engagement beyond the three jurisdictions discussed above, and this breadth matters: open-source AI governance that only reflects Western regulatory traditions will not achieve the international norm-setting that effective harmonisation requires.

The G7 Cyber Expert Group’s Statement on Artificial Intelligence and Cybersecurity (September 2025)^{[footnote 31]} addresses AI security coordination across G7 members and directly engages with AIBOM concepts, providing a multilateral foundation for provenance documentation standards. The Linux Foundation’s The Value of Open Source AI for APEC Economies (2025)^{[footnote 32]} documents how Asia-Pacific economies including Japan, South Korea, Singapore, and Australia are engaging with open-source AI governance, with open-source AI increasingly framed as a matter of strategic economic and technological autonomy rather than purely a security concern. The Linux Foundation’s The State of Sovereign AI (2025)^{[footnote 33]} extends this, showing how different jurisdictions are approaching open-source AI as infrastructure for national capability, with direct implications for how governance frameworks are designed to accommodate state-level interests.

The OECD’s AI principles and cybersecurity measurement frameworks apply across its 38 member states, providing the broadest available international baseline for both OSS and AI governance. OpenSSF’s global membership means that its secure open-source software frameworks covering dependency management, vulnerability disclosure, and supply-chain integrity, have operational relevance well beyond the US context in which they were developed.

Harmonisation opportunities: for both OSS and OSAI

Across all jurisdictions reviewed, three principles appear consistently: secure-by-design, supply-chain transparency, and risk-proportionate governance. These provide the most viable foundation for harmonisation, because they represent areas of genuine convergence rather than rhetorical alignment masking different implementation approaches.

For OSS, harmonisation is more advanced: OpenSSF frameworks, NIST supply-chain guidance, and CRA requirements converge on the same core practices such as SBOM adoption, dependency management, vulnerability disclosure, and secure development; the NCSC’s guidance places particular emphasis on asset inventory and knowing what software an organisation runs, rather than on SBOMs as a specific instrument. The primary harmonisation challenge is not definitional but implementation: ensuring that organisations operating across jurisdictions face consistent rather than contradictory requirements.

For OSAI, harmonisation is at an earlier stage. The OSAID provides a shared definitional foundation. The Linux Foundation’s AIBOM work provides a shared technical framework for provenance documentation. G7 discussions provide a multilateral forum. What is missing is the translation of these foundations into consistent regulatory requirements across jurisdictions; and the academic literature provides almost no comparative analysis of how to achieve this. No included study systematically compares how different regulatory approaches affect security outcomes, or what harmonisation would require in practice.

Implications

A pro-innovation, risk-based, and guidance-led approach of the kind the UK has adopted is coherent but faces a specific challenge: the platform evidence shows that voluntary adoption has not produced the documentation and governance norms that the market has failed to generate spontaneously. Policymakers should consider whether such frameworks need mechanisms to incentivise compliance that go beyond voluntary adoption, particularly given that EU mandatory requirements will create compliance pressure on organisations operating across both markets regardless. Standards development through ISO/IEC JTC 1/SC 42 and ETSI represents the most immediate opportunity to shape international norms for open-source software and AI security. Active engagement in these processes is the most leveraged intervention available at this moment.5.5 Platform-level evidence: GitHub and Hugging Face

The regulatory and mitigation frameworks describe what should happen in a well-governed open-source ecosystem. The platform analysis in this review provides direct empirical evidence of what actually happens, grounding the governance discussion in the observable behaviour of the two platforms through which open-source AI and OSS are primarily distributed at scale.

What the platforms say they require

Both Hugging Face and GitHub publish guidance on documentation and security practices. Hugging Face’s model card framework asks developers publishing models to document: intended use and out-of-scope uses; training data sources and any known limitations or biases; evaluation results; and known risks and recommendations for downstream users. These fields exist specifically to give users the information they need to assess whether a model is appropriate for their use case. GitHub’s security advisory system, dependency scanning via Dependabot, and secret scanning features are documented and actively recommended by NCSC and CISA as baseline practices for any OSS repository. Both platforms have therefore established voluntary documentation and security standards against which actual practice can be assessed.

What the analysis found

The GitHub search used keywords combining AI functionality terms and security practice terms to identify repositories where both topics were substantively present. Approximately 2,000 repositories were identified as relevant. Of those, 131 (around 6%) contained content substantively addressing both AI functionality and security practice in a meaningful way: this means repositories that included security documentation, vulnerability disclosures, or explicit treatment of security risks alongside functional AI code. The remaining 94% of repositories reviewed contained no meaningful security content of either kind. It is important to note that this search covered AI-related repositories specifically; a comparable analysis of OSS-only repositories on GitHub covering traditional software libraries and tools without AI components was not conducted in this review. That gap in the evidence base means a direct like-for-like comparison between OSS and OSAI security documentation norms on GitHub cannot be made from this data alone, though the OSS ecosystem’s more established CVE tracking and security advisory norms suggest coverage would be higher.

Of the 10,000 most downloaded models on Hugging Face with permissive open-source licences, 15 included security-relevant content in their model cards after screening. Of the initial 10,000 models, 218 matched security-related keywords; of those 218, only 15 contained information that was security-relevant rather than incidentally mentioning a security-adjacent term. A developer selecting from the most widely used open-source AI models has a 1-in-667 chance of finding any security information at all about what they are downloading. Given that Hugging Face’s own model card framework explicitly asks for this information, the 0.2% figure represents the gap between what the platform requests and what developers provide.

Why this matters — what a developer cannot do without security documentation

Security documentation in this context is not a bureaucratic requirement. It is the information that enables a developer to make basic security assessments before deploying a model in a production system. Without it, a developer cannot determine:

• whether the model’s training data included personal or sensitive data that could be reconstructed through model inversion attacks; a known risk documented by Al-Kharusi et al. (2024)
• whether known vulnerabilities have been identified and addressed since the model’s original release, or whether the model has been evaluated for adversarial robustness
• whether the weights available for download are identical to those released by the original developer, or whether they have been modified; a weight tampering risk with no detection mechanism absent integrity verification
• what the model’s intended use case and known failure modes are, and whether the deployment context is within the scope the developer designed and tested for

In traditional software, this information would appear in a security advisory, a CVE entry, a changelog, or an SBOM. In the financial services sector, product disclosure requirements attached to distribution ensure that users receive material risk information before adoption. In pharmaceuticals, package inserts serve the same function. No equivalent mechanism exists for open-source AI model distribution, and the platform analysis demonstrates that voluntary norms have not filled the gap.

Contextualising the proportions

The OSS ecosystem has its own documentation gaps: SBOM adoption is far from universal, and security advisory coverage is uneven across the long tail of less-maintained packages. But the OSS ecosystem has at least established the infrastructure for these norms: CVE tracking exists, security advisory systems are in place, and tools like Dependabot and VULCURATOR provide automated support for vulnerability identification. For open-source AI model distribution, none of this infrastructure exists. The 0.2% figure does not mean AI models are more secure than OSS; it means security is not yet a norm in how models are released, even on platforms that have explicitly requested it.

Implications

Platform-level governance is an area where policymakers have leverage that neither individual developers nor downstream users possess. Attaching documentation requirements to distribution platforms, rather than attempting to change individual developer behaviour across thousands of model releases, addresses the information gap at scale. This approach has clear precedent: financial product disclosure requirements are attached to distribution platforms and intermediaries rather than to individual issuers; pharmaceutical labelling requirements are attached to the point of sale rather than to individual prescribers. The same logic applies here. Policymakers should consider engaging directly with Hugging Face and GitHub on minimum documentation standards and exploring whether platform-level obligations, whether through regulatory requirement, procurement conditions, or sector-specific guidance, can produce the documentation norms that voluntary adoption has demonstrably failed to generate.

6. Conclusions and recommendations

The evidence reviewed across definitions, risks, mitigations, regulatory frameworks, and platform practice tells a consistent story. For open-source software, a mature governance infrastructure exists. In this case definitions are settled, risk categories are well-documented, mitigation frameworks are operationally tested, and real-world incidents including Log4Shell and XZ Utils have produced concrete lessons that have been absorbed into guidance. The gaps are in implementation and coverage, not in the conceptual framework. For open-source AI, almost none of this is true. Definitions are contested, upstream risks are under-addressed by existing frameworks, mitigation evidence is thin, and the platform analysis shows that voluntary documentation norms have not taken hold at any meaningful scale. The chardet case illustrates what happens when AI tools are applied to OSS without governance frameworks that can handle the resulting ambiguity, and it is an early signal of a much larger class of problem.

The five recommendations below are grounded in those findings.

6.1 Establish working definitions of open-source software and open-source AI for UK policy purposes

For open-source software, the Open-Source Initiative’s Open-Source Definition (OSD) is the most widely adopted international reference point and is already used implicitly by NCSC, CISA, and NIST. The UK Government should consider adopting it explicitly as the working reference for policy purposes, particularly in articulating how OSS governance obligations apply to AI systems that use OSS as their foundational infrastructure layer, a question the OSD alone does not resolve.

For open-source AI, no equivalent settled definition exists. Policymakers should consider anchoring a working definition in the OSAID framework. This would distinguish three governance-relevant categories. Fully open-source AI systems are those in which code, training data, and model parameters are all available under open terms. Open-weight models are those in which parameters are publicly available but training data and data methodology are not. Partially open configurations are those in which some but not all artefact layers are disclosed. Security obligations should then be calibrated to what is open. Fully open systems carry the full range of documentation and provenance obligations. Open-weight models carry the specific obligations associated with irreversible distribution, including pre-release evaluation and training data filtering. Partially open systems carry obligations proportionate to their disclosure profile. The working definition proposed in this review’s findings section provides a draft formulation that could serve as a starting point.

6.2 Lead development of provenance and documentation standards for both open-source software and open-source AI

The near-total absence of security documentation across widely used open-source AI models, 15 out of 10,000 on Hugging Face, is the clearest practical finding of this review. But the documentation gap affects OSS as well: SBOM adoption remains uneven across the OSS ecosystem, and the Log4Shell incident demonstrated at scale what happens when organisations cannot inventory their open-source dependencies. The difference is that OSS at least has the SBOM concept, established tooling, and a growing body of guidance. Open-source AI has none of this.

Policymakers should consider leading development of the AI equivalent of the SBOM, an AI Bill of Materials covering training data provenance, model lineage, fine-tuning history, configuration settings, and known vulnerabilities, building on the Linux Foundation’s AIBOM work with SPDX 3.0 and the G7’s 2025 SBOM-for-AI guidelines rather than starting from scratch. For OSS, consideration should be given to making SBOM adoption an explicit requirement in public procurement and critical sector contexts, where the evidence base for its value is now sufficient to support a stronger stance than voluntary recommendation. Industry could adopt existing openness assessment tools such as the Linux Foundation’s Model Openness Framework, the European Open-Source AI Index^{[footnote 34]}, and the Stanford Foundation Model Transparency Index^{[footnote 35]} as practical instruments for operationalising openness criteria in the interim.

6.3 Engage with platform operators on governance requirements for model-hosting and code-distribution platforms

Hugging Face and GitHub are the primary distribution infrastructure for open-source AI models and open-source software respectively. Both platforms publish documentation standards, Hugging Face’s model card framework and GitHub’s security advisory and dependency scanning features, that voluntary adoption has demonstrably failed to populate. Of the 10,000 most downloaded open-source AI models on Hugging Face, only 15 included security-relevant documentation despite the platform explicitly requesting it.

Policymakers should consider engaging directly with platform operators on minimum documentation standards, contributor verification mechanisms, and model integrity validation requirements for both OSS and OSAI. Where voluntary engagement does not produce results, policymakers should consider whether platform-level obligations through regulatory requirement, public procurement conditions, or sector-specific guidance are warranted. The precedent exists in other regulated sectors: financial product disclosure requirements are attached to distribution platforms rather than individual issuers; pharmaceutical labelling requirements apply at the point of distribution rather than to individual manufacturers. The same logic applies to open-source AI models and OSS components used in regulated contexts.

6.4 Be explicit about the limits of current evidence — for both OSS and OSAI

The evidence base does not support the claim that any existing strategy adequately addresses the full range of security risks for either open-source software or open-source AI. For OSS, the evidence supporting specific practices such as SBOM adoption, dependency scanning, vulnerability disclosure is reasonably strong at the tool and technique level, but empirical evidence that these practices reduce incident rates at ecosystem scale is limited. For open-source AI, the evidence base is weaker still: no study evaluates whether documentation standards reduce security incidents, whether platform governance mechanisms improve outcomes, or whether any regulatory requirement produces measurable change in developer behaviour.

Any framework document should therefore distinguish clearly between three categories: 1) practices supported by strong empirical evidence; 2) practices supported by expert consensus, regulatory analogy, and cross-jurisdictional precedent; and 3) practices that remain under-evidenced and are being adopted on the basis of reasonable inference rather than demonstrated effectiveness. This is not a weakness in the framework. It provides the basis for building evaluation mechanisms that can strengthen it over time. Policymakers should commit to reviewing and updating its framework as evidence accumulates, rather than treating initial adoption as the endpoint.

6.5 Engage in shaping international norms for open-source software and open-source AI security

The regulatory landscape for open-source software and open-source AI security is not yet settled. The EU AI Act’s open-source exemption threshold remains undefined in implementing guidance, creating live ambiguity about which open-weight models retain their exemption. In the United States, CISA’s voluntary secure-by-design programme has not produced mandatory requirements for OSS or OSAI security, NIST’s AI Risk Management Framework remains advisory, and the status of executive-level AI governance commitments is uncertain. This means that the world’s largest open-source software and AI ecosystem operates without enforceable baseline security standards. G7 SBOM-for-AI guidelines are at an early stage. The moment for shaping norms has not passed, but it is not indefinite.

Governments and policymakers, the UK among them, have a specific opportunity, through engagement with global standards development organisations including ISO/IEC JTC 1/SC 42 for AI trustworthiness standards and ETSI for AI security standards, to shape the technical standards that will underpin whatever regulatory requirements eventually emerge across jurisdictions. Standards compliance, even where not legally mandated, becomes a de facto market requirement when embedded in procurement specifications and sector regulators’ guidance. Shaping those standards now is more leveraged than attempting to influence regulatory requirements after they have crystallised. The convergence around secure-by-design principles, provenance transparency, and risk-proportionate governance across the EU, US, G7, and OECD frameworks provides the common ground from which that engagement can proceed.

Appendix A: academic literature search methodology

Search Strategy, Screening Criteria, and PRISMA Flow Diagram — Academic Literature

Academic literature was identified through a systematic search following the PRISMA guidelines (Preferred Reporting Items for Systematic Reviews and Meta-Analyses), ensuring the review is both methodologically rigorous and replicable. Search terms targeted the intersection of three domains: open-source software and open-source AI (including licensing, repositories, model weights, and datasets); AI and machine learning systems (including models, pipelines, and deployment); and security (including vulnerabilities, adversarial attacks, supply chain, and governance). A total of 14,561 records were identified across eight platforms: Scopus, Web of Science, IEEE Xplore, ACM Digital Library, arXiv, SSRN, SpringerLink, and ScienceDirect. All platforms were searched using the same three-domain keyword intersection logic, adapted where necessary for platform-specific search interfaces.

Screening process

A multistage screening process was applied following the PRISMA framework. The stages of the process are Identification, Screening, Eligibility and Inclusion. At the Identification stage a total of 14,561 records were identified for the review. The Screening stage involved removing duplicates, after which the Title, Keyword and Abstract screening were carried out. After the duplicate removal, Keyword and Title screening of the records retained 249 for further review. The Abstract screening resulted in excluding 152 records and including 97, completing the Screening stage of PRISMA process. At the Eligibility stage, Full-text review against the inclusion and exclusion criteria confirmed that 54 records were less relevant to the study. The Inclusion stage resulted 43 final records as eligible for the final academic literature review.

Inclusion and exclusion criteria

A record was included if it was published between 2020 and 2026, written in English, published in a peer-reviewed venue across computer science, cybersecurity, AI, or software engineering, and addressed OSS or AI security, governance, vulnerabilities, or mitigation strategies. Records were excluded if they were not peer-reviewed, were duplicated across platforms, or addressed cybersecurity topics without meaningful relevance to open-source or AI systems.

Quality appraisal

Each academic record was assessed against five criteria: authorship (1–3: clarity of researcher credentials and expertise), scholarly venue authority (1–3: credibility and selectivity of the journal or conference), publication type (1–3: level of peer review and formality), content quality (1–3: methodological rigour and evidential strength), and recency (1–3: timeliness of the contribution). Two reviewers applied these criteria independently, with disagreements resolved by a third arbitrating reviewer, and inter rater reliability was high (Cohen’s k =0.9). A minimum score of 8 out of 15 was required for inclusion.

Limitations

The search is limited to records indexed on the eight platforms listed above and to material published in English. The use of keyword intersection logic may exclude relevant work that does not use the specific terminology searched. The academic literature search was conducted using structured database queries rather than full-text analysis, which may undercount relevant material in adjacent fields. These limitations are consistent with the PRISMA framework and do not affect the validity of the findings within the scope defined.

Figure 1: PRISMA flow diagram for academic literature

This flow diagram shows how records from the academic database search were narrowed to the final included set, in four stages. Identification: 14,561 records were identified through the academic database search, and 6,279 remained after duplicates were removed. Screening 750 records were screened based on keywords, title and abstract using a script, with 5,529 excluded as irrelevant to the study; 249 records were then screened based on title, with 501 excluded after reading the full article as irrelevant to the study. Eligibility: 43 full-text articles were assessed for eligibility, with 54 excluded after reading the full article as irrelevant to the study. Included: 43 records were included after full review.

Appendix B: grey literature search methodology

Search Strategy, Screening Criteria, and PRISMA Flow Diagram — Grey Literature

Grey literature was identified through four complementary search methods, each targeting a different source type. The keyword strategy for platform searches followed the same three-domain intersection logic used in the academic literature search — covering open-source, AI/ML, and security terms — adapted for platform-specific search interfaces. All materials were screened against common inclusion and exclusion criteria and quality-appraised using a standardised credibility scoring matrix.

Method 1: Institutional repository searches

Reports, advisories, guidance, and standards from government agencies and standards bodies — including NCSC, CISA, ENISA, NIST, ISO/IEC, and OWASP — were identified through manual searches of institutional publication pages and curated repositories.

Method 2: Google SERP searches

Site-restricted keyword searches targeting policy, regulatory, and technical documents indexed on the open web but not captured through institutional repositories.

Method 3: Platform-specific searches (GitHub and Hugging Face)

API-driven searches were used to identify repositories and models at the intersection of open-source AI and security.

For GitHub, the GitHub Search API was queried using 540 keyword combinations across open-source, AI, and security terms, filtered to repositories with more than 50 stars. After deduplication, approximately 2,000 unique repositories were returned. Keyword screening for genuine relevance to both AI and security retained 131. These were then reviewed for eligibility against the review’s inclusion criteria; 49 were confirmed as eligible for inclusion. Repositories where security vocabulary was incidental — for example, tools described as “secure” to denote deployment properties rather than security functionality — and repositories applying AI to traditional cybersecurity tasks rather than addressing the security of AI systems themselves were excluded. All 49 eligible repositories were quality-appraised using the review’s five-criterion credibility matrix and scored at or above the 8/15 minimum threshold.

For Hugging Face, the 10,000 most downloaded models were retrieved via the Hugging Face API and filtered for permissive open-source licences (Apache 2.0, MIT, BSD-3-Clause, GPL-3.0, AGPL-3.0, CC-BY-4.0, and CC-BY-SA-4.0). Model card metadata was scanned for security-related keywords, yielding 218 initial matches. A second classification stage separated models matching genuinely security-specific terms — such as vulnerability, adversarial, attack, and security — from those matching only generic ML vocabulary — such as eval, robust, and risk — reducing the set to 15. Eligibility review against the review’s inclusion criteria confirmed 3 as substantively relevant. Models where security-specific vocabulary appeared in non-security contexts — such as “adversarial” referring to QA evaluation benchmarks or “safety” appearing in generic model card boilerplate — were excluded. All 3 eligible models were quality-appraised using the review’s five-criterion credibility matrix and scored at or above the 8/15 minimum threshold.

The platform search strategy is conservative. It relies on structured metadata and keyword matching rather than full-text analysis of documentation, and is limited to models and repositories with sufficient activity to appear in ranked results. The yield is therefore more likely to undercount than overcount security-relevant material in the open-source AI ecosystem.

Method 4: Targeted organisation searches

Direct searches of publication archives from key industry, policy, and research organisations — including national cyber authorities (NCSC, CISA, DCMS); standards bodies (NIST, OWASP, CIS); international organisations (ENISA, EU JRC, OECD); industry associations (TechUK, OpenUK, Snyk, Sonatype, Mandiant Google Cloud); open-source ecosystem stewards (OpenSSF, Linux Foundation, CNCF); and think tanks and research institutions (RAND Corporation, Brookings Institution) to ensure coverage of major stakeholders not fully captured by Methods 1–3.

Inclusion and exclusion criteria

A record was included if it was published from 2020 onwards, written in English, authored by a government agency, standards body, or reputable industry or platform organisation, and addressed OSS or AI security, governance, vulnerabilities, or mitigation. Records were excluded if they lacked institutional authority, were marketing materials, or were duplicated across methods.

Quality appraisal

Each record was scored on five criteria: authorship (1–3), institutional authority (1–3), publication venue (1–3), content quality (1–3), and recency (1–3). A minimum score of 8 out of 15 was required for inclusion.

Figure 2: PRISMA flow diagram for grey literature

This flow diagram shows how grey literature records were narrowed to the final included set, in four stages. Identification: 193 records identified from varied sources including national cyber authorities (NCSC, DSIT, CISA), standards bodies (NIST, OWASP, CIS), international organisations (ENISA, EU JRC, OECD), open-source software stewards (OpenSSF, Linux foundation, CNCF), industry associations (TechUK, OpenUK, SnyK, Sonatype, Google Cloud) and think tanks (RAND, Brooking institutions). Screening: relevance screening retained 188 grey literature records, over 2,000 GitHub records and 10,000 Hugging Face model were reviewed, most of wich were not relevant to security. Eligibility: 172 documents were included, with documents excluded where their insights did not aligned with at least one research question; Hugging Face records were screened from 218 down to 15, and GitHub records were screened to 131. Included: the final set comprised 172 grey literature documents, 3 Hugging Face models and 49 GitHub repositories.

Appendix C: bibliometric network analysis

VOSviewer Network Diagrams

Thematic Clusters, Keyword Co-occurrence, and Institutional Networks.

Figure 3: Thematic cluster map

Keyword co-occurence network in which each node, for example ‘circle’, represents a keyword. The line between two nodes indicates that the keywords appear together in the same publications. The size of the circle reflects how frequently the keyword occurs. Colours identify the fifteen thematic clusters identifiable within the network.

A dense core is formed by AI‑driven cybersecurity and intrusion detection, encompassing anomaly detection, threat intelligence, and automated mitigation, and represents the most mature and highly connected stream of research. Closely linked to this core is a set of clusters focused on adversarial machine learning, robustness, and explainable AI, reflecting efforts to harden AI systems against sophisticated attacks. A moderately connected group of clusters addresses open‑source software security and vulnerability management, including patching, malicious packages, and software supply‑chain threats, indicating an established but still fragmented body of work. Smaller, weakly connected clusters capture emerging open‑source AI–specific security topics, such as explainability, ethical and AI‑based hacking, agentic and self‑healing systems, which remain conceptually dispersed. Finally, blockchain‑centric and distributed security architectures appear as peripheral and exploratory clusters with limited integration into the core network. The sparse connectivity between mature open‑source software security and emerging open‑source AI security highlights a key evidence gap: while OSS supply‑chain security is well developed, its extension to AI‑centric and open‑source AI systems is not yet consolidated.

Figure 4: Co-authorship country network

Co-authorship country network in which each node represents a country, and a line between two nodes indicated a co-authorship relationship, meaning that researchers based in those countries have published together; countries with no lines have no recorded international co-authorship within this dataset. Label size reflects each country’s relative weight in the network, and coulours denote the co-authorship clusters assigned by VOSviewer’s clustering algorithm. 

Contributions dominated by China, United States, and India. These countries form the most visible and connected clusters, suggesting higher publication volume and stronger international co authorship ties. UK and European institutions are sparse and poorly networked, reflecting limited collaborative integration. This uneven network structure suggests that prevailing research agendas, methodological approaches, and threat framings are likely shaped by non UK contexts, potentially constraining the relevance and transferability of findings to UK specific infrastructure, regulatory environments, and security priorities.

Figure 5: Largest sub-network within co-authorship country network

Each node represents a country, and a line between two nodes indicates a co-authorship relationship, meaning that researchers based in those countries have published together. Node and label size reflect each country’s relative weight in the network, and colours denote the co-authorship clusters assigned by VOSviewer’s clustering algorithm.

Contributions dominated by China, United States, and India. UK and European institutions are sparse and poorly networked. This limits the extent to which the evidence base reflects UK-specific infrastructure, policy context, and threat environment. Note: In the VOSviewer visualisation, the relative positions of countries are determined by a clustering algorithm. Distances between countries are not to be interpreted as exact measures of collaboration strength or dissimilarity; instead, the visualisation highlights groupings of countries with similar co authorship patterns.

References

Academic sources

Al-Dmour, N.A., Hasan, M.K., Ajmal, M., Ali, M., Naseer, I., Ali, A., Al Hamadi, H. and Ali, N., 2023, March. An automated platform for gathering and managing open-source cyber threat intelligence. In 2023 International Conference on Business Analytics for Technology and Security (ICBATS) (pp. 1-7). IEEE.

Ali, B. and Chen, G.H. (2025) ‘Next-generation AI for advanced threat detection and security enhancement in DNS over HTTPS’, Journal of Network and Computer Applications, 244. https://doi.org/10.1016/j.jnca.2025.104326

Aljunaid, S.K., Almheiri, S.J., Dawood, H. and Khan, M.A., 2025. Secure and transparent banking: Explainable AI-driven federated learning model for financial fraud detection. Journal of Risk and Financial Management, 18(4), p.179.

Al-Kharusi, Y., Khan, A., Rizwan, M. and Bait-Suwailam, M.M. (2024) ‘Open-source artificial intelligence privacy and security: A review’, Computers, 13(12). https://doi.org/10.3390/computers13120311

Almheiri, S.J., Shah, A.A., Abbas, S., Ahmad, M. and Khan, M.A. (2025) ‘Smart sustainable cyber security: modelling an interpretable and transparent threat detection with explainable artificial intelligence’, Discover Sustainability, 6(1). https://doi.org/10.1007/s43621-025-01280-z

Alohali, M.A., Aljebreen, M., Ahmad, N., Alahmari, S., Albouq, S.S., Alqazzaz, A., Alkhiri, H. and Said, Y. (2025) ‘Privacy preserving blockchain integrated explainable artificial intelligence with two tier optimization for cyber threat detection and mitigation in the internet of things’, Scientific Reports, 15(1). https://doi.org/10.1038/s41598-025-10601-1

Balasubramanian, K., Baragur, A.G., Donadel, D., Sahabandu, D., Brighente, A., Ramasubramanian, B., Conti, M. and Poovendran, R. (2025) ‘CANLP: Intrusion detection for controller area networks using natural language processing and embedded machine learning’, IEEE Transactions on Dependable and Secure Computing, 22(6), pp. 7203-7214. https://doi.org/10.1109/TDSC.2025.3596516

Balasubramanian, P., Liyana, S., Sankaran, H., Sivaramakrishnan, S., Pusuluri, S., Pirttikangas, S. and Peltonen, E. (2025) ‘Generative AI for cyber threat intelligence: applications, challenges, and analysis of real-world case studies’, Artificial Intelligence Review, 58(11). https://doi.org/10.1007/s10462-025-11338-z

Basheer, N., Islam, S., Alwaheidi, M.K.S. and Papastergiou, S. (2024) ‘Adoption of deep-learning models for managing threat in API calls with transparency obligation practice for overall resilience’, Sensors, 24(15). https://doi.org/10.3390/s24154859

Borah, S., Dhabliya, D., Dhage, P., Shukla, J., Rai, S.K. and Bhattacharya, S., 2024, June. Collaborative Defense Strategies: AI, ML, and Cybersecurity: A Comprehensive Study. In International Conference on Frontiers of Intelligent Computing: Theory and Applications (pp. 451-462). Singapore: Springer Nature Singapore.

Ekisa, C., Briain, D.O. and Kavanagh, Y. (2021) ‘An open-source testbed to visualise ICS cybersecurity weaknesses and remediation strategies: A research agenda proposal’, in 2021 32nd Irish Signals and Systems Conference (ISSC). IEEE. https://doi.org/10.1109/ISSC52156.2021.9467852

Ergenç, D., Schenderlein, R. and Fischer, M. (2023) ‘TSNZeek: An open-source intrusion detection system for IEEE 802.1 time-sensitive networking’, in IFIP Networking Conference. IEEE. https://doi.org/10.23919/IFIPNetworking57963.2023.10186421

Foote, R., Sugunaraj, N. and Ranganthan, P., 2021. Low Cost ICS Network Scanning for Vulnerability Prevention. In International Summit Smart City 360° (pp. 332-350). Cham: Springer International Publishing.

Habibur Rahman, M., Sharif Hossen, M., Stephenson, N.H., Shah, V.K. and Da Silva, A., 2025. SAJD: Self-Adaptive Jamming Attack Detection in AI/ML Integrated 5G O-RAN Networks. arXiv e-prints, pp.arXiv-2511.

He, Y., Zamani, E., Yevseyeva, I. and Luo, C.J. (2023) ‘Artificial intelligence-based ethical hacking for health information systems: simulation study’, Journal of Medical Internet Research, 25. https://doi.org/10.2196/41748

Hussain, F., Chakranarayan, V., Jaber, F.A. and Shaker, R.J., 2025. Trust-Driven Blockchain-Enabled Deep Learning Architecture for Secure and Scalable IIoT Networks: Implications for Industrial Adoption and Market Differentiation. IEEE Communications Standards Magazine.

Kakani, P.K., Habibi, M.A., Balannagari, M.R.C., Costa-Pérez, X. and Schotten, H.D. (2025) ‘Mitigating ML-driven adversarial attacks on xApps using dynamic defense mechanisms’, IEEE Open Journal of the Communications Society, 6, pp. 6912-6929. https://doi.org/10.1109/OJCOMS.2025.3602200

Kaur, N. and Gupta, L. (2025) ‘Securing the 6G-IoT environment: A framework for enhancing transparency in artificial intelligence decision-making through explainable artificial intelligence’, Sensors, 25(3). https://doi.org/10.3390/s25030854

Lee, K.Y. and Yoo, J. (2025) ‘A proposal of a supply chain security model for generative AI’, in Information Security Applications (WISA 2024). Springer, pp. 324-335. https://doi.org/10.1007/978-981-96-1624-4_25

Li, Z.X., Lu, S.Q., Zhang, R., Zhao, Z.M., Liang, R.J., Xue, R., Li, W.H., Zhang, F. and Gao, S. (2023) ‘VulHunter: Hunting vulnerable smart contracts at EVM bytecode-level via multiple instance learning’, IEEE Transactions on Software Engineering, 49(11), pp. 4886-4916. https://doi.org/10.1109/TSE.2023.3317209

Lu Y, Tang W, Johnson M, Jung T, Jiang M. (2025) A Decentralized Retrieval Augmented Generation System with Source Reliabilities Secured on Blockchain. arXiv preprint arXiv:2511.07577. 2025 Nov 10.

Maniyat, V.B. and Arunkumar, B.R., 2025, August. An Integrated Knowledge Graph and Graph Neural Network Framework for Scalable Cyber Threat Attribution and Proactive Defense. In 2025 Third International Conference on Networks, Multimedia and Information Technology (NMITCON) (pp. 1-6). IEEE.

Mishra, M., Pradhan, R.R., Agrawalla, K. and Bokka, R., 2025, May. AI for Cybersecurity Threat Detection: A Machine Enabled Computing Perspective. In 2025 International Conference on Advancements in Smart, Secure and Intelligent Computing (ASSIC) (pp. 1-5). IEEE.

Ndayipfukamiye, T., Ding, J., Sarwatt, D.S., Philipo, A.G. and Ning, H., 2025. Adversarial Defense in Cybersecurity: A Systematic Review of GANs for Threat Detection and Mitigation. arXiv preprint arXiv:2509.20411.

Nguyen, T.C., Nguyen, N.T., Ung, V.G. and Vu, D.L., 2025. Towards Classifying Benign And Malicious Packages Using Machine Learning. arXiv preprint arXiv:2511.15033.

Nguyen, T.G., Le-Cong, T., Kang, H.J., Le, X.B.D. and Lo, D. (2022) ‘VULCURATOR: A vulnerability-fixing commit detector’, in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2022). ACM, pp. 1726-1730. https://doi.org/10.1145/3540250.3558936

Paltun, B.G. and Fuladi, R. (2024) ‘Introspective intrusion detection system through explainable AI’, in 2024 8th Cyber Security in Networking Conference (CSNet). IEEE, pp. 28-32. https://doi.org/10.1109/CSNET64211.2024.10851756

Pentela, V.K. and Deepalakshmi, P., 2025, May. Improved Threat Intelligence and Real-Time Protection with Next-Generation Firewall Solutions: Artificial Intelligence and Deep Learning. In 2025 Global Conference in Emerging Technology (GINOTECH) (pp. 1-6). IEEE.

Quincozes, V.E., Quincozes, S.E., Kazienko, J.F., Gama, S., Cheikhrouhou, O. and Koubaa, A. (2024) ‘A survey on IoT application layer protocols, security challenges, and the role of explainable AI in IoT (XAIoT)’, International Journal of Information Security, 23(3), pp. 1975-2002. https://doi.org/10.1007/s10207-024-00828-w

Ren, Y.T., Xiao, Y.J., Zhou, Y.H., Zhang, Z.Y. and Tian, Z.H. (2023) ‘CSKG4APT: A cybersecurity knowledge graph for advanced persistent threat organization attribution’, IEEE Transactions on Knowledge and Data Engineering, 35(6), pp. 5695-5709. https://doi.org/10.1109/TKDE.2022.3175719

Saad, S., Shi, K., Mamun, M. and Elmiligi, H. (2025). AutoML in Cybersecurity: An Empirical Study. arXiv preprint arXiv:2509.23621.

Salzano, F. and Pareschi, R. (2026) ‘Enhancing blockchain security through natural language processing and real-time monitoring’, International Journal of Parallel, Emergent and Distributed Systems, 41(1), pp. 151-166. https://doi.org/10.1080/17445760.2023.2272280

Sedar, R., Kalalas, C., Vázquez-Gallego, F. and Alonso-Zarate, J. (2024) ‘Deep reinforcement learning-based adversarial defense in vehicular communication systems’, in ICC 2024 - IEEE International Conference on Communications. IEEE, pp. 5250-5256. https://doi.org/10.1109/ICC51166.2024.10622762

Sheth, A., Achanta, A., Matam, P., Patel, A., Sharma, P., Janapareddy, N.V.P., Patil, B. and Gudur, V. (2025) ‘AI driven self-healing cybersecurity systems with agentic AI for adaptive threat response and resilience’, in IEEE Cloud Summit. IEEE, pp. 147-153. https://doi.org/10.1109/Cloud-Summit64795.2025.00030

Singh, A. and Dubey, S.K., 2024, October. Revolutionizing Malware Detection Techniques by using Predictive AI. In 2024 International Conference on Computing, Sciences and Communications (ICCSC) (pp. 1-6). IEEE.

Sood, I. and Sharma, V. (2025) ‘CINN-UTLC: A computationally intelligent neural network-based unsupervised transfer learning algorithm for ransomware detection’, Traitement du Signal, 42(3), pp. 1601-1615. https://doi.org/10.18280/ts.420331

Udoidiok, I. and Zhang, J.L. (2024) ‘When XAI meets CAPTCHA: A case study’, in 2024 Cyber Awareness and Research Symposium (CARS). IEEE. https://doi.org/10.1109/CARS61786.2024.10778641

Walkowski, M., Oko, J. and Sujecki, S. (2021) ‘Vulnerability management models using a common vulnerability scoring system’, Applied Sciences, 11(18). https://doi.org/10.3390/app11188735

Wang, X.D., Wang, S., Feng, P.B., Sun, K., Jajodia, S., Benchaaboun, S. and Geck, F. (2021) ‘PatchRNN: A deep learning-based system for security patch identification’, in 2021 IEEE Military Communications Conference (MILCOM). IEEE. https://doi.org/10.1109/MILCOM52596.2021.9652940

Wu, S.S., Chen, B., Sun, M.X., Duan, R.Y., Zhang, Q.X. and Huang, C. (2021) ‘DeepVuler: A vulnerability intelligence mining system for open-source communities’, in 2021 IEEE 20th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, pp. 598-605. https://doi.org/10.1109/TrustCom53373.2021.00090

Yakubu, P.B., Santana, L., Rahouti, M., Xin, Y., Chehri, A. and Aledhari, M., 2025. Automated and Explainable Denial of Service Analysis for AI-Driven Intrusion Detection Systems. arXiv preprint arXiv:2511.04114.

Yungaicela-Naula, N.M., Vargas-Rosales, C. and Pérez-Díaz, J.A. (2023) ‘SDN/NFV-based framework for autonomous defense against slow-rate DDoS attacks by using reinforcement learning’, Future Generation Computer Systems, 149, pp. 637-649. https://doi.org/10.1016/j.future.2023.08.007

GitHub repositories

aliasrobotics (2025) cai. Available at: https://github.com/aliasrobotics/cai (Accessed: 12 January 2026).

arm (2025) metis. Available at: https://github.com/arm/metis (Accessed: 12 January 2026).

Azure (2025) counterfit. Available at: https://github.com/Azure/counterfit (Accessed: 12 January 2026).

Azure (2025) PyRIT. Available at: https://github.com/Azure/PyRIT (Accessed: 12 January 2026).

Azure (2025) Security-Copilot. Available at: https://github.com/Azure/Security-Copilot (Accessed: 12 January 2026).

berylliumsec (2025) nebula. Available at: https://github.com/berylliumsec/nebula (Accessed: 12 January 2026).

chawins (2025) llm-sp. Available at: https://github.com/chawins/llm-sp (Accessed: 12 January 2026).

confident-ai (2025) deepteam. Available at: https://github.com/confident-ai/deepteam (Accessed: 12 January 2026).

cyproxio (2025) mcp-for-security. Available at: https://github.com/cyproxio/mcp-for-security (Accessed: 12 January 2026).

danny-avila (2025) LibreChat. Available at: https://github.com/danny-avila/LibreChat (Accessed: 12 January 2026).

dapr (2025) dapr-agents. Available at: https://github.com/dapr/dapr-agents (Accessed: 12 January 2026).

daytonaio (2025) daytona. Available at: https://github.com/daytonaio/daytona (Accessed: 12 January 2026).

ddzipp (2025) AutoAudit. Available at: https://github.com/ddzipp/AutoAudit (Accessed: 12 January 2026).

e2b-dev (2025) desktop. Available at: https://github.com/e2b-dev/desktop (Accessed: 12 January 2026).

faizann24 (2025) rogue. Available at: https://github.com/faizann24/rogue (Accessed: 12 January 2026).

FuzzingLabs (2025) fuzzforge_ai. Available at: https://github.com/FuzzingLabs/fuzzforge_ai (Accessed: 12 January 2026).

gadievron (2025) raptor. Available at: https://github.com/gadievron/raptor (Accessed: 12 January 2026).

InfinitiBit (2025) graphbit. Available at: https://github.com/InfinitiBit/graphbit (Accessed: 12 January 2026).

invariantlabs-ai (2025) invariant. Available at: https://github.com/invariantlabs-ai/invariant (Accessed: 12 January 2026).

JoseDeFreitas (2025) awesome-youtubers. Available at: https://github.com/JoseDeFreitas/awesome-youtubers (Accessed: 12 January 2026).

Koukyosyumei (2025) AIJack. Available at: https://github.com/Koukyosyumei/AIJack (Accessed: 12 January 2026).

Microsoft (2025) mcp-for-beginners. Available at: https://github.com/microsoft/mcp-for-beginners (Accessed: 12 January 2026).

mithril-security (2025) blindai. Available at: https://github.com/mithril-security/blindai (Accessed: 12 January 2026).

mrwadams (2025) stride-gpt. Available at: https://github.com/mrwadams/stride-gpt (Accessed: 12 January 2026).

msoedov (2025) agentic_security. Available at: https://github.com/msoedov/agentic_security (Accessed: 12 January 2026).

octelium (2025) octelium. Available at: https://github.com/octelium/octelium (Accessed: 12 January 2026).

openappsec (2025) openappsec. Available at: https://github.com/openappsec/openappsec (Accessed: 12 January 2026).

OWASP (2025) www-project-ai-security-and-privacy-guide. Available at: https://github.com/OWASP/www-project-ai-security-and-privacy-guide (Accessed: 12 January 2026).

OWASP (2025) www-project-top-10-for-large-language-model-applications. Available at: https://github.com/OWASP/www-project-top-10-for-large-language-model-applications (Accessed: 12 January 2026).

promptfoo (2025) promptfoo. Available at: https://github.com/promptfoo/promptfoo (Accessed: 12 January 2026).

ProtectAI (2025) llm-guard. Available at: https://github.com/protectai/llm-guard (Accessed: 12 January 2026).

ProtectAI (2025) rebuff. Available at: https://github.com/protectai/rebuff (Accessed: 12 January 2026).

rnchg (2025) APT. Available at: https://github.com/rnchg/APT (Accessed: 12 January 2026).

Safe3 (2025) uusec-waf. Available at: https://github.com/Safe3/uusec-waf (Accessed: 12 January 2026).

SecureAI-Tools (2025) SecureAI-Tools. Available at: https://github.com/SecureAI-Tools/SecureAI-Tools (Accessed: 12 January 2026).

SmythOS (2025) sre. Available at: https://github.com/SmythOS/sre (Accessed: 12 January 2026).

sugarforever (2025) chat-ollama. Available at: https://github.com/sugarforever/chat-ollama (Accessed: 12 January 2026).

superagent-ai (2025) superagent. Available at: https://github.com/superagent-ai/superagent (Accessed: 12 January 2026).

Tencent (2025) AICGSecEval. Available at: https://github.com/Tencent/AICGSecEval (Accessed: 12 January 2026).

test-zeus-ai (2025) testzeus-hercules. Available at: https://github.com/test-zeus-ai/testzeus-hercules (Accessed: 12 January 2026).

thalesgroup-cert (2025) Watcher. Available at: https://github.com/thalesgroup-cert/Watcher (Accessed: 12 January 2026).

TracecatHQ (2025) tracecat. Available at: https://github.com/TracecatHQ/tracecat (Accessed: 12 January 2026).

usestrix (2025) strix. Available at: https://github.com/usestrix/strix (Accessed: 12 January 2026).

utkusen (2025) promptmap. Available at: https://github.com/utkusen/promptmap (Accessed: 12 January 2026).

vectra-ai-research (2025) Halberd. Available at: https://github.com/vectra-ai-research/Halberd (Accessed: 12 January 2026).

vectra-ai-research (2025) MAAD-AF. Available at: https://github.com/vectra-ai-research/MAAD-AF (Accessed: 12 January 2026).

vxcontrol (2025) pentagi. Available at: https://github.com/vxcontrol/pentagi (Accessed: 12 January 2026).

whylabs (2025) langkit. Available at: https://github.com/whylabs/langkit (Accessed: 12 January 2026).

yashab-cyber (2025) HackGpt. Available at: https://github.com/yashab-cyber/HackGpt (Accessed: 12 January 2026).

HuggingFace model cards

bartowski (2025) PocketDoc_Dans-PersonalityEngine-V1.3.0-24b-GGUF. Available at: https://huggingface.co/bartowski/PocketDoc_Dans-PersonalityEngine-V1.3.0-24b-GGUF (Accessed: 12 January 2026).

deepset (2025) deberta-v3-base-squad2. Available at: https://huggingface.co/deepset/deberta-v3-base-squad2 (Accessed: 12 January 2026).

deepset (2025) roberta-base-squad2. Available at: https://huggingface.co/deepset/roberta-base-squad2 (Accessed: 12 January 2026).

deepset (2025) roberta-base-squad2-distilled. Available at: https://huggingface.co/deepset/roberta-base-squad2-distilled (Accessed: 12 January 2026).

deepset (2025) roberta-large-squad2. Available at: https://huggingface.co/deepset/roberta-large-squad2 (Accessed: 12 January 2026).

deepset (2025) tinyroberta-squad2. Available at: https://huggingface.co/deepset/tinyroberta-squad2 (Accessed: 12 January 2026).

EleutherAI (2025) deep-ignorance-pretraining-stage-unfiltered. Available at: https://huggingface.co/EleutherAI/deep-ignorance-pretraining-stage-unfiltered (Accessed: 12 January 2026).

EleutherAI (2025) deep-ignorance-unfiltered. Available at: https://huggingface.co/EleutherAI/deep-ignorance-unfiltered (Accessed: 12 January 2026).

eliasalbouzidi (2025) distilbert-nsfw-text-classifier. Available at: https://huggingface.co/eliasalbouzidi/distilbert-nsfw-text-classifier (Accessed: 12 January 2026).

geoffmunn (2025) Qwen3Guard-Stream-0.6B. Available at: [https://huggingface.co/geoffmunn/Qwen3Guard-Stream-0.6B]https://huggingface.co/geoffmunn/Qwen3Guard-Stream-0.6B (Accessed: 12 January 2026).

jackaduma (2023) SecBERT. Available at: https://huggingface.co/jackaduma/SecBERT (Accessed: 12 January 2026).

PocketDoc (2025) Dans-PersonalityEngine-V1.3.0-24b. Available at: https://huggingface.co/PocketDoc/Dans-PersonalityEngine-V1.3.0-24b (Accessed: 12 January 2026).

Protect AI (2025) deberta-v3-base-prompt-injection. Available at: https://huggingface.co/protectai/deberta-v3-base-prompt-injection (Accessed: 12 January 2026).

TheBloke (2024) Mixtral-8x7B-Instruct-v0.1-AWQ. Available at: https://huggingface.co/TheBloke/Mixtral-8x7B-Instruct-v0.1-AWQ (Accessed: 12 January 2026).

vicgalle (2025) Configurable-Hermes-2-Pro-Llama-3-8B. Available at: https://huggingface.co/vicgalle/Configurable-Hermes-2-Pro-Llama-3-8B (Accessed: 12 January 2026).

NCSC sources

National Cyber Security Centre (2025) New ETSI standard protects AI systems from evolving cyber threats. Blog post. Available at: https://www.ncsc.gov.uk/blog-post/new-etsi-standard-protects-ai-systems-from-evolving-cyber-threats (Accessed: 12 January 2026).

National Cyber Security Centre (2025) From bugs to bypasses: adapting vulnerability disclosure for AI safeguards. Blog post. Available at: https://www.ncsc.gov.uk/blog-post/from-bugs-to-bypasses-adapting-vulnerability-disclosure-for-ai-safeguards (Accessed: 12 January 2026).

National Cyber Security Centre (2024) Raising the cyber resilience of software ‘at scale’. Blog post. Available at: https://www.ncsc.gov.uk/blog-post/raising-cyber-resilience-software-at-scale (Accessed: 12 January 2026).

National Cyber Security Centre (2025) Impact of AI on cyber threat from now to 2027. Report. Available at: https://www.ncsc.gov.uk/report/impact-ai-cyber-threat-now-2027 (Accessed: 12 January 2026).

National Cyber Security Centre (2024) Machine learning principles. Guidance. Available at: https://www.ncsc.gov.uk/collection/machine-learning-principles (Accessed: 12 January 2026).

National Cyber Security Centre (2023) Thinking about the security of AI systems. Blog post. Available at: https://www.ncsc.gov.uk/blog-post/thinking-about-security-ai-systems (Accessed: 12 January 2026).

National Cyber Security Centre (2024) Machine learning security principles updated. Blog post. Available at: https://www.ncsc.gov.uk/blog-post/machine-learning-security-principles-updated (Accessed: 12 January 2026).

National Cyber Security Centre (2025) Cyber Assessment Framework v4.0 released in response to growing threat. Blog post. Available at: https://www.ncsc.gov.uk/blog-post/caf-v4-0-released-in-response-to-growing-threat (Accessed: 12 January 2026).

National Cyber Security Centre (2024) AI and cyber security: what you need to know. Guidance. Available at: https://www.ncsc.gov.uk/guidance/ai-and-cyber-security-what-you-need-to-know (Accessed: 12 January 2026).

National Cyber Security Centre (2024) The near-term impact of AI on the cyber threat. Report. Available at: https://www.ncsc.gov.uk/report/impact-of-ai-on-cyber-threat (Accessed: 12 January 2026).

National Cyber Security Centre (2023) New cyber security training packages launched to manage supply chain risk. Blog post. Available at: https://www.ncsc.gov.uk/blog-post/new-cyber-security-training-packages-launched-to-manage-supply-chain-risk (Accessed: 12 January 2026).

National Cyber Security Centre (2023) Guidelines for secure AI system development. Guidance. Available at: https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development (Accessed: 12 January 2026).

DSIT sources

Department for Science, Innovation and Technology (2024) Cyber security risks to artificial intelligence. Report. Available at: https://www.gov.uk/government/publications/research-on-the-cyber-security-of-ai/cyber-security-risks-to-artificial-intelligence (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) Code of Practice for the Cyber Security of AI. Report. Available at: https://www.gov.uk/government/publications/ai-cyber-security-code-of-practice/code-of-practice-for-the-cyber-security-of-ai (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2023) A pro-innovation approach to AI regulation. Report. Available at: https://www.gov.uk/government/publications/ai-regulation-a-pro-innovation-approach/white-paper (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) AI for Science Strategy. Report. Available at: https://www.gov.uk/government/publications/ai-for-science-strategy/ai-for-science-strategy (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2024) A Code of Practice for Software Vendors: call for views. Report. Available at: https://www.gov.uk/government/calls-for-evidence/a-code-of-practice-for-software-vendors-call-for-views (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2021) Call for views on cyber security in supply chains and managed service providers. Report. Available at: https://www.gov.uk/government/publications/call-for-views-on-supply-chain-cyber-security/call-for-views-on-cyber-security-in-supply-chains-and-managed-service-providers (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) A UK cyber growth action plan - final report. Report. Available at: https://www.gov.uk/government/publications/cyber-growth-action-plan-2025/a-uk-cyber-growth-action-plan-final-report (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2022) Government Cyber Security Strategy: 2022 to 2030. Report. Available at: https://www.gov.uk/government/publications/government-cyber-security-strategy-2022-to-2030/government-cyber-security-strategy-2022-to-2030-html (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2024) Impact of AI on the regulation of medical products. Report. Available at: https://www.gov.uk/government/publications/government-cyber-security-strategy-2022-to-2030/government-cyber-security-strategy-2022-to-2030-html (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) Generative artificial intelligence (AI) in education. Report. Available at: https://www.gov.uk/government/publications/generative-artificial-intelligence-in-education/generative-artificial-intelligence-ai-in-education (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) AI action plan for justice. Report. Available at: https://www.gov.uk/government/publications/ai-action-plan-for-justice/ai-action-plan-for-justice (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) Trusted third-party AI assurance roadmap. Report. Available at: https://www.gov.uk/government/publications/trusted-third-party-ai-assurance-roadmap/trusted-third-party-ai-assurance-roadmap (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) G7 cyber expert group statement on Artificial Intelligence and Cybersecurity: September 2025. Report. Available at: https://www.gov.uk/government/publications/g7-cyber-expert-group-statement-on-ai-and-cybersecurity/g7-cyber-expert-group-statement-on-artificial-intelligence-and-cybersecurity-september-2025 (Accessed: 12 January 2026).

Department for Science, Innovation and Technology (2025) Government response to the call for views on the code of practice for software vendors. Report. Available at: https://www.gov.uk/government/publications/government-response-on-the-code-of-practice-for-software-vendors/government-response-to-the-call-for-views-on-the-code-of-practice-for-software-vendors (Accessed: 12 January 2026).

CISA

CISA. 2024. Exploring Memory Safety in Critical Open-Source Projects. https://www.cisa.gov/resources-tools/resources/exploring-memory-safety-critical-open-source-projects (Accessed: 12 January 2026)

CISA; Cable, J.; Black, A. 2023. Open-Source Software Must Start with Secure Code. https://www.cisa.gov/news-events/news/open-source-software-must-start-secure-code (Accessed: 12 January 2026)

CISA. 2022. Securing the Software Supply Chain. https://www.cisa.gov/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF (Accessed: 12 January 2026)

CISA. 2023. Improving Security of Open-Source Software in Operational Technology and Industrial Control Systems. https://www.cisa.gov/sites/default/files/2023-10/Fact_Sheet_Improving_OSS_in_OT_ICS_508c.pdf (Accessed: 12 January 2026)

CISA. 2023. CISA Open-Source Software Security Roadmap. https://www.cisa.gov/resources-tools/resources/cisa-open-source-software-security-roadmap (Accessed: 12 January 2026)

CISA. 2023. Information and Communications Technology Supply Chain Risk Management. https://www.cisa.gov/information-and-communications-technology-supply-chain-risk-management (Accessed: 12 January 2026)

CISA. 2021. Defending Against Software Supply Chain Attacks. https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508.pdf (Accessed: 12 January 2026)

CISA. 2025. AI Cybersecurity Collaboration Playbook. https://www.cisa.gov/resources-tools/resources/ai-cybersecurity-collaboration-playbook (Accessed: 12 January 2026)

CISA. 2025. AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems. https://www.cisa.gov/resources-tools/resources/ai-data-security-best-practices-securing-data-used-train-operate-ai-systems (Accessed: 12 January 2026)

CISA. 2024. Risk in Focus: Generative AI and the 2024 Election Cycle. https://www.cisa.gov/resources-tools/resources/risk-focus-generative-ai-and-2024-election-cycle (Accessed: 12 January 2026)

CISA. 2024. Pilot for Artificial Intelligence Enabled Vulnerability Detection. https://www.cisa.gov/resources-tools/resources/pilot-artificial-intelligence-enabled-vulnerability-detection (Accessed: 12 January 2026)

CISA. 2025. United in Cyber Defense: A Model for Operational Collaboration. https://www.cisa.gov/news-events/news/united-cyber-defense-model-operational-collaboration (Accessed: 12 January 2026)

CISA. 2023. Open-Source Security. https://www.cisa.gov/opensource (Accessed: 12 January 2026)

ENISA

ENISA. 2025. ENISA Sectorial Threat Landscape – Public Administration. https://www.enisa.europa.eu/publications/enisa-sectorial-threat-landscape-public-administration (Accessed: 12 January 2026)

ENISA. 2020. Advancing Software Security in the EU. https://www.enisa.europa.eu/publications/advancing-software-security-through-the-eu-certification-framework (Accessed: 12 January 2026)

ENISA. 2023. Cybersecurity of AI and Standardisation. https://www.enisa.europa.eu/publications/cybersecurity-of-ai-and-standardisation (Accessed: 12 January 2026)

ENISA. 2023. Multilayer Framework for Good Cybersecurity Practices for AI. https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai (Accessed: 12 January 2026)

ENISA. 2020. Artificial Intelligence Cybersecurity Challenges. https://www.enisa.europa.eu/publications/artificial-intelligence-cybersecurity-challenges (Accessed: 12 January 2026)

ENISA. 2023. Cybersecurity and Privacy in AI – Medical Imaging Diagnosis. https://www.enisa.europa.eu/publications/cybersecurity-and-privacy-in-ai-medical-imaging-diagnosis (Accessed: 12 January 2026)

ENISA. 2023. Cybersecurity and Privacy in AI – Forecasting Demand on Electricity Grids. https://www.enisa.europa.eu/publications/cybersecurity-and-privacy-in-ai-forecasting-demand-on-electricity-grids (Accessed: 12 January 2026)

ENISA. 2021. Cybersecurity Challenges in the Uptake of Artificial Intelligence in Autonomous Driving. https://www.enisa.europa.eu/publications/enisa-jrc-cybersecurity-challenges-in-the-uptake-of-artificial-intelligence-in-autonomous-driving (Accessed: 12 January 2026)

ENISA. 2023. Artificial Intelligence and Cybersecurity Research. https://www.enisa.europa.eu/publications/artificial-intelligence-and-cybersecurity-research (Accessed: 12 January 2026)

ENISA. 2024. Cyber Insurance – Models and Methods and the Use of AI. https://www.enisa.europa.eu/publications/cyber-insurance-models-and-methods-and-the-use-of-ai (Accessed: 12 January 2026)

ENISA. 2025. From Cyber to Outer Space: A Guide to Securing Commercial Satellite Operations. https://www.enisa.europa.eu/news/from-cyber-to-outer-space-a-guide-to-securing-commercial-satellite-operations (Accessed: 12 January 2026)

ENISA. 2020. Guidelines for Securing the Internet of Things. https://www.enisa.europa.eu/publications/guidelines-for-securing-the-internet-of-things (Accessed: 12 January 2026)

EU JRC

EU JRC. 2025. An Open-Source IT Tool for Energy Forecast of Renewable Energy Communities. https://publications.jrc.ec.europa.eu/repository/handle/JRC139475 (Accessed: 12 January 2026)

EU JRC; De Paola, A. et al. 2024. Three Challenges to Secure AI Systems in the Context of AI Regulations. https://publications.jrc.ec.europa.eu/repository/handle/JRC136529 (Accessed: 12 January 2026)

EU JRC. 2021. AI Watch: Beyond Pilots: Sustainable Implementation of AI in Public Services. https://publications.jrc.ec.europa.eu/repository/handle/JRC126665 (Accessed: 12 January 2026)

EU JRC. 2025. The Role of AI Safety Benchmarks in Evaluating Systemic Risks in General-Purpose AI Models. https://publications.jrc.ec.europa.eu/repository/handle/JRC143259 (Accessed: 12 January 2026)

EU JRC. 2022. AI Watch: AI Uptake in Manufacturing. https://publications.jrc.ec.europa.eu/repository/handle/JRC129295 (Accessed: 12 January 2026)

EU JRC. 2022. AI Watch: National Strategies on Artificial Intelligence: A European Perspective (2022 Edition). https://publications.jrc.ec.europa.eu/repository/handle/JRC129123 (Accessed: 12 January 2026)

EU JRC et al. 2022. Cyber Resilience Act Requirements Standards Mapping. https://publications.jrc.ec.europa.eu/repository/handle/JRC137340 (Accessed: 12 January 2026)

EU JRC. 2023. Monitoring Resilience in the EU. https://publications.jrc.ec.europa.eu/repository/handle/JRC135043 (Accessed: 12 January 2026)

EU JRC. 2022. Artificial Intelligence in Automated Driving: An Analysis of Safety and Cybersecurity Challenges. https://publications.jrc.ec.europa.eu/repository/handle/JRC127189 (Accessed: 12 January 2026)

EU JRC. 2023. Research and Innovation in Transport Safety and Resilience in Europe. https://publications.jrc.ec.europa.eu/repository/handle/JRC134936 (Accessed: 12 January 2026)

EU JRC. 2024. The Global Supply Chain of Chips in the European Supply Chain. https://publications.jrc.ec.europa.eu/repository/handle/JRC139558 (Accessed: 12 January 2026)

EU JRC. 2022. API Strategy Essentials for Public Sector Innovation: Technical Perspective. https://publications.jrc.ec.europa.eu/repository/handle/JRC129951 (Accessed: 12 January 2026)

EU JRC. 2023. Email Communication Security Standards: An Analysis of Uptake in the EU. https://publications.jrc.ec.europa.eu/repository/handle/JRC130656 (Accessed: 12 January 2026)

NIST

NIST. 2024. Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines. https://www.nist.gov/publications/strategies-integration-software-supply-chain-security-devsecops-cicd-pipelines (Accessed: 12 January 2026)

NIST. 2022. Cybersecurity Supply Chain Risk Management for Systems and Organizations. https://www.nist.gov/publications/cybersecurity-supply-chain-risk-management-systems-and-organizations (Accessed: 12 January 2026)

NIST. 2024. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. https://www.nist.gov/publications/cybersecurity-supply-chain-risk-management-practices-systems-and-organizations (Accessed: 12 January 2026)

NIST. 2020. Impact Analysis Tool for Interdependent Cyber Supply Chain Risks. https://www.nist.gov/publications/impact-analysis-tool-interdependent-cyber-supply-chain-risks (Accessed: 12 January 2026)

NIST. 2020. Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF). https://www.nist.gov/publications/mitigating-risk-software-vulnerabilities-adopting-secure-software-development-framework (Accessed: 12 January 2026)

NIST. 2022. Secure Software Development Framework (SSDF) Version 1.1. https://www.nist.gov/publications/secure-software-development-framework-ssdf-version-11-recommendations-mitigating-risk (Accessed: 12 January 2026)

NIST. 2024. NIST Cybersecurity Framework 2.0: Quick-Start Guide for Cybersecurity Supply Chain Risk Management. https://www.nist.gov/publications/nist-cybersecurity-framework-20-quick-start-guide-cybersecurity-supply-chain-risk (Accessed: 12 January 2026)

NIST. 2021. A Decade of Reoccurring Software Weaknesses. https://www.nist.gov/publications/decade-reoccurring-software-weaknesses (Accessed: 12 January 2026)

NIST. 2020. Measurements of the Most Significant Software Security Weaknesses. https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=930459 (Accessed: 12 January 2026)

NIST. 2024. Secure Software Development Practices for Generative AI and Dual-Use Foundation Models. https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf (Accessed: 12 January 2026)

NIST. 2020. Automation Support for Security Control Assessments: Software Vulnerability Management. https://www.nist.gov/publications/automation-support-security-control-assessments-software-vulnerability-management (Accessed: 12 January 2026)

NIST. 2022. Improving Enterprise Patching for General IT Systems. https://www.nist.gov/publications/improving-enterprise-patching-general-it-systems-utilizing-existing-tools-and (Accessed: 12 January 2026)

NIST. 2023. Recommendations for Federal Vulnerability Disclosure Guidelines. https://www.nist.gov/publications/recommendations-federal-vulnerability-disclosure-guidelines (Accessed: 12 January 2026)

NIST. 2024. Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities. https://www.nist.gov/publications/bugs-framework-bf-formalizing-cybersecurity-weaknesses-and-vulnerabilities (Accessed: 12 January 2026)

CIS

CIS. 2025. Secure by Design: A Guide to Assessing Software Security Practices. https://www.cisecurity.org/insights/white-papers/secure-by-design (Accessed: 12 January 2026)

CIS. 2022. CIS Software Supply Chain Security Guide. https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide (Accessed: 12 January 2026)

CIS. 2022. Simplifying Security. https://www.cisecurity.org/insights/white-papers/simplifying-security (Accessed: 12 January 2026)

CIS. 2023. Enhancing Safety in the Connected World – A National Framework for Action. https://www.cisecurity.org/insights/white-papers/enhancing-safety-in-the-connected-world-a-national-framework-for-action (Accessed: 12 January 2026)

CIS. 2023. Embedded Security Guidance. https://www.cisecurity.org/insights/white-papers/internet-of-things-embedded-security-guidance (Accessed: 12 January 2026)

CIS. 2020. Cloud Security and the Shared Responsibility Model. https://www.cisecurity.org/insights/white-papers/cloud-security-and-the-shared-responsibility-model (Accessed: 12 January 2026)

CIS. 2024. Establishing Essential Cyber Hygiene Version 8.1. https://www.cisecurity.org/insights/white-papers/establishing-essential-cyber-hygiene-version-8-1 (Accessed: 12 January 2026)

CIS. 2021. CIS Controls Mapping to Cloud Security Alliance Cloud Control Matrix. https://www.cisecurity.org/insights/white-papers/cis-controls-mapping-to-cloud-security-association-cloud-control-matrix (Accessed: 12 January 2026)

CIS. 2022. CIS RAM (Risk Assessment Method). https://www.cisecurity.org/insights/white-papers/cis-ram-risk-assessment-method (Accessed: 12 January 2026)

CIS. 2021. Microsoft Cloud Security Benchmark. https://www.cisecurity.org/insights/white-papers/microsoft-cloud-security-benchmark (Accessed: 12 January 2026)

OECD

OECD. 2024. New Perspectives on Measuring Cybersecurity. https://www.oecd.org/en/publications/new-perspectives-on-measuring-cybersecurity_b1e31997-en.html (Accessed: 12 January 2026)

OECD. 2023. Enhancing the Security of Communication Infrastructure. https://www.oecd.org/en/publications/enhancing-the-security-of-communication-infrastructure_bb608fe5-en.html (Accessed: 12 January 2026)

OECD. 2023. Regulatory Sandboxes in Artificial Intelligence. https://www.oecd.org/en/publications/regulatory-sandboxes-in-artificial-intelligence_8f80a0e6-en.html (Accessed: 12 January 2026)

OECD. 2023. Advancing Accountability in AI. https://www.oecd.org/en/publications/advancing-accountability-in-ai_2448f04b-en.html (Accessed: 12 January 2026)

OECD. 2022. OECD Framework for the Classification of AI Systems. https://www.oecd.org/en/publications/oecd-framework-for-the-classification-of-ai-systems_cb6d9eca-en.html (Accessed: 12 January 2026)

OECD. 2021. Tools for Trustworthy AI. https://www.oecd.org/en/publications/tools-for-trustworthy-ai_008232ec-en.html (Accessed: 12 January 2026)

OECD. 2022. Security of the Domain Name System (DNS). https://www.oecd.org/en/publications/security-of-the-domain-name-system-dns_285d7875-en.html (Accessed: 12 January 2026)

OECD. 2021. Encouraging Vulnerability Treatment. https://www.oecd.org/en/publications/encouraging-vulnerability-treatment_0e2615ba-en.html (Accessed: 12 January 2026)

OpenSSF

OpenSSF (2025) Improving risk management decisions with SBOM data. Open-Source Security Foundation. Available at: https://openssf.org/resources/improving-risk-management-decisions-with-sbom-data/ (Accessed: 12 January 2026).

OpenSSF (2025) Secure Open-Source Software Vision Brief 2025. Open-Source Security Foundation. Available at: https://openssf.org/resources/publications/secure-open-source-software-vision-brief-2025/ (Accessed: 12 January 2026).

OpenSSF (2023) Cybersecurity in energy infrastructure: The value of Open-Source software. Open-Source Security Foundation. Available at: https://openssf.org/resources/whitepaper-cybersecurity-in-energy-infrastructure/ (Accessed: 12 January 2026).

OpenSSF (2023) Secure Open-Source Software Vision Brief 2023. Open-Source Security Foundation. Available at: https://openssf.org/soss-vision-brief/ (Accessed: 12 January 2026).

Dana, J., Hoffman, J., Randazzo, S. and Zhou, Y. (2022) Census II of free and Open-Source software — Application libraries. Open-Source Security Foundation. Available at: https://openssf.org/resources/census-ii-of-free-and-open-source-software-application-libraries/ (Accessed: 12 January 2026).

Linux Foundation

Gerosa, M., Hermansen, A., Lai, A., Lawson, A. and Collier, M. (Foreword) (2025) The State of Sovereign AI. Linux Foundation. Available at: https://www.linuxfoundation.org/research/state-of-sovereign-ai (Accessed: 12 January 2026).

Hermansen, A. and Sandberg, K. D. (2025) The Value of Open-Source AI for APEC Economies. Linux Foundation. Available at: https://www.linuxfoundation.org/research/open-source-ai-apec (Accessed: 12 January 2026).

Linux Foundation Research Team (2022) Addressing Cybersecurity Challenges in Open-Source Software. Linux Foundation. Available at: https://www.linuxfoundation.org/research/addressing-cybersecurity-challenges-in-open-source-software (Accessed: 12 January 2026).

Nagle, F., Dana, J., Hoffman, J., Randazzo, S. and Zhou, Y. (2022) Census II of Free and Open-Source Software — Application Libraries. Linux Foundation. Available at: https://www.linuxfoundation.org/research/census-ii-of-free-and-open-source-software-application-libraries (Accessed: 12 January 2026).

Bennet, K., Rajbahadur, G. K., Suriyawongkul, A. and Stewart, K. (2024) Implementing AI Bill of Materials (AI BOM) with SPDX 3.0. Linux Foundation. Available at: https://www.linuxfoundation.org/research/ai-bom (Accessed: 12 January 2026).

Linux Foundation Research Team (2020) Open-Source Software Supply Chain Security. Linux Foundation. Available at: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security (Accessed: 12 January 2026).

Hendrick, S. (2022) The State of Software Bill of Materials (SBOM) and Cybersecurity Readiness. Linux Foundation. Available at: https://www.linuxfoundation.org/research/the-state-of-software-bill-of-materials-sbom-and-cybersecurity-readiness (Accessed: 12 January 2026).

TechUK

TechUK (2023) Open and secure: Charting a path for UK tech in a world of resurgent strategic competition. TechUK. Available at: https://www.techuk.org/resource/open-and-secure-charting-a-path-for-uk-tech-in-a-world-of-resurgent-strategic-competition.html (Accessed: 12 January 2026).

TechUK (2025) techUK & CII Report – Securing the future: Deepening UK–India technology security cooperation. TechUK. Available at: https://www.techuk.org/resource/techuk-cii-report-securing-the-future-deepening-uk-india-technology-security-cooperation.html (Accessed: 12 January 2026).

TechUK (2025) techUK Report – Enabling growth and resilience: The UK tech sector in an uncertain world. TechUK. Available at: https://www.techuk.org/resource/techuk-report-enabling-growth-and-resilience-the-uk-tech-sector-in-an-uncertain-world.html (Accessed: 12 January 2026).

TechUK (2024) DefTech: Technology transforming defence – techUK report. TechUK. Available at: https://www.techuk.org/resource/deftech-technology-transforming-defence-techuk-report-published.html (Accessed: 12 January 2026).

TechUK (2022) techUK launches new report on supply chain risks. TechUK. Available at: https://www.techuk.org/resource/risks-in-tech-supply-chains.html (Accessed: 12 January 2026).

TechUK (2022) techUK position paper – Governance for an AI future. TechUK. Available at: https://www.techuk.org/resource/techuk-position-paper-governance-for-an-ai-future.html (Accessed: 12 January 2026).

TechUK (2023) Open and secure: Charting a path for UK tech in a world of resurgent strategic competition. TechUK. Available at: https://www.techuk.org/resource/open-and-secure-charting-a-path-for-uk-tech-in-a-world-of-resurgent-strategic-competition.html (Accessed: 12 January 2026).
(This appears to be a duplicate record with a different keyword.)

TechUK (2024) State of Open: The UK in 2024, Phase Three – “Open-Source and Market Shaping”. TechUK/OpenUK. Available at: https://openuk.uk/stateofopen/stateofopentheukin2024-phase3/ (Accessed: 12 January 2026).

OpenUK

Lwin, Z. (2025) The UK’s future leadership in Open-Source. OpenUK. Available at: https://openuk.uk/theuksfutureleadershipinopensource/ (Accessed: 12 January 2026).

Lwin, Z. (2025) The shifting power dynamics in Open-Source: Rug pulls, relicensing and forks. OpenUK. Available at: https://openuk.uk/blog-shiftingpowerdynamicsopensource/ (Accessed: 12 January 2026).

Brock, A. (2022) Does Open-Source software need regulation? OpenUK. Available at: https://openuk.uk/does-open-source-software-need-regulation/ (Accessed: 12 January 2026).

Brock, A., Brooks, B. and Tisne, M. (2025) AI openness update report: “From agentic to public good in 2025”. OpenUK. Available at: https://openuk.uk/stateofopen/publicgoodai/ (Accessed: 12 January 2026).

Hartnett, M., Brock, A., Richards, T. B., Mostaque, E., Lawrence, N. and Barth, J. (2024) State of Open: The UK in 2024, Phase One – AI and open innovation. OpenUK. Available at: https://openuk.uk/stateofopen/state-of-open-the-uk-in-2024-phase-1/ (Accessed: 12 January 2026).

Brock, A., Bracken, M., Mitchell, I. KC, Driesen, L., Allaire, J.J., Dunscombe, R., Fitzgerald, N. and Barth, J. (2024) State of Open: The UK in 2024, Phase Three – “Open-Source and Market Shaping”. OpenUK. Available at: https://openuk.uk/stateofopen/stateofopentheukin2024-phase3/ (Accessed: 12 January 2026).

Brock, A., Richards, T. B., Barker, M., Brooks, B., Richards, T. B., Nesterova, E. and Barth, J. (2025) State of Open: The UK in 2024, Phase Four – “AI Openness: End of Year Update 2024”. OpenUK. Available at: https://openuk.uk/stateofopen/2024phase4aiopennessupdate/ (Accessed: 12 January 2026).
(Note: “Toran Bruce Richards” appeared twice in the original data; retained once in citation.)

Brock, A., Hutton, W., Bracken, M., Hanson‑Granville, R., Tickell, S., Don, S., King, A., Tiwari, U., Hartnett, M., Liesenfeld, A., Rindi, C., Giannuzzi, J. and Barth, J. (2024) State of Open: The UK in 2024, Phase Two – “The Open Manifesto”. OpenUK. Available at: https://openuk.uk/stateofopen/state-of-open-the-uk-in-2024-phase-2-the-open-manifesto/ (Accessed: 12 January 2026).

CNCF

CNCF (2023) Kubernetes: Project Journey Report. Cloud Native Computing Foundation. Available at: https://www.cncf.io/reports/kubernetes-project-journey-report/ (Accessed: 12 January 2026).

CNCF (2023) OpenTelemetry: Project Journey Report. Cloud Native Computing Foundation. Available at: https://www.cncf.io/reports/opentelemetry-project-journey-report/ (Accessed: 12 January 2026).

Moch, D., Crum, W., Dvoretskyi, I., Dunbar‑Hall, I., Kunduru, H. and Bentley, S. (2025) Public sector software supply chain. Cloud Native Computing Foundation. Available at: https://www.cncf.io/reports/public-sector-software-supply-chain-whitepaper/ (Accessed: 12 January 2026).

CNCF (2022) Kubernetes Annual Report 2021. Cloud Native Computing Foundation. Available at: https://www.cncf.io/reports/kubernetes-annual-report-2021/ (Accessed: 12 January 2026).

Zaalouk, A., Jones, A., Velichkevich, A., Kurktchiev, B., Chin, C., Zhang, C., Misale, C., Chen, H., Roberts, J., Chen, K‑H., Bhandaru, M., Yao, M., Raghunath, N., Pan, P., Kakodkar, R., Pandey, R., Aravena, R., Petty, R., Taylor, R., Sheikh, S., Wilson, S., Thorley, T. and Lu, V. (2024) Cloud Native Artificial Intelligence Whitepaper. Cloud Native Computing Foundation. Available at: https://www.cncf.io/reports/cloud-native-artificial-intelligence-whitepaper/ (Accessed: 12 January 2026).

Rand Corporation

Tebyanian, N., Fischbach, J. R., Lempert, R. J., Knopman, D., Wu, H., Iulo, L. and Keller, K. (2023) Rhodium‑SWMM: An open‑source tool for green infrastructure placement under deep uncertainty. RAND Corporation. Available at: https://www.rand.org/pubs/external_publications/EP70210.html (Accessed: 12 January 2026).

Sargent, M., Marrone, J. V., Evans, A. T., Lilly, B., Nemeth, E. and Dalzell, S. (2020) Tracking and disrupting the illicit antiquities trade with Open-Source data. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RR2706.html (Accessed: 12 January 2026).

Schmid, J. (2021) An open‑source method for assessing national scientific and technological standing. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA1482-3.html (Accessed: 12 January 2026).

Stebbins, D., Girven, R. S., Parker, T., Deen, T., De Bruhl, B. F., Ryseff, J., Paige, J. W., Kleiman, A. Y., Bhatt, S. D., Sousa, É. M., et al. (2024) Exploring artificial intelligence use to mitigate potential human bias within U.S. Army intelligence preparation of the battlefield processes. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA2763-1.html (Accessed: 12 January 2026).

Romanosky, S., Dixon, L., Briggs, R. J. and Willis, H. H. (2025) Insuring catastrophic cyber risk. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA3817-1.html (Accessed: 12 January 2026).

Snyder, D. and Heitzenrater, C. (2024) Enhancing cybersecurity and cyber resiliency of weapon systems. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA1506-2.html (Accessed: 12 January 2026).

Greenfield, V. A., Welburn, J. W., Schwindt, K., Ish, D., Lohn, A. J. and Hartnett, G. S. (2023) Cybersecurity and supply chain risk management are not simply additive. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA532-1.html (Accessed: 12 January 2026).

van Soest, H., Arciniegas Rueda, I., Park, H. M., Spurling, B., Wyatt, A., Fine, H., Steier, J. and Lebret, M. (2024) The use of AI for improving energy security. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA2907-1.html (Accessed: 12 January 2026).

Arciniegas Rueda, I., van Soest, H. and Park, H. M. (2024) The use of AI for improving energy security. RAND Corporation. Available at: https://www.rand.org/pubs/external_publications/EP70756.html (Accessed: 12 January 2026).
(Note: this is a distinct publication with the same title but different URL and author subset.)

Smith, G., Stanley, K. D., Marcinek, K., Cormarie, P. and Gunashekar, S. (2024) General‑purpose artificial intelligence (GPAI) models and GPAI models with systemic risk: Classification and requirements for providers. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA3243-1.html (Accessed: 12 January 2026).

Gerstein, D. M. and Leidy, E. N. (2024) Emerging technology and risk analysis: Artificial intelligence and critical infrastructure. RAND Corporation. Available at: https://www.rand.org/pubs/research_reports/RRA2873-1.html (Accessed: 12 January 2026).

Brookings Institution

Meltzer, J. P. (2024) Developing global AI governance for foundational AI. Brookings Institution / Hinrich Foundation. Available at: https://www.hinrichfoundation.com/research/article/tech/developing-global-ai-governance-for-foundational-ai (Accessed: 12 January 2026).

Engler, A. (2023) The EU and U.S. diverge on AI regulation: A transatlantic comparison and steps to alignment. Brookings Institution. Available at: https://www.brookings.edu/articles/the-eu-and-us-diverge-on-ai-regulation-a-transatlantic-comparison-and-steps-to-alignment/ (Accessed: 12 January 2026).

Engler, A. (2022) The EU AI Act will have global impact, but a limited Brussels Effect. Brookings Institution. Available at: https://www.brookings.edu/articles/the-eu-ai-act-will-have-global-impact-but-a-limited-brussels-effect/ (Accessed: 12 January 2026).

Engler, A. (2023) How open‑source software shapes AI policy. Brookings Institution. Available at: https://www.brookings.edu/articles/how-open-source-software-shapes-ai-policy (Accessed: 12 January 2026).

Nagle, F. (2022) Strengthening digital infrastructure: A policy agenda for free and Open-Source software. Brookings Institution. Available at: https://www.brookings.edu/articles/strengthening-digital-infrastructure-a-policy-agenda-for-free-and-open-source-software/ (Accessed: 12 January 2026).

SonaType

SonaType (2021) The 2021 State of the Software Supply Chain Report. SonaType. Available at: https://www.sonatype.com/resources/whitepapers/2021-state-of-the-software-supply-chain-report-2021 (Accessed: 12 January 2026).

SonaType (2020) The 2020 State of the Software Supply Chain. SonaType. Available at: https://www.sonatype.com/hubfs/SSC/SON_SSSC-Report-2020_sept23.pdf (Accessed: 12 January 2026).
(Publication date recorded as 23 September 2020.)

SonaType (2022) The 2022 State of the Software Supply Chain. SonaType. Available at: https://www.sonatype.com/hubfs/1-2023%20New%20Site%20Assets/SSCR/8th-Annual-SSCR-digital-0206%20update.pdf (Accessed: 12 January 2026).

SonaType (2023) The 2023 State of the Software Supply Chain. SonaType. Available at: https://www.sonatype.com/hubfs/SSC/2023%20Sonatype-%209th%20Annual%20State%20of%20the%20Software%20Supply%20Chain-%20Update.pdf (Accessed: 12 January 2026).

Google Cloud

Mandiant (2024) The Defender’s Advantage: Using Artificial Intelligence in Cyber Defense. Google Cloud. Available at: https://cloud.google.com/security/resources/defenders-advantage-artificial-intelligence (Accessed: 12 January 2026).

Kutscher, J. (2025) M‑Trends 2025: Data, insights, and recommendations from the frontlines. Google Cloud. Available at: https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025 (Accessed: 12 January 2026).

Google Cloud (2023) Threat Horizons August 2023: Threat Horizons Report. Google Cloud. Available at: https://services.google.com/fh/files/blogs/gcat_threathorizons_full_jul2023.pdf (Accessed: 12 January 2026).

Deloitte (2023) Entering the era of generative AI‑enabled security. Google Cloud. Available at: https://cloud.google.com/security/resources/entering-era-gen-ai-enbl-security (Accessed: 12 January 2026).

Contact details of the authors

Dr. Srinidhi Vasudevan
Srinidhi.vasudevan@greenwich.ac.uk

Dr. Anna Piazza
Anna.piazza@greenwich.ac.uk

Mr. Guru Krishna Ramakrishnan
g.ramakrishnan@greenwich.ac.uk

Dr. Guido Conaldi
g.conaldi@greenwich.ac.uk

1. A critical vulnerability in a ubiquitous open source logging component that enabled unauthenticated remote code execution across thousands of downstream systems. Read CNA: Apache Software Foundation. ↩

2. A sophisticated supply chain compromise in a core open source Linux utility, involving intentional malicious code introduced by a trusted maintainer. Read CNA: Red Hat, Inc.. ↩

3. PRISMA is a reporting guideline for systematic reviews; the 2020 update replaces the 2009 version and reflects advances in how studies are identified, assessed, and synthesised. Read The PRISMA 2020 statement: an updated guideline for reporting systematic reviews, The BMJ. ↩

4. A Software Bill of Materials (SBOM) is a formal, structured list of all components, libraries, and dependencies used in a piece of software. It functions like an ingredients list, making it possible to identify and address known vulnerabilities in any component. ↩

5. AIBOM / SPDX 3.0: Linux Foundation. (2024). Implementing AI Bill of Materials (AI BOM) with SPDX 3.0. ↩

6. DSIT. G7 Cyber Expert Group Statement on Artificial Intelligence and Cybersecurity: September 2025. ↩

7. Due to Machinery of Government changes, DSIT no longer exists however all previous research and guidance published under its name will remain cited as DSIT. ↩

8. DSIT. Open source software best practices and supply chain risk management. ↩

9. Open Source Initiative ↩

10. Creative Commons licences ↩

11. Community Data License Agreement (CDLA) ↩

12. Meta for Llama licence ↩

13. The Open Source AI Definition 1.0 - Open Source Initiative ↩

14. White et al. (2024) ↩

15. Liesenfeld & Dingemanse (2024) ↩

16. Bommasani et al. (2023) ↩

17. The GNU Lesser General Public Licence (LGPL) is a type of “copyleft” software licence requiring that modifications to the licensed library remain open, whilst allowing the library to be used within proprietary software. ↩

18. The MIT licence is one of the most permissive open-source licences, requiring only that the original copyright notice is retained. ↩

19. A clean-room implementation recreates a system without copying the original, requiring that the team building the new version has no direct access to the original code. ↩

20. npm (Node Package Manager) is the primary package registry for JavaScript software. It hosts hundreds of thousands of open-source packages that developers can incorporate into their own projects. It is one of the largest and most widely used open-source software ecosystems in the world. ↩

21. NIST Special Publication 800‑161 Revision 1 (usually written SP 800‑161r1) is the U.S. government’s primary framework for managing cybersecurity risks arising from software and hardware supply chains. ↩

22. Oxford-led study finds filtering data helps secure open-source AI against misuse: Globe Banner ↩

23. Read Project Glasswing: Securing critical software for the AI era - Anthropic and Claude Mythos Preview - Anthropic for further information. ↩

24. AutoML (Automated Machine Learning) refers to tools and frameworks that automate the process of selecting, training, and optimising AI models, reducing the need for manual expert configuration. In cybersecurity contexts, AutoML frameworks are used to build intrusion detection systems, anomaly detectors, and threat classification tools. ↩

25. Frontier AI Trends Report: AISI ↩

26. Linux Foundation. (2024). Implementing AI Bill of Materials (AI BOM) with SPDX 3.0 ↩

27. CISA. (2023). CISA Open Source Software Security Roadmap. ↩

28. DSIT. Code of Practice for the Cyber Security of AI (January 2025). ↩

29. ISO/IEC JTC 1/SC 42 is the international subcommittee responsible for AI standardisation, covering trustworthiness, governance, risk management, and security across the AI lifecycle. Its published and in-development standards include ISO/IEC 42001 (AI management systems) and ISO/IEC 5338 (AI lifecycle processes). ↩

30. NCSC. New ETSI standard protects AI systems from evolving cyber threats (May 2025). ↩

31. DSIT. G7 Cyber Expert Group Statement on Artificial Intelligence and Cybersecurity: September 2025. ↩

32. Linux Foundation. (2025). The Value of Open Source AI for APEC Economies. ↩

33. Linux Foundation. (2025). The State of Sovereign AI. ↩

34. European Open-Source AI Index ↩

35. Stanford Foundation Model Transparency Index ↩