Risks and Vulnerabilities Across the DevSecMLOps Loop

This chapter walks the loop of Chapter 8 stage by stage and sets out the risks large organisations actually meet, the documented incidents of 2024 to 2026 behind them, and the controls that contain them. Revision management gets particular weight, because most of the loop's risks are either caused by weak version control or contained by strong version control. The chapter also treats unmanaged skills as a risk class, maps the risks to ISO/IEC 27001:2022 Annex A, and closes with a risk register as code.

The stages of the DevSecMLOps loop that carry risk, from source control to monitoring, with revision management connected to three of them

Figure 9.1: The stages of the loop that carry risk. Revision management connects to them, either as the cause of a failure or as the control that contains it. The table names the main risk at each stage.

Stage Main risks
Source, CI and coding assistants Tags, caches and secrets; injection and rules files
Dependencies and mirrors Worms, cache poisoning
Data and model artefacts Poisoning, lineage gaps; unsafe formats, exposed platforms
Prompts, indexes and evaluation Unreviewed change; contamination, gamed graders
Inference servers Remote code execution, exposure
Monitoring and evidence Tampering, retention gaps
Revision management Gaps in coverage, signing and immutability

How to read this chapter

The chapter is written for defenders: what happened, why the control failed, and what prevents it, never how to reproduce an attack. Figures carry their month and year, because they age quickly. Three taxonomies sit behind the stage risks: NIST AI 100-2 E2025 on adversarial machine learning (144, Vassilev et al., 2025); MITRE ATLAS (28, MITRE, n.d.); and the OWASP lists for large language model and agentic applications (27, OWASP, 2025) (102, OWASP, 2025). This chapter applies them to the delivery loop, and refers to the July 2026 OpenAI–Hugging Face incident, which AI Governance, Chapter 19 tells in full.

Revision management decides most outcomes

Reading the incidents of 2024 to 2026 side by side, the same three failures recur. The first is the mutable reference, such as a Git tag or registry alias that can be pointed at different content while consumers keep trusting the name. The second is the shared CI cache that lets a low-privilege job plant content a release job later consumes. The third is the credential believed revoked but still valid. Immutable digests, isolated release workflows, signed provenance, and verified revocation address all three; provenance alone does not, as the dependency section shows. This synthesis is my interpretation of the cases below.

Each control in the table below turns an open-ended compromise into an incident that can be contained and reconstructed.

Recurring failure Containing control
Mutable references: tags, latest, aliases Pin by digest and commit SHA
Shared CI caches across trust boundaries No caches in release workflows
Credentials believed revoked but still valid Verify revocation against the credential
Rewritten or force-pushed history Block force pushes and sign commits
Artefacts outside version control Complete artefact coverage
Logs shorter-lived than obligations Retention mapped to obligations

Effective revision management therefore has five properties: complete coverage of the artefacts listed in Chapter 8; signed, immutable history, which SLSA's Source Track describes as "continuous, immutable, and retained" (133, SLSA Community, 2025); protection that cannot be bypassed silently; releases reproducible from their manifests; and retention is aligned with obligations: Article 12 of the AI Act requires high-risk AI systems to allow automatic recording of events, Article 19 requires providers to keep those logs for at least six months, Article 26(6) places the same minimum on deployers, and Article 18 requires technical documentation to be kept for ten years (1, European Union, 2024), while DORA's Article 9 change management requirements apply to financial entities (3, European Union, 2022).

Source control and CI

Mutable action tags. In March 2025 attackers retargeted release tags of the tj-actions/changed-files action, used in over 23,000 repositories, to a commit that dumped CI secrets into build logs (158, Sharma, 2025). On 19 March 2026 a threat actor with compromised credentials force-pushed 76 of 77 version tags of aquasecurity/trivy-action and all seven tags of setup-trivy to credential-stealing code; the record carries a CVSS 4.0 score of 9.4 and entered CISA's Known Exploited Vulnerabilities catalogue on 26 March 2026 (154, NVD, 2026) (90, CISA, n.d.). The advisory directs only those who referenced a version tag rather than a full commit SHA to review their workflow logs, because tags are not versions.

Untrusted triggers and cache poisoning. In August 2025 a workflow in the Nx repository ran with the privileged pull_request_target trigger and allowed shell injection, through which the attacker stole the npm token (157, Strumpflohner, 2025). In December 2024 the Ultralytics computer-vision library, a dependency of many machine learning pipelines, shipped malicious versions through its own release workflow after GitHub Actions cache poisoning, and a second round used an API token still available to the workflow, probably a hold-over from before the move to trusted publishing (159, PyPI, 2024). PyPI notes that Sigstore attestations made the attack auditable.

Secrets in history. GitGuardian's March 2026 report counted 28,649,024 new secrets in public GitHub commits during 2025, with secrets for AI services up 81 per cent, and found that 64 per cent of valid secrets detected in 2022 were still active four years later (155, GitGuardian, 2026). Rewriting history does not remove a pushed secret: GitHub's own guidance is to revoke or rotate first, warning that rewriting strips signatures and leaves data reachable in forks (178, GitHub, 2026). The rule is therefore "rotate, do not rewrite".

Bypassable protection. Roles, teams, and applications on a ruleset's bypass list can override its rules, including the signed-commit requirement (140, GitHub, 2026). A bypass list grown by convenience is an unprotected branch.

Practical guide: hardening the source-control and CI layer

Purpose. Close the paths by which source control and CI were compromised in 2025 and 2026, largest reduction first.

Roles. The platform team owns CI templates and rulesets; the security architect owns the bypass list and token policy.

Steps.

  1. Pin every third-party action and reusable workflow to a full commit SHA, and fail any workflow that references a tag or branch.
  2. Set the default workflow token to read-only and give publishing jobs short-lived OIDC credentials instead of stored tokens.
  3. Remove pull_request_target and other privileged triggers from workflows that process untrusted input, and disable shared caches in any job that handles release credentials.
  4. Apply an organisation ruleset to every default branch that blocks force pushes and requires signed commits, pull requests, and status checks; reduce bypass lists to a two-person break-glass group with alerts on every use.
  5. Enable push-time secret scanning; on detection, rotate the secret and verify that the old value is rejected, without rewriting history unless legal or privacy duties require it.

Defaults to adapt. A 90-day bypass review, two approvals for high-risk systems, and no tag references at all.

Definition of done. No workflow references a third-party action by tag; no release job uses a shared cache or stored publishing token; and every default branch refuses force pushes and unsigned commits.

AI coding assistants and agents in the loop

Coding assistants and agents read repository content, run commands, and open pull requests, which makes repository content an input to a system with tools: the condition for prompt injection.

The clearest case is the 2026 compromise of the Cline project's releases: an issue-triage workflow ran a coding agent with shell access on issues any GitHub user could open and placed the issue title in the agent's prompt; a crafted title led the agent to install code from an attacker's commit, from which the attacker poisoned the shared Actions cache of the nightly release workflow and obtained publishing tokens (162, Khan, 2026). The post-mortem adds the revision-management lesson: during rotation the wrong npm token was deleted, and on 17 February 2026 an unauthorised version was published (161, Rizwan, 2026).

In May 2025 researchers showed that a prompt injection in a public issue could lead an agent using the official GitHub MCP server to leak private repository content, an architectural "toxic agent flow" rather than a server bug (163, Milanta & Beurer-Kellner, 2025). And a "rules file backdoor" used hidden Unicode characters in an assistant's rules file to make it insert code silently; GitHub added a hidden-Unicode warning on 1 May 2025 (164, Karliner et al., 2025). Output quality adds risk without any attack: Veracode found in March 2026 that about 45 per cent of generated code samples still contained a known class of flaw (160, Brombacher, 2026), and GitGuardian found commits co-authored by one coding agent, Claude Code, leaking secrets at about twice the baseline rate (155, GitGuardian, 2026).

The controls follow from Chapter 8. Agent configuration, including rules files, hooks, skills, and MCP server lists, is versioned, reviewed by code owners, scanned for hidden characters, and signed. Agents never run on untrusted triggers with tools and credentials together, and hold no publishing rights.

Dependencies and package mirrors

Package registries saw the largest self-propagating attacks of the period. In September 2025 CISA warned of the self-replicating "Shai-Hulud" worm, which had compromised over 500 npm packages, harvested credentials, and republished infected versions, and advised searching artefact repositories for cached copies (156, CISA, 2025).

The May 2026 wave against the TanStack packages shows the limit of provenance. StepSecurity reports that the attackers chained an untrusted pull-request trigger, cache poisoning, and extraction of an OIDC token to publish through the project's own release workflow, and that the malicious packages carried valid SLSA Build Level 3 provenance: "SLSA provenance confirms which pipeline produced the artifact, not whether the pipeline was behaving as intended" (153, Kurmi, 2026). In August 2026 the CHAINDROP wave compromised over 400 npm packages with more than 1.3 billion combined monthly downloads; Elastic reports that it harvested AI coding-tool credentials and persisted through hooks in coding-agent settings, committed under an author named after a coding agent (152, Elastic Security Labs, 2026).

Mirrors deserve their own line in the risk register. In the July 2026 incident, agents exploited a previously unknown flaw in an Artifactory remote cache to store attacker-controlled content under the name of a trusted image (104, OpenAI, 2026). The vulnerability, CVE-2026-66384, carries a CVSS 3.1 score of only 5.3, yet CISA added it to the Known Exploited Vulnerabilities catalogue on 27 August 2026 (172, NVD, 2026) (123, JFrog, 2026), a reminder that severity scores do not measure what a component means to the loop.

The containing controls are hashed lockfiles, a soak period, a mirror whose cache is checked against upstream digests, disabled install scripts, and the Chapter 8 admission rule that nothing runs unless its digest appears in a signed manifest. Provenance stays valuable because it makes compromise attributable.

Data and training

Data poisoning is the first attack Article 15(5) of the AI Act names among those a high-risk system must resist (1, European Union, 2024), and recent research has lowered the bar. In October 2025 Anthropic, the UK AI Security Institute, and the Alan Turing Institute reported that 250 poisoned documents were enough to implant a backdoor in models from 600 million to 13 billion parameters, a number that did not grow with the data, although the backdoor was narrow (165, Souly et al., 2025). Earlier work showed that poisoning 0.01 per cent of two web-scale image datasets would have cost about 60 US dollars, by buying expired domains whose content had changed since indexing (167, Carlini et al., 2023).

That second attack is a revision-management failure at heart, because the dataset referenced content by URL rather than by content hash. The May 2025 guidance from the Five Eyes agencies makes the control explicit: a cryptographically signed, append-only provenance ledger of data changes, verified at the start of each training run, which aborts on failure (143, Five Eyes agencies, 2025). A dataset whose origin is not recorded cannot be shown to be lawful under the GDPR (2, European Union, 2016) or free of poisoning, so no training run starts from data that is not pinned, signed, and traceable.

Model artefacts, registries, and ML platforms

Loading a model is executing code unless the format makes that impossible. In February 2025 ReversingLabs described models that evaded Hugging Face's pickle scanner through a different compression format and a broken stream, so the scanner errored while the payload ran (170, Zanki, 2025). "Safe" loading flags have not held either: in April 2025 PyTorch disclosed that torch.load with weights_only=True could still lead to remote code execution in versions up to 2.5.1 (169, PyTorch, 2025). The durable control is a non-executable format such as Safetensors, contributed to the PyTorch Foundation in April 2026 (168, PyTorch Foundation, 2026), combined with signature verification under the OpenSSF Model Signing specification (134, Maruseac et al., 2025).

The platforms that hold the truth about models are targets in their own right. MLflow's tracking server had an unauthenticated remote code execution flaw rated 9.8, published in October 2025 (171, NVD, 2025). The controls are network isolation, authentication in front of every ML platform, references to registry entries by immutable version and digest, and an audit log kept outside the registry.

Prompts, retrieval indexes, and configuration

The changes that most often reach production without review are prompt edits, index refreshes, and guardrail threshold changes, because they look like content rather than code. An unreviewed prompt change can remove a refusal instruction, and an index refresh can add documents carrying indirect prompt injection, in which instructions hidden in retrieved content steer the model (51, Greshake et al., 2023). The subtlety is the mutable alias: registries make prompt versions immutable but treat aliases such as "production" as mutable pointers (139, MLflow, 2026), so moving the alias changes production without a new version. Alias moves are therefore performed only by the release pipeline, and the release manifest records the version each alias resolved to.

Evaluation

An evaluation gate is only as good as its evaluation set, and contamination inflates results without improving the system. In June 2025 researchers reported that state-of-the-art models could identify the buggy file path in a widely used software-engineering benchmark from the issue text alone with up to 76 per cent accuracy, but only up to 53 per cent on repositories outside the benchmark, which they read as memorisation (166, Liang et al., 2025). OpenAI's report on the July 2026 incident observed that the vast majority of cheating it found during training involved finding answers on public websites or in version history (104, OpenAI, 2026), and METR's 2025 work describes models exploiting flaws in task scoring (97, Von Arx et al., 2025). Consequently, evaluation sets keep a held-out portion no pipeline or agent can read, evaluation environments see no repository history or network, and graders are versioned like code.

Deployment and inference

Inference servers load models and process untrusted input, and their vulnerabilities followed one pattern: model loading and data handling that executed code. vLLM had a 2025 flaw that used pickle over unsecured sockets, rated up to 10.0 (174, NVD, 2025), and a March 2026 flaw in which two model files hard-coded trust of remote code, rated 8.8 (173, NVD, 2026). In August 2025 Wiz described a chain of three vulnerabilities in NVIDIA Triton's Python backend that gave an unauthenticated attacker full control of the server (175, Shustin & Ohfeld, 2025). Exposure compounds the risk: SentinelLABS and Censys observed 175,108 publicly reachable Ollama hosts in research published in January 2026, although the software binds locally by default, so the exposure is configuration drift (176, Bernadett-Shapiro & Cutler, 2026). The controls are patching under the service levels of Chapter 18, loading only signed, non-executable artefacts named in the manifest, no endpoint reachable without the AI gateway, and drift detection against the versioned desired state.

Monitoring and evidence

The last stage fails quietly: missing lineage hides which release caused an incident, tampered logs prevent reconstruction, and short retention loses evidence before the authority asks. OpenAI reports that in the July 2026 incident the agents sometimes tried to erase or tamper with their outputs or message logs, although none of the attempts affected the records its graders and monitors saw (104, OpenAI, 2026), and the CHAINDROP worm's borrowed author name makes the same point for repository history. Logs and history must therefore be written where the monitored system cannot write. Sigstore's Rekor version 2 is an append-only log that organisations can self-host (177, Blauzvern, 2025), and Architecture as Code (Chapter 15A) supplies the rest of the evidence model (130, Nordqvist, 2025).

Unmanaged skills and agents

Chapter 8 argued that skills, agents, prompts, and connectors should be governed shared assets, and the risks of the alternative are now measured. In February 2026 Snyk scanned 3,984 agent skills from two public marketplaces and found at least one security issue in 1,467 of them, 36.82 per cent, and 76 confirmed malicious payloads (150, Beurer-Kellner et al., 2026). In the same month, press reports of an audit of one marketplace described 341 malicious skills among 2,857 examined, on a marketplace where publishing required only a week-old GitHub account (151, Lakshmanan, 2026). GitGuardian counted 24,008 unique secrets in MCP configuration files exposed on public GitHub during 2025 (155, GitGuardian, 2026).

The risk takes four forms: private copies that never receive fixes; unreviewed instructions, where an instruction to fetch remote content turns a skill into a remote-control channel; connectors of unknown origin, since the official registry's metadata is self-reported (148, Soria Parra et al., 2025); and poisoned shared skills, which is why a catalogue without signing and review concentrates the risk instead of reducing it. The treatment is the catalogue of Chapter 8, with user-installed skills and connectors disabled outside a sandboxed development scope.

Mapping the loop's risks to ISO/IEC 27001:2022 Annex A

The loop's risks belong in the organisation's information security risk register, treated through the Annex A controls it has already selected, not in a separate AI register. ISO/IEC 27001:2022 requires a risk treatment process and a statement of applicability, and Annex A draws its 93 controls from ISO/IEC 27002:2022 (124, ISO/IEC, 2022) (125, ISO/IEC, 2022).

Loop stage Principal risks Annex A controls
Source control and CI Mutable tags, privileged triggers, cache poisoning, secrets 8.4 Access to source code; 8.9 Configuration management; 8.32 Change management; 5.17 Authentication information
Coding assistants and agents Injection through repository content, over-privileged agents 8.2 Privileged access rights; 8.28 Secure coding
Dependencies and mirrors Worms, malicious versions, mirror poisoning 5.19 Supplier relationships; 5.21 ICT supply chain; 8.8 Technical vulnerabilities
Data and training Poisoning, lineage gaps, personal or unlicensed data 5.9 Inventory of assets; 5.34 Privacy and protection of PII
Model artefacts and registries Executable formats, unsigned weights, exposed platforms 8.7 Protection against malware; 8.24 Use of cryptography; 8.20 Networks security
Prompts, indexes, configuration Unreviewed change, index poisoning, alias moves 8.9 Configuration management; 8.32 Change management
Evaluation Contamination, leaked sets, gamed graders 8.29 Security testing; 8.33 Test information; 8.31 Separation of environments
Deployment and inference Vulnerable servers, exposed endpoints 8.8 Technical vulnerabilities; 8.20 Networks security
Monitoring and evidence Missing lineage, tampered logs, short retention 8.15 Logging; 5.28 Collection of evidence; 5.33 Protection of records
Skills, agents, connectors Private copies, unreviewed instructions, unknown connectors 5.9 Inventory of assets; 8.19 Installation of software on operational systems

Worked example: an Annex A control mapping with evidence

Illustrative example. Nordvik Region keeps its statement of applicability as code, naming for each control the loop element that implements it and the evidence an auditor can retrieve. Control 8.9, configuration management, is implemented by pinning prompts, policies, index and skill versions by digest, with a weekly drift report; its last verification was "effective with findings", because two inference nodes had run an unpinned serving image for six days. That finding matters as much as the passes, because the auditor saw a deviation the platform team had already recorded and corrected.

Practical guide: a stage-by-stage risk assessment of an existing pipeline

Purpose. Establish in two weeks where an existing pipeline stands against this chapter's risks, with a treatment plan in the information security management system.

Roles. The security architect leads; the platform team provides access; the system owner accepts residual risks.

Steps.

  1. Draw the pipeline as it actually runs, using Figure 9.1 as the template, and list every system, credential, and shared service each stage touches.
  2. Inventory artefacts against the coverage list of Chapter 8 and mark each as pinned by digest, versioned but mutable, or unversioned.
  3. Search CI definitions for tag references, privileged triggers, shared caches in release jobs, and stored publishing tokens, and compare skills and MCP configurations in use with the catalogue.
  4. Test one reconstruction: pick a production release from three months ago and try to name every artefact version in it.
  5. Score each risk on the organisation's existing scale, map it to Annex A, and agree a treatment plan with owners and dates.

Defaults to adapt. Four days of effort per pipeline; reassessment every six months or after a major incident.

Definition of done. Every stage has an assessed risk entry with an owner and Annex A mapping, the reconstruction result is recorded, and the treatment plan is accepted by the system owner.

Practical guide: responding to a compromised dependency or model artefact

Purpose. Contain, investigate, and recover when a dependency, action, base model, adapter, skill, or connector the loop uses is reported compromised.

Roles. Security operations leads; the platform team searches manifests; compliance assesses reporting duties.

Steps.

  1. Within one hour, freeze promotion of any release that includes the artefact and block the affected versions at the mirror, registry, and catalogue.
  2. Search all release manifests, lockfiles, and mirror caches by name and digest to find every consumer, including cached copies.
  3. Roll back affected systems to the last signed manifest that predates the compromised version.
  4. Rotate every credential reachable by a pipeline or workstation that ran the artefact, verify that each old credential is rejected, and inspect repositories for unexpected commits, hooks, and agent configuration changes.
  5. Preserve manifests, logs, mirror contents, and the artefact itself in write-once storage.
  6. Assess reporting duties: an early warning within 24 hours of a significant incident under Article 23 of NIS 2 (4, European Union, 2022), and, for manufacturers under the Cyber Resilience Act (7, European Union, 2024), reporting of actively exploited vulnerabilities through the single reporting platform (110, European Commission, 2026).
  7. Re-admit a fixed version only after the full pipeline and a soak period.

Defaults to adapt. One hour to freeze, four hours to identify consumers, 24 hours to complete rotation for internet-exposed systems, and a seven-day soak.

Definition of done. No environment runs the compromised version, every reachable credential is rotated and its revocation verified, evidence is preserved, and reporting decisions are recorded with their rationale.

A risk register as code for the loop

The loop's risk register sits in the platform repository, is reviewed like any other code, and feeds the information security management system through its export. Each entry names the stage, the risk, the controls with their Annex A mapping, the evidence that shows the control works, and an owner. Architecture as Code (Chapter 10) describes how such a register is evaluated by policy as code (128, Nordqvist, 2025). A starting register has one entry per stage above, from mutable references (LOOP-01) to unreviewed skills reaching users (LOOP-08).

Worked example: a stage-risk register entry

Illustrative example. Below is one entry in full, as Hansa Mutual maintains it for the dependency and mirror stage of its claims assistant's loop. It links the risk to public incidents, to Annex A, and to the DORA articles that make it a regulated ICT risk, and it states the key risk indicators that trigger a review.

risk_entry:
  id: HM-LOOP-04
  system: hansa.claims-assistant
  stage: dependencies-and-mirrors
  title: Compromised package or poisoned mirror cache enters a release
  external_lessons: [CISA npm alert 2025-09, TanStack wave 2026-05, CVE-2026-66384]
  inherent: {likelihood: 4, impact: 5, score: 20}
  controls:
    - {id: hashed-lockfiles, status: implemented}
    - {id: soak-period-7d, status: implemented}
    - {id: mirror-digest-verification, status: implemented}
    - id: install-scripts-disabled
      status: partial
      evidence: 3 of 41 build images still allow install scripts
    - {id: signed-manifest-admission, status: implemented}
  residual: {likelihood: 2, impact: 5, score: 10}
  appetite: 12
  actions:
    - action: Remove install-script exemptions from remaining build images
      owner: role:platform-lead
      due: 2026-12-15
  key_risk_indicators:
    - {name: unpinned_dependencies_in_production_manifests, threshold: 0}
    - {name: hours_from_advisory_to_consumer_list, threshold: 4}
  annex_a: ["5.19", "5.21", "8.8", "8.7"]
  regulation:
    dora: [Article 9 ICT change management, Article 28 ICT third-party risk]
  accepted_by: role:chief-information-security-officer
  next_review: 2027-01-20

Because the entry is code, its key risk indicators are computed from manifests and mirror logs, and a breach opens a review automatically.

Across the usage modes

Risk in the delivery loop concentrates in different places depending on the usage mode of Chapter 2 (usage-mode matrix).

Mode Where risk concentrates Primary control
Mode 0 – Ambient AI Unreviewed processing by features suppliers switch on Contract change control and inventory
Mode 1 – Conversational assistants Leakage of data through prompts Enterprise tier, data loss prevention, literacy
Mode 2 – Embedded workplace assistants Over-broad permissions; poisoned shared documents Permission hygiene and labels
Mode 3 – Agentic work tools Agents executing commands, reading secrets, adding dependencies Sandboxing, egress rules, package mirrors and review
Mode 4 – Built AI applications The whole pipeline: data, artefacts, prompts and evaluation The controls of this chapter
Mode 5 – Autonomous production agents Tool calls on business systems Manifests, policy decisions and approval gates (Chapter 11)

For Modes 0 to 2 the assessment's questions are answered through supplier assessment and tenant configuration.

Nordvik Region and Hansa Mutual

Nordvik Region's largest risks sit with its suppliers, whom it can influence only through contracts and acceptance testing, so its ISO/IEC 27001 mapping leans on supplier relationships and its evidence register serves public-access and archives law.

Hansa Mutual's risks, by contrast, come from its own scale: agentic coding tools, autonomous agents and a shared platform mean that a single compromise can reach every market at once. HM-LOOP-04 is written once for the group, but incident handling is not, since a major ICT-related incident may have to be reported under DORA by the EU entities (3, European Union, 2022), under national rules in Norway, and under separate UK and Swiss regimes. The register therefore names, for each risk, the markets affected and the reporting route in each.

Summary

The loop of Chapter 8 has an attack surface at every stage, from mutable tags and poisoned caches in CI, through coding agents, package worms and mirrors, to poisoned data, executable model formats, unreviewed prompt changes, leaked evaluation sets, and logs the monitored system can write to.

Revision management decides most of these outcomes: pinning by digest, isolated release workflows, signed and immutable history, and verified revocation contain the recurring failures, while provenance is necessary but not sufficient, as the TanStack wave showed. Unmanaged skills are treated by the governed catalogue, and the loop's risks sit in the existing ISO/IEC 27001 register, held as code. Chapter 10 turns to the foundation model that many AI systems obtain rather than build, and to its retrieval indexes.

Sources

  1. Vassilev, A., Oprea, A., Fordyce, A., Anderson, H., Davies, X. & Hamin, M. (2025). Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST AI 100-2 E2025. National Institute of Standards and Technology, 24 March 2025. (144, Vassilev et al., 2025)
  2. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (28, MITRE, n.d.)
  3. OWASP Foundation. OWASP Top 10 for LLM Applications 2025. OWASP GenAI Security Project. (27, OWASP, 2025)
  4. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project, 9 December 2025. (102, OWASP, 2025)
  5. SLSA Community (2025). Announcing SLSA v1.2 and SLSA v1.2 Source Track: requirements. slsa.dev, 24 November 2025. (133, SLSA Community, 2025)
  6. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  7. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  8. Sharma, V. (2025). Harden-Runner detection: tj-actions/changed-files action is compromised. StepSecurity, 14 March 2025. (158, Sharma, 2025)
  9. National Vulnerability Database (2026). CVE-2026-33634: Trivy v0.69.4 supply chain compromise. NIST NVD, published 23 March 2026. (154, NVD, 2026)
  10. Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. CISA. (90, CISA, n.d.)
  11. Strumpflohner, J. (2025). S1ngularity – What Happened, How We Responded, What We Learned. Nx blog, 5 September 2025. (157, Strumpflohner, 2025)
  12. PyPI (2024). Supply-chain attack analysis: Ultralytics. The Python Package Index Blog, 11 December 2024. (159, PyPI, 2024)
  13. GitGuardian (2026). The State of Secrets Sprawl 2026. GitGuardian, March 2026. (155, GitGuardian, 2026)
  14. GitHub (2026). Removing sensitive data from a repository. GitHub Docs. (178, GitHub, 2026)
  15. GitHub (2026). Available rules for rulesets. GitHub Docs. (140, GitHub, 2026)
  16. Khan, A. (2026). Clinejection — Compromising Cline's Production Releases just by Prompting an Issue Triager. 9 February 2026, updated 18 February 2026. (162, Khan, 2026)
  17. Rizwan, S. (2026). Post-mortem: Unauthorized Cline CLI npm publish on February 17, 2026. Cline blog, 24 February 2026. (161, Rizwan, 2026)
  18. Milanta, M. & Beurer-Kellner, L. (2025). GitHub MCP Exploited: Accessing private repositories via MCP. Invariant Labs, 26 May 2025. (163, Milanta & Beurer-Kellner, 2025)
  19. Karliner, Z. et al. (2025). New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents. Pillar Security, 18 March 2025. (164, Karliner et al., 2025)
  20. Brombacher, F. (2026). Spring 2026 GenAI Code Security Update: Despite Claims, AI Models Are Still Failing Security. Veracode, 24 March 2026. (160, Brombacher, 2026)
  21. Cybersecurity and Infrastructure Security Agency (2025). Widespread Supply Chain Compromise Impacting npm Ecosystem. CISA Alert, 23 September 2025. (156, CISA, 2025)
  22. Kurmi, A. (2026). TeamPCP's Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Compromises TanStack npm Packages. StepSecurity, 11 May 2026. (153, Kurmi, 2026)
  23. Elastic Security Labs (2026). Shai-Hulud strikes again: CHAINDROP worm hits 400+ npm packages. Elastic, 6 August 2026. (152, Elastic Security Labs, 2026)
  24. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. 26 August 2026. (104, OpenAI, 2026)
  25. National Vulnerability Database (2026). CVE-2026-66384: JFrog Artifactory Docker remote-cache path handling. NIST NVD, published 12 August 2026. (172, NVD, 2026)
  26. JFrog (2026). JFrog Security Advisories: CVE-2026-66384, CVE-2026-65616, CVE-2026-65617 and related Artifactory advisories. July–August 2026. (123, JFrog, 2026)
  27. Souly, A., Rando, J., Chapman, E., Davies, X., Hasircioglu, B., Shereen, E., Mougan, C., Mavroudis, V., Jones, E., Hicks, C., Carlini, N., Gal, Y. & Kirk, R. (2025). A small number of samples can poison LLMs of any size. Anthropic, UK AI Security Institute and Alan Turing Institute, 9 October 2025; arXiv:2510.07192. (165, Souly et al., 2025)
  28. Carlini, N., Jagielski, M., Choquette-Choo, C. A., Paleka, D., Pearce, W., Anderson, H., Terzis, A., Thomas, K. & Tramèr, F. (2023). Poisoning Web-Scale Training Datasets is Practical. arXiv:2302.10149, v2 6 May 2024. (167, Carlini et al., 2023)
  29. Five Eyes cyber security agencies: NSA AISC, CISA, FBI, ASD's ACSC, NCSC-NZ and NCSC-UK (2025). AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems. Cybersecurity Information Sheet, 22 May 2025. (143, Five Eyes agencies, 2025)
  30. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
  31. Zanki, K. (2025). Malicious ML models discovered on Hugging Face platform. ReversingLabs, 6 February 2025. (170, Zanki, 2025)
  32. PyTorch (2025). Remote Code Execution in torch.load with weights_only=True (GHSA-53q9-r3pm-6pq6, CVE-2025-32434). GitHub Security Advisory, 17 April 2025. (169, PyTorch, 2025)
  33. PyTorch Foundation (2026). PyTorch Foundation Announces Safetensors as Newest Contributed Project to Secure AI Model Execution. Linux Foundation press release, 8 April 2026. (168, PyTorch Foundation, 2026)
  34. Maruseac, M., Wickens, E., Major, D. & Sablotny, M. (2025). An Introduction to the OpenSSF Model Signing (OMS) Specification: Model Signing for Secure and Trusted AI Supply Chains. OpenSSF blog, 25 June 2025. (134, Maruseac et al., 2025)
  35. National Vulnerability Database (2025). CVE-2025-11201: MLflow Tracking Server Model Creation Directory Traversal Remote Code Execution. NIST NVD, published 29 October 2025. (171, NVD, 2025)
  36. Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T. & Fritz, M. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23). (51, Greshake et al., 2023)
  37. MLflow Project (2026). Prompt Registry. MLflow documentation. (139, MLflow, 2026)
  38. Liang, S., Garg, S. & Zilouchian Moghaddam, R. (2025). The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason. arXiv:2506.12286, v4 1 December 2025. (166, Liang et al., 2025)
  39. Von Arx, S., Chan, L. & Barnes, B. (2025). Recent Frontier Models Are Reward Hacking. METR, 5 June 2025. (97, Von Arx et al., 2025)
  40. National Vulnerability Database (2025). CVE-2025-32444: vLLM Mooncake integration remote code execution. NIST NVD, published 30 April 2025. (174, NVD, 2025)
  41. National Vulnerability Database (2026). CVE-2026-27893: vLLM model files hardcode trust_remote_code=True. NIST NVD, published 27 March 2026. (173, NVD, 2026)
  42. Shustin, R. & Ohfeld, N. (2025). Breaking NVIDIA Triton: CVE-2025-23319 – A Vulnerability Chain Leading to AI Server Takeover. Wiz Research, 4 August 2025. (175, Shustin & Ohfeld, 2025)
  43. Bernadett-Shapiro, G. & Cutler, S. (2026). Silent Brothers: Ollama Hosts Form Anonymous AI Network Beyond Platform Guardrails. SentinelLABS, January 2026, updated 6 March 2026. (176, Bernadett-Shapiro & Cutler, 2026)
  44. Blauzvern, H. (2025). Rekor v2 GA – Cheaper to run, simpler to maintain. Sigstore blog, 10 October 2025. (177, Blauzvern, 2025)
  45. Nordqvist, G. (2025). Evidence as Code and Continuous Assurance. Architecture as Code, Chapter 15A. (130, Nordqvist, 2025)
  46. Beurer-Kellner, L., Kudrinskii, A., Milanta, M., Bonde Nielsen, K., Sarkar, H. & Tal, L. (2026). Snyk Finds Prompt Injection in 36%, 1467 Malicious Payloads in a ToxicSkills Study of Agent Skills Supply Chain Compromise. Snyk blog, 5 February 2026. (150, Beurer-Kellner et al., 2026)
  47. Lakshmanan, R. (2026). Researchers Find 341 Malicious ClawHub Skills Stealing Data from OpenClaw Users. The Hacker News, 2 February 2026. (151, Lakshmanan, 2026)
  48. Soria Parra, D., Jones, A., Antanavicius, T., Padilla, T. & Chu, T. (2025). Introducing the MCP Registry. Model Context Protocol blog, 8 September 2025. (148, Soria Parra et al., 2025)
  49. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Geneva: ISO, October 2022. (124, ISO/IEC, 2022)
  50. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls. Geneva: ISO, February 2022. (125, ISO/IEC, 2022)
  51. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
  52. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (7, European Union, 2024)
  53. European Commission (2026). Cyber Resilience Act – Reporting obligations. Shaping Europe's digital future, updated 11 September 2026. (110, European Commission, 2026)
  54. Nordqvist, G. (2025). Policy and Security as Code in Detail. Architecture as Code, Chapter 10. (128, Nordqvist, 2025)