SBOMs in AI-native software: what security teams are missing

TL;DR: SBOMs still improve software transparency, but Codenotary argues they no longer capture the full risk picture for AI-native systems because data provenance, model lineage, inference exposure, and ownership metadata now shape governance, compliance, and incident response. AI supply chain control has to move beyond code inventories to living operational inventories.

Editorial analysis by NHI Mgmt Group, based on content published by Codenotary: “SBOMs in the Age of AI”.

Key questions

Q: How should security teams govern AI systems when SBOMs only cover code artifacts?

A: Treat SBOMs as the starting point, not the control model.

Q: Why is data lineage so important for AI governance?

A: Because AI outputs inherit risk from the data that feeds them.

Q: What are the signs that an AI inventory is too shallow to support security decisions?

A: A shallow inventory usually stops at packages and code repositories.

Practitioner guidance

• Define AI inventory scope beyond code Include datasets, model versions, inference endpoints, integrations, and downstream consumers in the asset register so the inventory reflects production reality.
• Record dataset provenance and approval status Capture source, licensing terms, classification, regulated-data flags, and approval evidence for every dataset used in training or inference pipelines.
• Track model lineage as a controlled asset Maintain base model origin, fine-tuning history, version identifiers, and update history so outputs can be traced back to a specific lineage.

Bottom line: AI-native systems broaden the control surface beyond source code, so SBOM-only governance misses material security and compliance dependencies.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →