The EU AI Act requires organisations deploying high-risk AI systems to manage supply chain risk as an ongoing operational concern, not a one-time assessment. This page covers vendor evaluation, continuous dependency monitoring, foundation model provider tracking, and procedural alternatives for organisations building their supply chain security programme.
AI supply chain security operations address the ongoing management of trust dependencies across every external component an AI system relies upon. The supply chain extends beyond traditional software dependencies to encompass foundation models, training data from third parties, annotation services, ML frameworks, hardware accelerators, cloud infrastructure, and third-party inference APIs. Each element introduces a trust dependency where a compromise in any link can affect the system's security, performance, or compliance posture. Vendor risk assessments should be conducted before adoption, covering data governance practices, security certifications, data handling commitments, and incident response capabilities. Assessments are reviewed annually and re-conducted when a vendor's service scope or security posture changes materially. Continuous monitoring is essential because new vulnerabilities are discovered in ML frameworks regularly and foundation model providers may update models in ways that affect downstream systems. Automated tools such as Dependabot, Renovate, and Snyk Monitor provide real-time alerting on vulnerable dependencies. Foundation model provider monitoring requires subscribing to changelogs, running sentinel tests, reviewing terms of service, and tracking security posture. For organisations without automated tooling, manual periodic reviews using the NVD and SHA-256 hash verification for model artefacts provide a procedural alternative.
The AI supply chain extends well beyond traditional software dependencies to include every external component that an AI system relies upon.
The AI supply chain extends well beyond traditional software dependencies to include every external component that an AI system relies upon. Pre-trained foundation models, whether accessed via API or deployed locally, represent a major trust dependency. Training data sourced from third parties, annotation and labelling services, ML frameworks and libraries, hardware accelerators and their firmware, cloud infrastructure and managed services, and third-party APIs called during inference all form part of the chain. Each element introduces a trust dependency; a compromise in any single link can affect the system's security, performance, or eu ai act compliance posture.
Every third-party component should undergo a vendor risk assessment before adoption, with the depth of assessment proportionate to the component's criticality.
Every third-party component should undergo a vendor risk assessment before adoption, with the depth of assessment proportionate to the component's criticality. For foundation model providers, the assessment should cover data governance practices: what data was used for training, whether personal data was included, and whether copyright-infringing material was used. Security certifications such as SOC 2 and ISO 27001 should be verified as part of this process.
The assessment should also cover the provider's data handling commitments, specifically whether inference inputs are used for further training and whether data is retained. Contractual commitments regarding model versioning and change notification are essential, as are the provider's incident response capabilities. These factors directly affect the downstream system's ability to maintain its own compliance posture.
Supply chain risk does not remain static after the initial assessment.
Supply chain risk does not remain static after the initial assessment. New vulnerabilities are discovered in ML frameworks on a regular basis. Foundation model providers update their models, sometimes changing behaviour in ways that affect downstream systems. Data providers may alter their data collection practices or experience their own data breaches.
Continuous monitoring should include automated alerts for newly disclosed vulnerabilities in any component listed in the . It should also include monitoring of foundation model provider release notes and change logs for behavioural changes that could affect the system, periodic reassessment of data provider practices, and monitoring of industry threat intelligence feeds for supply chain attack campaigns targeting ML infrastructure.
Automated dependency monitoring tools such as Dependabot and Renovate watch the project's dependency manifest and alert when new versions are available or when vulnerabilities are disclosed in current versions.
Automated dependency monitoring tools such as Dependabot and Renovate watch the project's dependency manifest and alert when new versions are available or when vulnerabilities are disclosed in current versions. These tools can automatically open pull requests that update vulnerable dependencies, triggering the CI pipeline's validation gates before the update reaches production.
For critical vulnerabilities with a CVSS score above nine, the remediation SLA should be within 24 to 72 hours. The automated pull request accelerates the response by eliminating the manual step of identifying the vulnerable package and preparing the update. This approach integrates directly with the broader management process.
Continuous vulnerability monitoring goes beyond PR-time scanning to track the deployed system's actual dependency tree.
Continuous vulnerability monitoring goes beyond PR-time scanning to track the deployed system's actual dependency tree. Tools such as Snyk Monitor examine the resolved versions in the production container, looking beyond the declared dependencies, and check them against continuously updated vulnerability databases.
A vulnerability disclosed on a given afternoon triggers an alert within hours, even if no code change has occurred. This closes the gap between vulnerability disclosure and detection that periodic scanning leaves open. The distinction matters because supply chain attacks often target transitive dependencies that the development team may not be directly aware of.
Foundation model provider monitoring is a supply chain concern specific to AI systems.
Foundation model provider monitoring is a supply chain concern specific to AI systems. When the system uses a third-party model, whether accessed via API or downloaded, the provider's practices directly affect the system's compliance posture. A provider that silently updates their model, changes their content filtering, or modifies their API's behaviour can alter the downstream system's outputs without any change to the downstream system's code or configuration.
Monitoring should include four activities: subscribing to the provider's changelog via RSS, webhook, or email notifications; running sentinel tests at regular intervals to detect behavioural changes; reviewing the provider's terms of service periodically for material changes; and tracking the provider's security posture through security incident disclosures, compliance certifications, and audit reports. The Technical SME assesses any material change for its impact on the downstream system's compliance profile and documents the assessment in the .
SBOM compilation and dependency review can be conducted manually when automated tooling is not yet in place.
SBOM compilation and dependency review can be conducted manually when automated tooling is not yet in place. The Technical SME completes a manual dependency review checklist before adding or updating any dependency. This checklist covers the project's security track record, licence terms, maintenance status, and known vulnerabilities via the NVD website. Risk Management Framework principles apply to prioritising which dependencies receive the most scrutiny.
pip-audit, npm audit, and Trivy are all command-line tools with no licensing cost that can be used for dependency vulnerability scanning.
Quarterly dependency vulnerability reviews, quarterly reviews of foundation model provider communications, annual supply chain risk reassessments, and scheduled manual sentinel test execution.
The manual approach discovers changes at the next scheduled review rather than in real time, losing live alerting on new vulnerabilities or provider changes. Dependabot and Renovate are free for public repositories and low-cost for private ones.
Foundation models, third-party training data, annotation services, ML frameworks, hardware accelerators, cloud infrastructure, and inference APIs all form part of the AI supply chain.
Data governance practices, security certifications (SOC 2, ISO 27001), data handling commitments, model versioning and change notification, and incident response capabilities.
Supply chain risk is not static: ML framework vulnerabilities are discovered regularly, model providers change behaviour, and data providers may alter practices or suffer breaches.
Tools like Dependabot and Renovate watch dependency manifests, alert on vulnerabilities, and automatically open pull requests to update vulnerable packages through CI validation gates.
It tracks the deployed system's actual resolved dependency tree in production containers against continuously updated vulnerability databases, alerting within hours of disclosure.
Subscribe to changelogs, run sentinel tests to detect behavioural changes, review terms of service periodically, and track provider security posture through certifications and audit reports.
Manual dependency review checklists, quarterly NVD checks, SHA-256 hash verification for model artefacts, and scheduled reviews of provider communications.
Supply chain vulnerabilities were introduced as a threat category in the broader Cybersecurity for AI Systems framework. This section addresses the operational programme needed to manage supply chain risk continuously, not at a single point in time.
For data providers, the assessment should cover data provenance and licensing, data quality controls, data handling and security practices, and the provider's compliance with applicable data protection legislation. The security team documents and retains vendor risk assessments as Module 9 evidence. Assessments are reviewed annually by the security team and re-conducted whenever the vendor's service scope or security posture changes materially.
The MITRE ATLAS navigator provides a structured way to track the evolving threat landscape for AI supply chain attacks. New attack techniques are disclosed regularly in academic publications and security conferences. The Technical SME updates the organisation's threat model when ATLAS is updated, and the cybersecurity testing programme should incorporate newly documented techniques.
Quarterly, the Technical SME reviews all current dependencies against the NVD for newly disclosed vulnerabilities. For model artefacts, the engineering team computes and records the SHA-256 hash at download, then verifies it before use. Scanning tools such as pip-audit, npm audit, and Trivy are all command-line tools with no licensing cost, making them accessible even for organisations with limited tooling budgets.
Ongoing supply chain monitoring can also be conducted through manual periodic reviews. This includes quarterly dependency vulnerability review, quarterly review of foundation model provider communications such as changelogs, blog posts, and security advisories, an annual supply chain risk reassessment, and manual sentinel test execution on a scheduled basis.
The manual approach discovers changes at the next scheduled review rather than in real time, losing live alerting on new vulnerabilities or provider changes. Dependabot and Renovate are free for public repositories and low-cost for private ones, making the transition to automated monitoring a practical next step for most organisations.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
Accuracy, Robustness, Cybersecurity
