Skip to content

Back to the catalog

Orca Security: AI-BOM
orca.securityarticle

Orca Security: AI-BOM

Orca Security explains what an AI-BOM is (an inventory of models, datasets, prompts, embeddings, and external AI services an AI system depends on) and why discovery — not format — is the hard problem: components arrive via notebooks and managed consoles rather than dependency manifests. It surveys the two competing standards, CycloneDX's ML-BOM (v1.7, standardized as ECMA-424 2nd edition) and SPDX 3.0's AI/Dataset profiles, walks through failure modes like unrecoverable model lineage, stale embeddings outliving deleted source documents, and silent version drift on managed endpoints (e.g. Azure OpenAI's auto-update-to-default), and ties the practice to EU AI Act Annex IV technical-documentation requirements and the NIST AI RMF. It ends by describing Orca's agentless SideScanning-based AI inventory across Azure OpenAI, AWS Bedrock, SageMaker, and Vertex AI.

TL;DR Orca's field guide to AI-BOM: why discovery (not schema) is the hard problem, how CycloneDX and SPDX cover it, and what EU AI Act Annex IV demands.
Open original ↗
Document

What it is

Orca's AI-BOM explainer. The catalog summary captures the core argument (discovery, not format, is the hard problem) and the standards landscape. What it omits are the concrete procedure for discovery, the version/date boundaries, and the regulatory deadlines — those are below.

Discovery methodology

The page states a specific enumeration approach, ordered because recording fields on an incomplete list is wasted effort:

  1. Cloud control plane — provider APIs for Bedrock, SageMaker, Azure OpenAI, Vertex AI list endpoints and jobs per account.
  2. Billing data — catches accounts nobody onboarded.
  3. Package manifests and container images — reveal AI libraries in workloads.
  4. Code repository scanning — finds API keys pointing at services no inventory lists.

The stated principle: do not start from a voluntary registry. Voluntary registration finds only what teams already know about. Placing enumeration with a team that can query the whole estate removes the dependency on data scientists adopting build-time SBOM tooling.

Version and regulatory boundaries the summary omits

  • CycloneDX: ML-BOM arrived in v1.5 (June 2023); v1.7 shipped October 2025, standardized as ECMA-424 2nd edition (December 2025).
  • SPDX: 2.2.1 is ISO/IEC 5962:2021; 3.0 released April 2024 but still a draft revision in ISO, so the current spec and the published ISO standard are not the same document.
  • Azure OpenAI auto-update: a deployment tracking the default moves within two weeks of a default-version change. Pinning a version makes the entry meaningful and hands upgrade work back to the team.
  • EU AI Act deadlines: high-risk systems (biometrics, critical infrastructure, employment, border control) apply from 2 December 2027; high-risk systems embedded in regulated products from 2 August 2028.

Also noted

  • OWASP AIBOM Generator emits a CycloneDX AI BOM from a model on a public hub (open-source option).
  • An AI-BOM does not replace a model card — link entries to their cards; maintain both.

Organisations named here

  • ECMA-424
  • ISO/IEC 5962:2021

Technologies named here

  • Azure OpenAI
  • Orca
  • PyTorch
  • CycloneDX
  • SPDX
  • TensorFlow
  • scikit-learn
  • OWASP AIBOM Generator
  • Amazon Bedrock
  • Amazon SageMaker
  • Google Vertex AI
  • Hugging Face
  • OpenAI
  • SBOM
  • AWS Bedrock
  • EU AI Act
  • NIST AI RMF

Techniques named here

  • AI-BOM / AI bill of materials
  • Cloud control plane enumeration
  • Billing data review
  • Package manifest and container image scanning
  • Code repository scanning
  • Agentless SideScanning
  • Event-triggered BOM regeneration

Related in AI Security