CISA Expands AI SBOM Guidance to Cover Models, Data and Runtime Behavior

Context The U.S. Cybersecurity and Infrastructure Security Agency (CISA) teamed with cyber agencies from the G7 to address the growing opacity of AI systems. Traditional SBOMs list software components and licenses; the new guidance adds layers specific to AI, such as model lineage, fine‑tuning history, vector databases and orchestration logic. The document is advisory, not mandatory, but reflects a consensus among leading experts and is expected to evolve as AI technology matures.

Key Facts - The minimum elements require vendors to document models, datasets, software dependencies, licensing, and third‑party APIs. - AI risk now hinges on more than code: model weights, training data provenance, prompt handling, GPU dependencies and runtime behavior all shape outcomes. - Analysts warn that an SBOM shows what a vendor *claims* is inside a system, not whether those claims are accurate or sufficient for a given deployment. - Security leaders can use the guidance in procurement, demanding evidence of model provenance, data source legality, update cycles and monitoring controls. Larger suppliers must reveal third‑party foundation model use, geographic data flows and whether customer data is retained for future training. Start‑ups should be vetted on governance maturity, identity controls and operational monitoring. - For high‑risk AI deployments, the SBOM should be part of a broader evidence pack that includes data‑flow diagrams, security architecture, privacy impact assessments, red‑team findings and prompt‑injection testing.

What It Means Enterprises now have a concrete checklist to press AI vendors for transparency, moving AI risk assessment into the same vendor‑risk conversations that already govern software and cloud services. The guidance forces a shift from asking “what code is inside this product?” to asking “what code, model, data, infrastructure and vendor decisions shape its behavior?”

Mitigations – What Defenders Should Do 1. Integrate the AI SBOM checklist into existing vendor‑risk workflows; require it before onboarding any AI‑enabled product. 2. Verify disclosed components against runtime inventories using tools that can scan model files, container images and API calls. 3. Demand evidence of data‑source legality and provenance, such as data‑use agreements or audit logs. 4. Establish continuous monitoring for model drift and unexpected outputs; log prompts and responses to detect hallucinations or prompt‑injection attacks. 5. Align AI SBOM reviews with existing security standards (e.g., NIST AI RMF) and map disclosed elements to MITRE ATT&CK techniques like “Model Poisoning” (T1485) or “Data Manipulation” (T1565). 6. For critical deployments, conduct independent red‑team exercises that test model behavior under adversarial prompts and verify that runtime controls match SBOM claims.

Looking Ahead Watch for the first industry‑wide AI SBOM submissions and for regulatory bodies that may turn the advisory checklist into enforceable requirements.