feat(C4): add unsafe deserialization prohibition for model artifacts (4.5.10)

[RicoKomenda]

Summary

Adds 4.5.10 to C4.5 (AI Workload Sandboxing & Validation) to address one of the most commonly exploited attack vectors against AI systems: arbitrary code execution via unsafe model artifact deserialization.

New control:

Verify that model artifact loading prohibits or restricts serialization formats that permit arbitrary code execution at deserialization time (e.g., Python pickle with unrestricted globals), and that model files are scanned using format-aware tools before loading in any environment.

Level: 1

Why this is needed

Python's pickle format, widely used for serializing PyTorch model checkpoints, executes arbitrary Python code at load time. A malicious model file with a crafted pickle payload achieves remote code execution on any system that loads it -- no exploit required beyond torch.load(malicious_file). This has been demonstrated in multiple CVEs and is one of the most common supply chain attacks against ML systems. Hugging Face and PyTorch both document this as a known risk and recommend SafeTensors as a safe alternative.

No existing AISVS control addresses this. C4.5.1 requires external models to run in sandboxes, but that is post-load isolation -- the code execution happens during load(), before the sandbox has any effect. C6.1.2 requires scanning for malicious layers, but generic malware scanners do not parse pickle opcodes. A format-aware scan (e.g., picklescan, ModelScan) is specifically required.

Level 1 is appropriate: this is a prerequisite security control. Unsafe deserialization is the #1 documented model supply chain attack and is verifiable through tooling available today.

Changes

• 1.0/en/0x10-C04-Infrastructure.md: add 4.5.10, fix MD060 separator rows and spacing on 4.5.1/4.5.2
• 1.0/en/0x93-Appendix-D_AI_Security_Controls_Inventory.md: add entry to AD.12