Supply chain
Software dependencies, container images, model artifacts, datasets, prompts, agent configurations, and external services are verified separately under AI-SUPPLY1 to AI-SUPPLY6 and AI-DATA-CHECK1. Verifying one category does not confirm the security of another.
Third-party datasets
Third-party dataset provenance and integrity are verified
Requirement ID: AI-SUPPLY1
Scope
This requirement applies to a dataset or RAG corpus from an external author, provider, or public source.
Requirement
The source, author, or provider, date of receipt, version, terms of use, and checksum of the received object must be recorded before use. If the author publishes a signature or checksum through an independent trusted channel, it must be verified before unpacking and transformation. If independent verification is unavailable, a self-generated checksum must not be used as a substitute; source risk and the decision to accept the object must be recorded separately.
The provider record additionally contains contact details and the exact version of the accepted internal object; an isolated identity is used for downloading and importing through the preparation path. The production system only uses the accepted internal copy, not an externally hosted mutable URL.
Implementation
The received object first goes to an acceptance area that is inaccessible to production training and search. After verification, the object's immutable ID gets associated with the AI-DATA1 record.
Check
Retrieve or select the saved source object again, calculate its checksum, and compare it with the acceptance record and, if available, the author's publication. A modified object or an object without the required approval must not proceed to the next stage. A checksum mismatch sends the batch to quarantine; if the check fails, derived objects, such as the index or model, are isolated as well.
Artifact
- Acceptance record.
- Repeated retrieval and checksum comparison.
- Source and internal hashes.
- Quarantine test.
Third-party dataset content goes through an intake check
Requirement ID: AI-DATA-CHECK1
Scope
The requirement applies to any external, custom, or otherwise untrusted dataset prior to training, fine-tuning, evaluation, or publication in a RAG system.
Requirement
For a specific data type, the owner must define automated and manual checks: expected size and number of objects, field formats and types, mandatory metadata, sensitive data categories, structural anomalies, duplicates and outliers, source consistency, control and hidden characters, unexpected executable objects, and signs of injected instructions. The verification result is linked to the precise ID or checksum of the input version and the versions of the applied validators.
For a multi-modal set, hidden content is additionally checked if the selected analyzer is capable of detecting it; lack of this capability is flagged as a blind spot rather than a successful check.
Implementation
An object containing a parsing error, an unknown type, or a prohibited field, or exceeding an approved threshold, is not automatically published. It is rejected or quarantined, with the reason, owner, and manual review decision recorded. The statistical anomaly threshold and manual sampling amount are defined by a specific scenario's policy. DSPM can scan supported storage but does not transform data or prove its absence; guardrails do not scan the corpus outside the request flow.
Check
- Submit a valid set and a synthetic set containing an incorrect amount, missing metadata, an incompatible type, sensitive field, control or hidden character, and a corrupted object.
- Verify the link between the report and the specific input version, automated resolution, reason entry, quarantine status, and manual resolution where applicable.
No rejected item should appear in the published version. Lack of the rejected object is also confirmed in the index; in the event of a failure, the derived indexes are rebuilt.
Artifact
- Test error set.
- Link between the report and the input version.
- Validator versions.
- Confirmation of the object's absence from the index.
Third-party models
Third-party model format, loader, and behavior are checked prior to admission
Requirement ID: AI-SUPPLY2
Scope
The requirement applies to the model, weights, tokenizer, or ingestion code received outside the approved internal pipeline.
Requirement
The model package must be associated with the source you are checking and the checksums. For access to the production network, secrets, and data, the serialization format, accompanying code, custom loader, and dependencies are checked. The first run is made in an isolated environment using AI-MODEL2. It is preferred to use a format that does not require you to run random code during the ingestion; however, the format name alone does not guarantee security.
Implementation
Static file check and dynamic execution answer different questions. The scope of behavioral tests, test inputs, and admissibility criteria are defined by the risk owner. The standard does not imply that the cloud scanner is able to analyze weights or hidden behavior.
Check
Map the package against the source and checksums, repeat the ingestion in an isolated environment, and monitor the file, process, and network actions. A mismatch, unexpected execution, or external write attempt will block admission until a separate decision is made. After the check, the initial ingestion environment gets deleted.
Artifact
- Package with the source.
- Action monitoring during ingestion.
- Configuration of the initial check environment.
Third-party model goes through a formal acceptance procedure
Requirement ID: AI-SUPPLY3
Scope
This requirement applies prior to the initial production deployment of any third-party model package and after its major modification.
Requirement
The procedure must include a request explaining how you plan to use the model, a check on the source and license terms, integrity check, format and loader analysis, isolated run, results of approved behavioral tests, admission decision, and and a record of the exact version number. The requesting party cannot approve their own package if the organization policy mandates an independent review. The approval is bound to the exact hash of the acceptance package; the deployment control must only accept approved model packages.
Implementation
The acceptance record must be linked to AI-MODEL1, while the production release, to AI-REL1. Reusing a previous approval decision for a different version is not allowed.
Manual check
- Select a running third-party model and restore the associated request, approved package, results, decision, and registry entry.
- Replace the test checksum or version: the old decision must reject the new package.
A missing or outdated acceptance package must also be rejected.
Artifact
- Acceptance record.
- Checksum spoofing test.
- Acceptance package and its hash.
- Confirmation or exclusion.
Software component vulnerabilities
Dependency and container image vulnerabilities are managed
Requirement ID: AI-SUPPLY4
Requirement
The organization must maintain a registry of software dependencies and images, obtain vulnerability information, determine the remediation timeframe with respect to the risk, and must not release a component that violates the approved criterion. An exception must name the specific version and the compensating measure. Scanning covers the dependencies of the application and the model loader; the finds are linked to the release manifest. If there is no container, an N/A result is acceptable for the image branch, but the dependency branch remains applicable.
Implementation
Container Registry can scan Docker images manually, on upload, or on a schedule; the scope and results are described in the scanner docs and the scanning guide. The scanner does not analyze model weights, model behavior, the RAG corpus, or the external service.
Check
- Compare the production image digest and dependency versions against latest scan results.
- Check test find processing and the impossibility to release a version that violates the approved criterion.
You can roll back to a previously accepted digest only after its vulnerabilities are checked.
Artifact
- Image digest.
- Latest scan results.
- Release test.
- Dependency report.
- Redeployment event.
Reproducible release composition
The composition of software and AI components of the release is known
Requirement ID: AI-SUPPLY5
Requirement
For each release, a reproducible list must be preserved that covers its software dependencies, images, model, adapters and tokenizer, configuration, prompts, applied guardrails and model instance, tools and MCPs, external provider, and data sources or index.
For the software component, we recommend to generate an SBOM in a standard machine-readable format. A separate manifest may be required for the model and data, as a software SBOM does not describe their meaning and provenance.
If the pipeline generates an SBOM, signature, or attestation, a reference to it is provided, but this is not referred to as native Yandex Cloud control.
Implementation
Documented Container Registry functions include storage and distribution of Docker images and vulnerability scanning. These results in themselves do not constitute a complete SBOM or release attestation. The organization selects a specific tool for generation and verification and links the result to the release digest.
Check
Reconstruct the contents of the working version from the saved manifest and compare the checksums against the actual objects. An unspecified component or a floating version means that the release is non-reproducible. The check must detect an intentionally omitted or altered component.
Artifact
- Saved manifest.
- Comparison with actual objects.
- Manifest hash.
- Component cards.
Supplier risk change
Change to a component or external service triggers re-assessment
Requirement ID: AI-SUPPLY6
Requirement
The owner must identify official channels and public sources for provider security notifications. They must monitor and act on alerts regarding compromises, critical vulnerabilities, revocations, terms-of-service updates, or unavailability of a model, data, library, image, or external API. This procedure must enable you to pinpoint affected releases, restrict usage, replace a component, and repeat relevant checks.
Implementation
For an external service, updates to the API, model, processing region, retention terms, and telemetry must be tracked. Yandex Cloud does not manage permissions and lifecycles for external providers unless a specific integration is explicitly documented. Security Deck and YCDR only process incoming signals within a configured environment and do not replace provider monitoring.
Manual check
Take a test notification about a revoked version and trace the response: search of affected systems, restriction decision, replacement, and repeating the check. The registry must allow you to do this by the exact version, not just the product name. Simulating an update to a version, notification, or endpoint should trigger a new check and prevent silent production drift. The system must never run an unknown version without notice.
Artifact
- Test notification.
- Search for systems.
- Restriction decision.
- Affected release manifests.
- Ticket.