Scope - What This Guide Covers
This guide addresses the governance gap between AI model acquisition and your existing software supply chain controls. You'll find requirement mappings, implementation steps, and a decision framework for teams pulling models from public registries.
In scope:
- AI models sourced from public registries (Hugging Face, GitHub, PyPI)
- Pre-trained models integrated into applications
- AI development tools and dependencies
- Governance controls for model provenance and validation
Not covered:
- Training your own models from scratch
- ML infrastructure security
- General dependency management
Key Concepts and Definitions
AI Model Governance: The policies, processes, and technical controls that verify model provenance, assess risk, and enforce approval workflows before deployment.
Public Registry: An open repository where anyone can publish models or packages. In 2025, 11.7 million new packages entered software supply chains—a 67% increase from the previous year. Your attack surface grows with every pull.
Certified Governance: A documented framework with defined roles, approval gates, and audit trails. Despite claims of governance, 53% of organizations are pulling AI models straight from public registries without additional controls.
Model Provenance: The verifiable history of a model's origin, training data sources, and modification chain. If you can't trace it, you can't trust it.
Requirements Breakdown
ISO 27001 Mappings
Annex A 8.30 - Outsourced Development: When you pull a model from a public registry, you're outsourcing development. Your controls must include:
- Supplier assessment
- Security requirements in acquisition
- Verification of deliverables
Annex A 5.23 - Information Security for Use of Cloud Services: Public registries are cloud services. Document your:
- Data classification for models
- Access controls
- Monitoring requirements
NIST Cybersecurity Framework v2.0
ID.AM-2 (Inventory): Your asset inventory must include AI models. Track:
- Model name and version
- Source registry and publisher
- Integration points in your applications
- Last validation date
ID.RA-1 (Risk Assessment): Assess model-specific risks:
- Poisoned training data
- Backdoored weights
- License violations
- Unmaintained dependencies
PR.DS-6 (Integrity Checking): Verify model integrity at acquisition and before each deployment. Hash verification alone is insufficient—you need behavioral validation.
SOC 2 Type II Controls
CC6.6 - Logical and Physical Access Controls: Your model acquisition process needs the same rigor as your code deployment pipeline:
- Approval workflows for new models
- Role-based access to model registries
- Audit logs for model downloads and deployments
CC7.2 - System Monitoring: Monitor model behavior post-deployment. Drift in model outputs can indicate tampering or poisoning.
Implementation Guidance
Step 1: Inventory Your Current State
Run this audit across your teams:
- Which public registries do you access?
- How many models have you deployed in the last six months?
- Who approved each model acquisition?
- What validation did you perform before deployment?
If you can't answer these questions in under an hour, you have a governance gap.
Step 2: Define Model Acceptance Criteria
Create a decision matrix. Before any model enters your environment, verify:
Provenance checks:
- Publisher identity and reputation
- Model card completeness
- Signature verification where available
- License compatibility with your use case
Security validation:
- Scan model files for embedded malware
- Review model dependencies for known vulnerabilities
- Test model behavior against expected outputs
- Check for data exfiltration attempts during inference
Compliance verification:
- Data residency requirements
- Privacy controls in training data
- Regulatory constraints (GDPR, CCPA, industry-specific)
Step 3: Build Approval Workflows
Your model acquisition pipeline should mirror your code review process:
- Request phase: Developer submits model with justification and risk assessment
- Security review: AppSec team validates provenance and scans for threats
- Compliance review: Legal/compliance confirms licensing and regulatory fit
- Approval: Designated authority approves or rejects with documented reasoning
- Monitoring: Track model in production with behavioral baselines
Use your existing ticketing system. Don't build new tooling until you've proven the process works manually.
Step 4: Establish Registry Controls
Not all registries are equal. Categorize them:
Tier 1 - Pre-approved: Registries with strong publisher verification and security controls. Streamlined approval process but still requires validation.
Tier 2 - Conditional: Public registries with basic controls. Full approval workflow required.
Tier 3 - Prohibited: Registries with no publisher verification or known compromise history. Block at the network level.
Document this in your acceptable use policy. Make it searchable.
Common Pitfalls
Pitfall 1: Treating models like static artifacts Models aren't binaries. They can behave differently based on inputs, and their dependencies update independently. Your validation can't be one-time—schedule quarterly re-assessments for production models.
Pitfall 2: Assuming the model card is accurate Model cards are self-reported documentation. Verify claims independently. If a card says "trained on public data," confirm no proprietary or PII leaked into training sets.
Pitfall 3: Skipping behavioral testing Hash verification proves the file hasn't changed. It doesn't prove the file does what you expect. Test model outputs against known-good baselines before deployment.
Pitfall 4: Ignoring the dependency tree A model might be clean, but its 47 transitive dependencies might not be. Run SCA scans on the full dependency graph, not just the model file.
Pitfall 5: Governance theater Having a policy document doesn't mean you have governance. If 53% of your model pulls bypass the approval workflow, your controls are documentation, not protection.
Quick Reference Table
| Decision Point | Yes Path | No Path | Escalation |
|---|---|---|---|
| Is the model from a Tier 1 registry? | Proceed to security scan | Full approval workflow required | Security architect |
| Does the model have a complete model card? | Continue validation | Request from publisher or reject | Product owner |
| Are all dependencies CVE-free? | Proceed to behavioral testing | Remediate or find alternative | AppSec team |
| Does the model pass behavioral validation? | Submit for compliance review | Document failure and reject | Security architect |
| Is licensing compatible? | Approve for deployment | Legal review or reject | Legal counsel |
| Is monitoring configured? | Deploy | Configure monitoring first | DevOps lead |
Validation frequency:
- Pre-deployment: Always
- Production models: Quarterly
- After dependency updates: Within 48 hours
- After registry compromise: Immediate re-validation
Audit trail requirements:
- Model request with justification
- Security scan results
- Behavioral test outputs
- Approval chain with timestamps
- Deployment logs with model version
Your governance framework is only as strong as your ability to answer: "Which models are running in production right now, and when did we last validate them?" If that takes more than five minutes, start there.
