AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational and Technical
Control requirement
Scan model artifacts and their relevant supporting files before acceptance and deployment, using suitable checks for the formats and threat scenarios involved. Quarantine findings, document coverage limits and repeat assessment when artifacts or scanning capability change materially.
Why this matters
A clean scan is evidence about the checks performed, not proof that a model is safe. Malicious code, vulnerable dependencies, malformed artifacts and harmful learned behavior require different detection and evaluation methods.
How the control types work together
Operational controls define acceptance, responsibility and response. Technical controls verify artifacts, observe actual use or enforce data and action boundaries. The process must cover the same deployment that the technical mechanisms protect.
When it applies
Model archives, checkpoints, adapters, configuration files, tokenizers, supporting code and packaged runtimes entering the AI supply chain.
Tailor review depth to information sensitivity, granted authority and business dependence. Record what the organization can test directly, what relies on provider evidence and how material visibility gaps affect the acceptance decision.
Ownership
The security scanning owner operates the checks; model and platform owners provide complete packages and resolve relevant findings.
Implementation guidance
- Define scanning scope and supported formats, including executable files, dependency vulnerabilities, suspicious serialized content and archive structure as relevant.
- Collect artifacts into a controlled intake area, bind results to exact integrity references and avoid executing untrusted content to inspect it.
- Quarantine suspicious or unsupported artifacts for qualified review; distinguish false positives, incomplete scans and unresolved findings from successful coverage.
- Require release gates and re-scan relevant changed artifacts, while using separate behavioral evaluation for threats the scanner cannot establish.
How to verify it
Use representative deployment records and authorized controlled tests. Establish the assessed service, artifact version and acceptance conditions before interpreting results; do not extend evidence beyond the boundary it covers.
| Test | Expected result |
|---|---|
| Use a harmless test fixture or known benign detection marker | The intended scanner and release gate produce the expected quarantine or finding. |
| Inspect scan coverage | All required package components are checked or explicitly handled through an approved alternative. |
| Modify an artifact after scanning | Earlier results cannot silently authorize the changed bytes. |
Record a finding when a required result cannot be demonstrated or actual practice differs materially from the accepted conditions. Assign corrective action and verify the affected boundary before closing the issue.
Evidence to retain
- Scan policy and tool coverage
- Artifact-specific scan reports
- Quarantine and review decisions
- Release gate and re-scan records
Protect supplier-confidential information, credentials and personal data in these records. Preserve enough version and scope information to establish which service or artifact the evidence supports.
If the control fails
Escalate material detections, unsupported formats or scan bypasses to security and release authorities. Hold affected deployment until evidence supports acceptance or a constrained alternative.
Example in practice
Hypothetical example: A model weight file passes scanning but its repository includes an unreviewed startup script. The package remains blocked until that executable component is assessed; the weight scan is not extended to cover it by implication.
Related controls
- CF03-014: Model Provenance & Integrity Verification
- CF03-016: Secure Model Format & Serialization
- CF13-006: Backdoor Attack Detection & Prevention
Framework mappings
- CSA AICM (MDS-02)
- NIST AI RMF (MAP 1.6)
- EU AI Act (Art. 15(1))
- ISO 42001 (Cl. 8.3)
- MITRE ATLAS
Review and maintenance
Review at the interval approved by the control owner and after relevant supplier, component, contract, access or deployment changes. Reassess material incidents and new evidence, updating acceptance conditions and verifying corrective actions where required.
Back to AI Supply Chain & Third-Party Risk
Version 1.0