AI Control Library / CF-08: Testing & Robustness
Designation: Core | Control types represented: Operational and Technical
Control requirement
Identify and assess vulnerabilities in AI software dependencies and libraries using a current component inventory, appropriate scanning and deployment-specific triage. Track findings through verified treatment.
Why this matters
AI packages depend on parsers, runtimes, containers and ordinary libraries as well as model files. A scan result needs interpretation: an affected package may be exploitable, unreachable or outside the scanned scope.
How the control types work together
Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.
When it applies
AI build and runtime dependencies, images, notebooks, plugins and supporting services within the assessed boundary.
Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.
Ownership
The vulnerability-management owner operates scanning; component and system owners establish exposure and remediation.
Implementation guidance
- Reconcile dependency and version information from builds, runtime images and service records, including transitive packages.
- Scan with suitable tools and current advisory data, recording unsupported components and coverage limits.
- Triage findings against actual deployment, configuration and exposure, using credible evidence rather than dismissing untested paths.
- Remediate, isolate or replace affected components and rescan or retest the deployed result.
How to verify it
Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.
| Test | Expected result |
|---|---|
| Inspect a live dependency | Its relevant version and scan coverage are recorded. |
| Trace a material advisory | Exposure analysis and accountable treatment occur. |
| Review a fixed finding | The corrected component is deployed and relevant exploit conditions are retested. |
Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.
Evidence to retain
- Component inventory and scope
- Scan and advisory records
- Exposure and treatment decisions
- Deployment and retest evidence
Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.
If the control fails
Escalate exploitable material weaknesses or scan coverage gaps to security and service owners. Apply proportionate containment while approved remediation proceeds.
Example in practice
Hypothetical example: A vulnerable tokenizer library is present in a serving image. The team verifies the active loading path, patches the image and confirms deployed instances rather than closing the issue when a repository file changes.
Related controls
- CF03-013: AI Service Bill of Materials (AI-BOM)
- CF08-012: AI Vulnerability Remediation
- CF03-017: AI Model Artifact Scanning
Framework mappings
- CSA AICM (TVM-05)
- NIST AI RMF (MEASURE 2.5)
- MITRE ATLAS
Review and maintenance
Review at the interval approved by the control owner and after relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.
Version 1.0