# MLOps and AI Supply Chain Security: Model, Dataset and Pipeline Risks

**URL:** https://securesys.com.tr/en/learning/software-and-ai-security/what-is-mlops-security-ai-supply-chain-and-model-security

![MLOps and AI Supply Chain Security: Model, Dataset and Pipeline Risks](/images/bilgi-merkezi/covers/cover-yzguv-09.webp)

### Introduction: AI Security Starts Before the Model Is Trained

Artificial intelligence technologies are being used more and more in enterprise business processes.

Organisations are integrating large language models into their applications.

They detect fraud with machine learning models.

They carry out quality control with image processing systems.

They benefit from anomaly detection models in cyber security operations.

However, all of these systems have one thing in common.

AI models do not work on their own.

Different technologies are used together to develop, train, test, deploy and monitor models.

Training datasets are prepared.

Open source libraries are used.

Model files are downloaded.

GPU infrastructures are configured.

CI/CD pipelines are run.

Versions are kept in model registry systems.

Container images are built.

And models are made available in the production environment through API services.

Each of these components forms an attack surface that needs to be assessed from a security perspective.

For example, a model file downloaded from an untrusted source may contain malicious content.

A manipulated dataset can influence the behaviour of the model.

A model registry that is open to unauthorised access can lead to model files being modified.

An insecure CI/CD pipeline can allow an attacker to push uncontrolled components into the production environment.

For this reason, it is not correct to limit AI security to the answers a model gives.

**Secure AI must be built on secure data sources, trustworthy model components and controlled development processes.**

This is exactly where MLOps security becomes important.

In this article, we will examine the concept of MLOps, the AI supply chain, model development pipelines and enterprise security controls from a technical and operational point of view.

### \1. What Is MLOps?

MLOps is an abbreviation of Machine Learning Operations.

It refers to the processes and practices used to develop, train, deploy, monitor and manage machine learning models.

The MLOps approach is associated with adapting the DevOps principles of the software development world to the machine learning lifecycle.

However, MLOps is not simply DevOps applied under a different name.

This is because, in machine learning systems, training data, model parameters, experiment results and model performance must be managed in addition to source code.

#### Which processes fall within the scope of MLOps?

Data collection.

Data preparation.

Feature engineering.

Model training.

Experiment management.

Model evaluation.

Model versioning.

Model deployment.

Model monitoring.

Retraining.

Automating these processes can deliver operational efficiency.

However, automation that is not designed securely can create new risks.

### \2. What Is MLOps Security?

MLOps Security is an approach that aims to protect the data, model, software, infrastructure and operational processes in the machine learning lifecycle against security threats.

Within this scope, not only the behaviour of the model but also the systems in which the model is produced and run are assessed.

#### Core security objectives

**Confidentiality:** Training data, model files and sensitive information must be protected against unauthorised access.

**Integrity:** Datasets, model artifacts and pipeline components must not be modifiable in an unauthorised way.

**Availability:** The continuity of training and inference systems must be preserved.

**Traceability:** It must be possible to track which data, code and configuration a model was produced with.

**Reproducibility:** Under suitable conditions, model development processes must be repeatable.

**Accountability:** It must be possible to determine who made critical model changes and with what approval.

These objectives form the foundation of secure and sustainable AI operations.

### \3. The Difference Between DevOps, DevSecOps and MLOps

DevOps focuses on managing software development and operations processes together.

DevSecOps aims to integrate security controls into the software development lifecycle.

MLOps, in turn, manages the lifecycle of machine learning models.

Secure MLOps refers to the systematic inclusion of security controls in these processes.

| Approach | Core focus |
| --- | --- |
| DevOps | Software development and operations |
| DevSecOps | Security in the software lifecycle |
| MLOps | Machine learning lifecycle |
| Secure MLOps | Security in machine learning processes |

These approaches are not alternatives to one another.

For example, in an AI application, DevSecOps controls may be needed for secure API development, while Secure MLOps controls may be needed for the integrity of the training dataset.

In an enterprise security architecture, these processes should be assessed together.

### \4. What Is the AI Supply Chain?

The AI Supply Chain is the supply ecosystem formed by the external and internal components used while developing and operating an AI system.

This ecosystem can be broader than the traditional software supply chain.

This is because not only software packages but also datasets and model files constitute important dependencies.

#### AI Supply Chain components

- Training datasets.
- Open source models.
- Model weights.
- ML frameworks.
- Python packages.
- Container images.
- Model registry systems.
- GPU drivers and runtime environments.
- Embedding models.
- Third-party API services.
- Data processing tools.
- Model optimisation components.

A compromise of the security of any one of these components can affect the entire AI application.

### \5. Why Does AI Supply Chain Security Matter?

In traditional software security, the risks of third-party dependencies have been assessed for a long time.

In AI systems, however, the number and types of dependencies can expand.

For example, even if an organisation does not develop its own model, it may use an open source foundation model.

This model may be downloaded from a third-party platform.

Different libraries may be required for the model to run.

Fine-tuning may be carried out with external datasets.

Deployment, in turn, may take place in a cloud-based container environment.

The origin, integrity and security of every component in this chain matter.

#### Possible attack targets

Modification of the model file.

Manipulation of the dataset.

Insertion of a malicious dependency.

Compromise of the CI/CD pipeline.

Unauthorised actions on the model registry.

Modification of deployment packages.

For this reason, AI Supply Chain Security is an important security component of model development processes.

### \6. Risks of Untrusted Model Files

Open source AI models offer organisations significant opportunities.

However, the security of model files downloaded from the internet must be assessed.

A model file may not consist solely of mathematical parameters.

Some model packages may contain configuration files, custom code or serialised objects.

Untrusted serialisation formats in particular can create risk.

#### The security problem

Some serialisation mechanisms have features that can cause code to be executed while the file is being loaded.

For this reason, loading untrusted model artifacts directly in a production or development environment can be risky.

#### Protection approach

Model sources must be verified.

Artifact hash values must be checked.

Secure file formats should be preferred.

Unnecessary custom code execution features should be disabled.

Model files should be evaluated in isolated environments.

The model provider's security advisories should be followed.

**The fact that a model file can be downloaded does not mean it is secure.**

### \7. What Is Model Provenance?

Model Provenance is the traceability of information about the origin and production history of an AI model.

Within this scope, answers are sought to the following questions:

Who developed the model?

Which foundation model was used?

Which datasets was it trained with?

Which code version was used?

Which configurations were applied?

Which security tests did it pass?

Who promoted it to the production environment?

This information is important for model security.

This is because, when a security incident occurs, it makes it easier to identify the affected model versions.

#### Example

Let us assume that an organisation uses three different model versions in its production environment.

A security problem is identified in a particular training dataset.

If model provenance records exist, the model versions that used this dataset can be identified.

In this way, risk assessment can be carried out faster.

### \8. How Is Model Artifact Integrity Ensured?

Model artifacts are the files used in the deployment of a trained model.

These files may carry high commercial value.

They can also directly affect model behaviour.

For this reason, artifact integrity must be protected.

#### Security controls

Cryptographic hash verification.

Digital signature mechanisms.

Secure artifact storage.

Access control.

Version management.

Change logs.

Approved deployment processes.

However, for hash verification to be reliable, the expected hash value must also be obtained from a trusted source.

If an attacker can modify both the file and the verification information, the control can become ineffective.

For this reason, artifact security should be addressed together with a trusted source and access control.

### \9. What Is a Model Registry?

A Model Registry is the system in which the versions and lifecycle information of AI models are managed.

It can play an important role in enterprise MLOps processes.

A model registry can hold different model versions, performance results, metadata and artifact links.

#### Purposes of using a Model Registry

Model versioning.

Model approval processes.

Linking experiment results.

Determining the production model.

Rollback management.

Monitoring the model lifecycle.

These systems can be critical from a security perspective.

This is because they can influence which model is promoted to the production environment.

### \10. Model Registry Security Risks

Different security problems can arise in model registry systems.

#### Unauthorised model upload

An attacker or unauthorised user can add a new model version.

#### Model modification

An existing model artifact can be modified.

#### Model theft

An unauthorised user can download private model files.

#### Metadata manipulation

The security or performance information of a model can be altered.

#### Privilege escalation

Because of insufficient access control, a user can obtain production deployment privileges.

#### Protection approach

Role-based access control should be applied.

Model upload and approval privileges should be separated.

Critical changes should be recorded.

Artifact integrity should be verified.

Production deployments should be carried out in a controlled way.

### \11. What Is an ML Pipeline?

An ML Pipeline is the automation of the operations in the machine learning lifecycle within a defined flow.

For example, a pipeline may include the following steps:

Data ingestion.

Data cleaning.

Feature extraction.

Model training.

Model evaluation.

Model packaging.

Registration in the model registry.

Deployment to the production environment.

Thanks to automation, these processes can be made faster and repeatable.

However, if pipeline security is insufficient, the attacker's impact can widen.

### \12. What Is ML Pipeline Security?

ML Pipeline Security aims to protect model development and deployment flows against unauthorised access, manipulation and malicious components.

Within this scope, pipeline code, the runtime environment, credentials, data sources and deployment privileges are assessed.

#### Core security areas

Pipeline authentication.

Service account privileges.

Secret management.

Code integrity.

Data source verification.

Artifact security.

Deployment approvals.

Audit logging.

These controls are related to traditional CI/CD security.

However, in ML pipelines, data and model components must also be protected separately.

### \13. ML Pipeline Attack Scenario

Let us assume that an organisation uses an automated model training pipeline.

The pipeline ingests new data at regular intervals.

It retrains the model.

It runs performance tests.

It promotes the successful model to the production environment.

However, the reliability of the data source is not checked sufficiently.

#### Possible risk

If an attacker manages to manipulate the training data, they can influence the behaviour of the model.

If the model security tests are insufficient, the manipulated model can be promoted to the production environment.

#### Secure approach

Data sources should be verified.

Data changes should be monitored.

Training datasets should be versioned.

Model performance should be evaluated with independent tests.

Critical model changes should go through an approval process.

This example shows that data security and pipeline security must be addressed together.

### \14. CI/CD Security and MLOps

MLOps systems often work integrated with CI/CD tools.

For this reason, traditional CI/CD security controls are important.

#### Main risks

Insecure pipeline scripts.

Over-privileged service accounts.

Exposed access keys.

Untrusted dependencies.

Unauthorised deployment.

Insufficient change control.

#### Protection approach

Pipeline privileges should be restricted.

Secret management should be used.

Code review processes should be applied.

Dependencies should be checked.

Deployment environments should be separated.

Critical operations should be recorded.

These controls are fundamental parts of a Secure MLOps architecture.

### \15. Secret Management in MLOps Environments

Different access credentials can be used in model development processes.

For example:

Cloud API keys.

Database connection details.

Model registry access tokens.

Container registry credentials.

Data storage service accounts.

Storing this information in plain text in pipeline code or configuration files can create risk.

#### Secure approach

Centralised secret management should be used.

Short-lived credentials should be preferred.

Service accounts should run with least privilege.

Secret access should be monitored.

Credentials should be reviewed regularly.

In the event of a suspected leak, the relevant access should be revoked.

### \16. Training Dataset Security

The behaviour of machine learning models is shaped by training data.

For this reason, training datasets are critical assets from a security perspective.

#### Dataset risks

Data Poisoning.

Unauthorised data modification.

Leakage of sensitive data.

Incorrect labelling.

Untrusted data source.

Missing data versioning.

#### Protection approach

Data sources should be recorded.

Data integrity should be checked.

Datasets should be versioned.

Access privileges should be restricted.

Sensitive data should be classified.

Abnormal data changes should be evaluated.

These controls support model reliability.

### \17. What Is Dataset Provenance?

Dataset Provenance is the traceability of a dataset's origin and change history.

For example, a training dataset may have been compiled from different sources.

Corporate databases.

Open data sources.

Third-party data providers.

User-generated content.

The reliability of these sources can differ.

#### Within the scope of dataset provenance

The origin of the data.

Collection time.

Processing method.

Labelling process.

Change history.

Usage permissions.

Data classification.

and similar information can be kept.

This approach can make it easier to investigate Data Poisoning and data quality problems.

### \18. Security Risks of Open Datasets

Open datasets can be widely used in machine learning development processes.

However, the security and terms of use of open datasets must be assessed.

#### Possible risks

Manipulated samples.

Incorrect labels.

Personal data content.

Licence ambiguity.

Source reliability problems.

Malicious files.

#### Security approach

The source of the dataset should be verified.

Licence and terms of use should be reviewed.

Sensitive data scanning should be performed.

Data integrity should be checked.

Appropriate sampling and quality analyses should be carried out.

The use of open datasets should not be left outside the security assessment.

### \19. What Is an AI-BOM?

AI-BOM is an abbreviation of Artificial Intelligence Bill of Materials.

It refers to approaches aimed at taking an inventory of the components and dependencies of an AI system.

It is related to the SBOM concept used in the traditional software world.

However, an AI-BOM can cover not only software packages but also AI-specific components.

#### Information that can be included in an AI-BOM

Model name.

Model version.

Model provider.

Foundation model dependencies.

Training datasets.

ML frameworks.

Model artifacts.

External services.

Licence information.

Related security metadata.

The fields and formats used for an AI-BOM may vary depending on the standard applied or the organisation's own model.

For this reason, it should not be assumed that an AI-BOM is kept in the same structure in every organisation.

### \20. What Is an ML-BOM?

ML-BOM is an inventory approach associated with the expression Machine Learning Bill of Materials.

It aims to make the components and dependencies of a machine learning system visible.

The concepts of AI-BOM and ML-BOM may be used in similar or overlapping senses in different sources.

For this reason, it is important for an organisation to define clearly which scope and data fields it uses.

#### Why is an ML-BOM important?

It supports tracking of model dependencies.

It makes supply chain risks visible.

It makes it easier to identify the affected components during security incidents.

It contributes to model version management.

However, creating a component inventory does not provide security on its own.

The inventory must be kept up to date and used in risk management processes.

### \21. The Difference Between SBOM, AI-BOM and ML-BOM

| Concept | Focus |
| --- | --- |
| SBOM | Software components and dependencies |
| AI-BOM | The components of an AI system, including model, data and software |
| ML-BOM | Components and dependencies in the machine learning lifecycle |

The scope of these concepts may vary depending on the framework used.

In an enterprise approach, what matters is not only the name of the inventory.

It is which components are tracked and how they are linked to security risks.

### \22. Model Dependency Security

AI models may require different software dependencies.

For example:

Python libraries.

ML frameworks.

GPU runtime components.

Data processing packages.

Model serving tools.

Vulnerabilities in these dependencies can affect the model infrastructure.

#### Security approach

Dependencies should be added to the inventory.

Vulnerabilities should be tracked.

Update policies should be established.

Unnecessary packages should be removed.

Package installation from untrusted sources should be restricted.

This approach can be applied together with traditional Software Composition Analysis processes.

### \23. Container Security and MLOps

MLOps systems often run on container technologies.

For example, the model training environment or the inference service can be run inside a container.

This approach can provide portability and operational convenience.

However, container security is important.

#### Risks

Insecure base image.

Outdated dependencies.

Over-privileged container.

Exposed secrets.

Misconfigured volume access.

Insufficient network isolation.

#### Protection approach

Trusted base images should be used.

Container images should be scanned.

The principle of least privilege should be applied.

Secrets should be managed securely.

Network access should be restricted.

Runtime security controls should be considered.

### \24. Kubernetes and Model Serving Security

Enterprise AI systems can be run on orchestration platforms such as Kubernetes.

In this case, the model serving infrastructure becomes dependent on Kubernetes security controls.

#### Important areas

RBAC.

Network Policy.

Secret Management.

Pod Security.

Container Image Security.

Service Account Permissions.

Audit Logging.

#### Example risk

The model serving service account may hold broader privileges than necessary.

In this case, if the service is compromised, the resources an attacker can reach increase.

#### Protection approach

Service accounts should be configured with least privilege.

Network access should be restricted.

Critical namespaces should be separated.

Secret access should be controlled.

Security logs should be monitored.

### \25. GPU Infrastructure and Training Environment Security

Training large AI models can require significant computing resources.

For this reason, GPU infrastructures can be critical assets in enterprise MLOps environments.

#### Security risks

Unauthorised access to the training environment.

Resource consumption.

Leakage of sensitive data.

Insecure drivers.

Isolation of shared infrastructure.

Unauthorised access to model files.

#### Security approach

Training environments should be isolated.

User access should be restricted.

Driver and runtime environment components should be managed.

Resource usage should be monitored.

Sensitive data storage areas should be protected.

These controls are especially important in multi-user training infrastructures.

### \26. Model Deployment Security

Model Deployment is the transfer of a trained model to a usable environment.

In this process, model artifacts, configurations and service components can be promoted to the production environment.

#### Possible risks

Deployment of the wrong model version.

Unauthorised deployment.

Compromised artifact integrity.

Insecure configuration.

Missing access control.

#### Secure approach

Deployment processes should be approved.

Model artifacts should be verified.

Environments should be separated.

Rollback mechanisms should be established.

Changes should be recorded.

These controls ensure that model deployment is carried out in a controlled way.

### \27. Model Rollback and Security

Model updates do not always deliver the expected results.

A new model version can cause a performance problem.

It can be incompatible with security controls.

Or it can show unexpected behaviour.

For this reason, a model rollback mechanism is important.

Rollback makes it possible to return to the previous model version when necessary.

#### Security requirements

Previous model versions should be stored securely.

Artifact integrity should be verified.

Rollback privileges should be restricted.

The operation should be recorded.

The security status of the model being rolled back to should also be assessed.

In critical AI systems in particular, a rollback plan supports operational continuity.

### \28. Model Monitoring and Security

Model monitoring refers to observing model behaviour in the production environment.

This process should not be limited to performance measurement.

It should also be assessed from a security perspective.

#### Areas that can be monitored

Model performance.

Changes in data distribution.

Abnormal query behaviour.

API usage volume.

Resource consumption.

Unexpected model outputs.

Unauthorised access attempts.

#### Key point

Not every change in model behaviour means a cyber attack.

However, unexpected changes can be subject to a security assessment.

For this reason, model monitoring and security monitoring processes should be linked appropriately.

### \29. Model Drift and Retraining Security

Model Drift is a concept associated with changes in model performance or data relationships over time.

This situation may require the model to be retrained.

However, retraining processes must also be assessed from a security perspective.

#### Risks

New data having been manipulated.

Incorrect labelling.

Untrusted data sources.

Uncontrolled automated deployment.

#### Secure approach

New data should be verified.

Training datasets should be versioned.

Model changes should be tested.

Critical deployments should be approved.

Model performance should be monitored.

These controls are important in automated learning processes.

### \30. Secure MLOps Architecture

The Secure MLOps approach aims to apply security controls across the entire model lifecycle.

#### Example architecture

Data Sources

|

v

Data Source Verification

|

v

Data Classification and DLP

|

v

Dataset Versioning

|

v

Secure Training Environment

|

v

Model Security Testing

|

v

Artifact Signature / Hash Verification

|

v

Model Registry

|

v

Approved Deployment Pipeline

|

v

Model Serving / API

|

v

Security Monitoring

|

v

Controlled Retraining

This architecture is an example.

The real implementation should be designed according to the organisation's model type, infrastructure and risk level.

### \31. What Is an MLOps Security Assessment?

An MLOps Security Assessment is the evaluation of machine learning development and operations processes from a security perspective.

This work can cover different components.

#### Assessment areas

Data source security.

Dataset provenance.

ML Pipeline Security.

CI/CD security.

Model Registry Security.

Artifact integrity.

Container security.

Kubernetes security.

Model API security.

Model monitoring.

#### Assessment approach

First, the architecture and data flows are identified.

Then critical assets are classified.

Trust boundaries are assessed.

Technical controls are reviewed.

Risk-based security tests are carried out.

The impact of findings is assessed.

A remediation plan is created.

### \32. The Difference Between an MLOps Pentest and a Traditional Pentest

A traditional pentest can assess areas such as network, system, web and API security.

An MLOps Pentest, in addition to these areas, examines model development and deployment processes.

For example, during a traditional pentest, a Kubernetes API access problem may be identified.

During MLOps Security Testing, however, the risk of unauthorised artifact modification on the model registry can be assessed.

Similarly, training dataset integrity or pipeline privileges can be examined.

For this reason, an MLOps Pentest does not replace traditional security tests.

It is an assessment extended to cover risks specific to the AI lifecycle.

### \33. Example Scenario: Using an Open Source Model

Let us assume that an organisation wants to use an open source large language model.

The model is downloaded from the internet.

It is then run on the organisation's GPU infrastructure.

#### Risk 1: Model source

The true provider of the model may not have been verified.

#### Risk 2: Artifact security

The model file may have been modified.

#### Risk 3: Dependencies

Libraries containing vulnerabilities may be used.

#### Risk 4: Runtime environment

The model may be run with broader system privileges than necessary.

#### Risk 5: Update management

New model versions may be applied in an uncontrolled way.

#### Secure approach

The model source should be verified.

Artifact integrity should be checked.

Dependencies should be assessed.

The runtime environment should be isolated.

Model versions should be managed.

Security tests should be carried out.

This approach forms the basic security requirements for using open source models.

### \34. Example Scenario: Automated Model Training

Let us assume that a financial institution retrains its fraud detection model at regular intervals.

New transaction data is added automatically to the training dataset.

The pipeline retrains the model.

Performance tests are carried out.

The successful model is promoted to the production environment.

#### Risk 1: Data Poisoning

The new training data may have been manipulated.

#### Risk 2: Pipeline privileges

Service accounts may hold broader privileges than necessary.

#### Risk 3: Model integrity

Artifact files may be modified in an unauthorised way.

#### Risk 4: Deployment security

The wrong model version may be promoted to production.

#### Risk 5: Lack of monitoring

Unexpected changes in model behaviour may go unnoticed.

#### Secure approach

Data sources should be verified.

Pipeline privileges should be restricted.

Artifact integrity should be checked.

Critical deployment operations should be approved.

Model behaviour should be monitored.

This example shows why the Secure MLOps approach is necessary.

### \35. The SECURESYS Secure MLOps Approach

At SECURESYS, we believe that AI security should not be limited to assessing the model's answers.

This is because the reliability of AI systems is directly linked to the security of development and operations processes.

For this reason, in the Secure MLOps approach, data, model, software and infrastructure security should be addressed together.

Depending on the project scope, the following areas can be assessed:

#### MLOps Security Assessment

Reviewing model development and operations processes from a security perspective.

#### AI Supply Chain Security

Assessing model, dataset and software dependencies.

#### ML Pipeline Security

Reviewing the security controls of automated training and deployment processes.

#### Model Registry Security

Assessing model versioning and artifact management infrastructure.

#### Model Artifact Security

Reviewing integrity and reliability controls for model files.

#### Container and Kubernetes Security

Assessing model training and inference environments from a security perspective.

#### AI Security Testing

Carrying out security tests specific to model behaviour and application architecture.

#### DevSecOps Integration

Integrating security controls into development and deployment processes.

The aim of this approach is not only to identify vulnerabilities.

It is to support organisations in developing their AI systems in a secure, traceable and sustainable way.

**A secure AI model cannot be considered independently of secure development and deployment processes.**

### \36. Secure MLOps Checklist

#### Data security

- Have the training data sources been verified?
- Are datasets being versioned?
- Have Data Poisoning risks been assessed?
- Has sensitive data been classified?

#### Model security

- Have the model sources been verified?
- Is artifact integrity being checked?
- Are model versions being managed?
- Are model security tests being carried out?

#### Pipeline security

- Has pipeline access been restricted?
- Is secret management being applied?
- Are code changes being checked?
- Are deployment processes being approved?

#### Supply chain

- Have model dependencies been inventoried?
- Have open source components been assessed?
- Has the need for an AI-BOM or ML-BOM been analysed?
- Are vulnerabilities being tracked?

#### Infrastructure security

- Has container security been assessed?
- Is Kubernetes access being controlled?
- Have training environments been isolated?
- Has model registry security been ensured?

#### Operational security

- Is model behaviour being monitored?
- Is Model Drift being assessed?
- Is there a rollback mechanism?
- Has a security incident response process been defined?

This checklist can be extended according to the organisation's infrastructure and the intended use of the model.

### Frequently Asked Questions

#### What is MLOps?

MLOps refers to the processes and practices used to develop, train, deploy and monitor machine learning models.

#### What is MLOps security?

MLOps security is the protection of the data, model, software and infrastructure components in the machine learning lifecycle against security threats.

#### What is Secure MLOps?

Secure MLOps is the integration of security controls into model development, training, deployment and operations processes.

#### What is the AI Supply Chain?

The AI Supply Chain is the supply ecosystem formed by the model, data, software and infrastructure components used while developing and operating an AI system.

#### Why is AI Supply Chain Security important?

Untrusted model files, manipulated datasets and malicious dependencies can affect the security of an AI system.

#### What is a Model Registry?

A Model Registry is the system in which model versions, artifacts and the related lifecycle information are managed.

#### What is a Model Artifact?

A Model Artifact refers to the files and related components used to store, distribute or reuse a trained model.

#### What is Model Provenance?

Model Provenance is the traceability of a model's origin and development history.

#### What is Dataset Provenance?

Dataset Provenance is the traceability of a dataset's origin, processing steps and change history.

#### What is ML Pipeline Security?

ML Pipeline Security is the protection of model development and deployment flows against unauthorised access and manipulation.

#### What is an AI-BOM?

An AI-BOM is an approach to taking an inventory of the model, data, software and other components of an AI system.

#### What is an ML-BOM?

An ML-BOM is an inventory approach that aims to make the components and dependencies of a machine learning system visible.

#### What is the difference between an AI-BOM and an SBOM?

While an SBOM focuses on software components, an AI-BOM can also cover AI-specific model and data components.

#### Is it safe to use an open source model?

Security depends on the model's source, artifact integrity, dependencies and runtime environment.

#### What is an MLOps Pentest?

An MLOps Pentest is the assessment of model development, training and deployment infrastructure through controlled security scenarios.

#### Is DevSecOps necessary for Secure MLOps?

DevSecOps controls support the Secure MLOps approach. However, data and model security controls specific to machine learning are also necessary.

### Conclusion: Secure AI Begins with a Trustworthy Supply Chain

AI systems do not consist solely of model files.

There are data sources.

Training environments are used.

Model registry systems operate.

Pipelines carry out automated operations.

Container infrastructures run the models.

API services deliver model outputs to applications.

And all of these components are updated over time.

It must be known which data a model was trained with.

The origin of the model files used must be verified.

Artifact integrity must be preserved.

Pipeline access must be restricted.

Model registry security must be ensured.

Deployment processes must be controlled.

Model behaviour must be monitored.

And it must be possible to respond to security incidents.

The Secure MLOps approach aims to integrate these controls into the model lifecycle.

In enterprise AI projects in particular, supply chain security is an important part of sustainable model reliability.

**Secure AI is not merely about choosing the right model; it is about bringing the right model into the production environment from trusted sources, through controlled processes and with verified components.**