# Deep-Dive SDD-B07 — Agent SBOM and Supply Chain Assessment

**Course**: 2B — Securing & Attacking Harnesses and LLMs
**Deep-Dive**: SDD-B07 · **Duration**: 45 minutes · **Level**: Senior Engineer and above
**Prerequisites**: Course 2B B0–B2; B4 (Trust Surfaces); SDD-B01–SDD-B06

> *An agent is not a program. It is a dependency graph with a model at the center. Every tool it can call, every MCP server it connects to, every checkpoint it loads, and every corpus that shaped that checkpoint is a trust dependency. The Software Bill of Materials was built to enumerate the components in a compiled binary. The AI Bill of Materials extends it to enumerate the components in an agent — and the agent's supply chain is its attack surface. This deep-dive covers the SBOM-to-AI-BOM extension, the standards that carry it (CycloneDX, SPDX), how to generate and validate one, and why a missing MCP server entry in the BOM is the same class of finding as a transitive npm dependency nobody audited.*

---

## Learning Objectives

After completing this deep-dive, you will be able to:

1. Explain the SBOM-to-AI-BOM extension: an SBOM enumerates the components in a compiled binary; an AI BOM additionally enumerates the model, the training data sources, the tools and MCP servers, and the harness dependencies — because each is a trust dependency an attacker can reach.
2. Map an agent's supply chain to its attack surface: every tool, every MCP server, every model dependency, and every training-data source is a node in a trust graph, and each node is a vector for the injection, exfiltration, and governance-bypass attacks of B1–B5 and SDD-B04–SDD-B06.
3. Apply the assessment tools and methodologies: CycloneDX (ML/AI and crypto-material extensions), SPDX (AI/SAI profiles), and the generation and validation workflows that produce and check an AI BOM.
4. Generate an AI BOM for a representative agent: enumerate the model components, the data components, the tool/MCP components, and the software dependencies.
5. Validate an AI BOM against a runtime snapshot: detect undeclared tools, unregistered MCP servers, model-version drift, and the missing entries that represent un-assessed attack surface — and tie each finding to B4's trust-surface map.
6. Articulate where AI BOMs intersect B11's governance material: an AI BOM is the machine-checkable inventory that governance, procurement, and incident response all depend on.

---

## Why this deep-dive exists

B4 established the trust surfaces of an agent — the model, the tools, the memory, the retrieval store, the identity layer, the sandbox, the inter-agent edges. B11 established the governance layer that owns them. Neither provided the concrete *inventory practice*: how do you enumerate, in a machine-checkable artifact, every component of a deployed agent, so governance can govern it, procurement can vet it, a red-team can scope it, and incident response can answer "what was in the blast radius?"

That artifact is the AI Bill of Materials — the direct extension of the SBOM that software supply-chain security (SLSA, the NTIA minimum elements, Executive Order 14028) made baseline for compiled software. The SBOM exists because you cannot defend a dependency you do not know about. The log4j incident was a failure of inventory, not patching: the organizations that did not know they shipped log4j could not patch it. The AI BOM exists for the same reason — you cannot govern an MCP server you do not know your agent calls, cannot assess a checkpoint you do not know it loads, cannot scope an engagement against a supply chain you have not enumerated.

This deep-dive makes B4's trust surfaces and B11's governance obligations operable. The connection to SDD-B04–SDD-B06 is direct: every component in the AI BOM is a node an attacker targets, and an undeclared component is an un-assessed node — the agent equivalent of an unknown transitive dependency.

Three sub-sections, fifteen minutes each:

- **B07.1 — The SBOM-to-AI-BOM Extension.** What an SBOM is, what an AI BOM adds (model, data, tools, MCP servers, harness), and why every component is a trust dependency.
- **B07.2 — Standards, Generation, and Validation.** CycloneDX (ML/AI and crypto-material extensions), SPDX (AI/SAI profiles), the NTIA minimum elements, and the tooling that produces and checks an AI BOM.
- **B07.3 — Supply-Chain Assessment in an Engagement.** The AI BOM as the scope input, the undeclared-component finding, model-version drift, and the bridge to B4 and B11.

---

# B07.1 — The SBOM-to-AI-BOM Extension

*What a software bill of materials enumerates, what an AI bill of materials adds, and why every added component is a trust dependency.*

## The Software Bill of Materials, briefly

A Software Bill of Materials is a formal, machine-readable inventory of the components in a piece of software. It records, at minimum (per the NTIA minimum elements): the component name, version, supplier, a unique identifier, the dependency relationship, and a cryptographic hash. Its value is negative — it lets you answer the question you could not answer before: "do we ship a component with a known vulnerability?" The log4j lesson is that the answer is often "yes, and we did not know."

SBOMs are generated by build tooling (Syft, CycloneDX plugins for Maven/Gradle/npm, `spdx-tools`), exchanged in standard formats (CycloneDX JSON/XML, SPDX), and consumed by vulnerability databases (NVD, OSV, GitHub Advisory). US federal requirements (Executive Order 14028, M-22-18, OMB guidance) made SBOMs a procurement condition for software sold to the government. The practice is now baseline for any mature software supply chain.

The SBOM's unit of analysis is the compiled or packaged artifact: a container image, a binary, a package. It enumerates software dependencies. It does not — and was never designed to — enumerate a model, a training corpus, or a tool server. That is the gap the AI BOM fills.

## What the AI BOM adds

An agent is a runtime composition of a model, a set of tools, a set of external server connections, a retrieval store, a memory, and a harness that orchestrates them. Each is a component the deployer did not write and cannot fully audit — a trust dependency. The AI BOM extends the SBOM to enumerate them. At minimum, it adds:

- **Model components.** The base model (architecture, parameter count, checkpoint hash, supplier), fine-tune adapters (LoRA weights, provenance), quantization scheme, inference runtime (vLLM, llama.cpp, TGI), and the model's own BOM if the provider publishes one. A frontier API model is recorded by provider, model id, and pinned version.
- **Data components.** Training data sources (corpora, datasets, provenance, licensing), evaluation sets, and retrieval-store contents the agent grounds on. For a provider model, this is the provider's published training-data disclosure; for a fine-tune, the fine-tune dataset. Data is a component because it shapes behavior — a data-poisoning finding (B1) is a supply-chain finding.
- **Tool and MCP components.** Every function-call tool the agent exposes (name, description, backing implementation, supplier), and every MCP server it connects to (identity, transport, tools exposed, supplier). This maps directly to B4's trust surfaces: each tool and each MCP server is a trust-surface node.
- **Harness and orchestration components.** The agent framework (version, supplier), the harness libraries, the sandbox implementation, the orchestration code. For an agent, the harness is the governance layer (B0, SDD-B04, SDD-B05), so its version and provenance are security-critical, not just maintenance-critical.

The load-bearing insight: **every component in the AI BOM is a trust dependency an attacker can reach.** The model is reachable via the prompt channel (prompt injection, SDD-B03). The tools are reachable via tool-call manipulation. The MCP servers are reachable via the agent's outbound connections and via the servers' own attack surface (a compromised MCP server is an indirect-injection source). The training data is reachable retroactively via data-poisoning. A component not in the BOM is a surface not assessed.

## The trust graph: the agent's supply chain is its attack surface

B4's central claim was that an agent's trust surfaces — the model, the tools, the memory, the retrieval store, the identity layer, the sandbox, the inter-agent edges — are the attack surface. The AI BOM is the inventory of those surfaces, and the supply chain is the graph connecting them. Every node is a component; every edge is a trust relationship (the agent trusts the tool's output, the model trusts retrieved context, the harness trusts the MCP server's response).

This reframes supply-chain security for agents. The traditional software question is "is any of our dependencies vulnerable?" (a CVE lookup against the SBOM). The agent question is broader: "can any of our components be reached and manipulated, and is every component declared and assessed?" The first is a vulnerability scan; the second is a trust-graph assessment. The AI BOM is the input to both, but the trust-graph assessment is the one that matters — because the attack is not always a CVE in a dependency; it is often a perfectly-functional MCP server that returns attacker-influenced content the agent then trusts.

---

# B07.2 — Standards, Generation, and Validation

*The formats, the extensions, and the tooling that produce and check an AI BOM.*

## CycloneDX and the ML/AI extension

CycloneDX (OWASP) is one of the two dominant SBOM formats. It is a JSON/XML specification for supply-chain composition analysis, extended specifically for AI and ML components. The CycloneDX ML-BOM (machine-learning bill of materials) and broader AI-BOM profile add component types the core SBOM does not carry: model components (`type: "machine-learning-model"`), dataset components (`type: "data"`), and the relationships between them (trained-on, fine-tuned-from, depends-on).

The CycloneDX fields that matter for an agent AI BOM: **`bom-ref`** (a unique reference per component, used to express the dependency graph); **`components[].type`** (extended beyond software types to include `machine-learning-model` and `data`); **`components[].properties`** (name-value pairs for architecture, parameter count, checkpoint hash, quantization, model-card reference, training-data references); **`externalReferences`** (links to the model card, data card, security disclosure, signing attestation); and **`crypto-metadata`** (the crypto-material extension, CDX 1.6, for the agent's keys and attestation materials — part of the supply chain, per B0's credential surface).

CycloneDX is generated by tooling (Syft for container/image scanning, `cdxgen` for multi-ecosystem generation, build-tool plugins) and consumed by vulnerability and policy tooling (Dependency-Track, OWASP DepCheck). For an agent, the model and tool components are added to the software components the build tooling already produces.

## SPDX and the AI/SAI profiles

SPDX (the Linux Foundation's Software Package Data Exchange) is the other dominant SBOM format — an ISO standard (ISO/IEC 5962:2021), extended for AI through the SPDX AI profile and the System Package Bill of Materials for AI (the "SAI" work, addressing the NTIA AI BOM working group's elements). SPDX's model is a document with packages, files, and snippets, each with a license, supplier, checksum, and relationships. The AI profile adds the AI "package" carrying model-specific fields: purpose, hyperparameters, training-data references, evaluation metrics, and energy-consumption profile (a governance disclosure some regimes are beginning to require).

For a deployer choosing between CycloneDX and SPDX: CycloneDX is more common in build-and-pipeline tooling (the format most generation tools emit natively); SPDX is more common in governance, licensing, and standards-compliance contexts (its ISO standardization matters for some procurement regimes). Many toolchains emit both. The choice is less important than the practice: have an AI BOM, in a standard format, with the model/data/tool components declared.

## The NTIA AI BOM minimum elements

The NTIA published a working-group output defining the minimum elements of an AI BOM, paralleling its earlier minimum-elements-for-SBOM work. These are the floor, not the ceiling — an AI BOM omitting any is incomplete in a way that matters for assessment. The core set:

- **Model identity.** Name, version, supplier, checksum/hash, model-card reference.
- **Model architecture and parameters.** Architecture (transformer, diffusion), parameter count, input/output modalities.
- **Training data.** Sources (named datasets, corpora), provenance, licensing, a data card or equivalent. For a fine-tune, the base-model reference and the fine-tune dataset.
- **Evaluation.** The evaluation sets, the metrics, the results — so a consumer can assess whether the model was evaluated for the behaviors that matter (safety, fairness, robustness).
- **Software and runtime.** The inference runtime, the harness, the orchestration code — the traditional SBOM components, integrated.

A deployer who cannot produce an AI BOM meeting these elements cannot answer the first question a regulator (EU AI Act documentation duties), a procurement officer, or a red-team (what is in scope?) will ask. The AI BOM is the inventory that makes the agent legible to the governance and security processes that must assess it.

## Generating and validating an AI BOM

Generation has two parts: the software-component part (automated by existing SBOM tooling) and the AI-component part (the model, the data, the tools, the MCP servers). The software part is solved; the AI part is semi-manual today, and is where most AI BOMs are incomplete. The AI components are generated from: the agent's configuration (the model id, the tool list, the MCP server registry), the model supplier's published model card and training disclosure, and the fine-tune records. A mature deployment automates this — the agent's config-as-code is the source of truth, and the AI BOM is generated from it in CI, the same way a container image's SBOM is generated from the Dockerfile.

Validation is the assessment. Given an AI BOM, the checks are:

1. **Completeness.** Does the BOM declare every tool, every MCP server, every model? An undeclared component is an un-assessed surface — the agent equivalent of an unknown transitive dependency. Validation compares the BOM against the runtime configuration and flags the delta.
2. **Version pinning and drift.** Is the model version pinned (a specific checkpoint, not a floating alias)? Are the tools pinned to audited versions? Drift between the BOM and the runtime is a finding — the assessed agent is not the deployed agent.
3. **Provenance and signing.** Are the components attested (SLSA build provenance, Sigstore signatures, the supplier's published checksum)? An un-attested checkpoint is a supply-chain risk of the same class as an un-signed binary.
4. **Vulnerability and policy check.** Do any components have known vulnerabilities (CVEs in the harness libraries, disclosed issues in an MCP server, a revoked checkpoint)? Do any violate the deployer's policy (a tool from an un-approved supplier, a model trained on a disallowed data source)?

Validation is continuous, not one-time. A production agent that updates its model, adds a tool, or connects to a new MCP server changes its AI BOM. The CI pipeline regenerates the BOM, validation runs against it, and a drift or undeclared component gates the deployment. This is the agent-specific realization of SLSA's continuous-verification principle.

---

# B07.3 — Supply-Chain Assessment in an Engagement

*The AI BOM as the scope input, the undeclared-component finding, and the bridge to B4 and B11.*

## The AI BOM as the engagement scope input

In a B12-style engagement, the first question the red-team asks the deployer is: "what is in your agent?" The answer is the AI BOM. Without it, the engagement scopes against a black box — the red-team does not know what tools to test, what MCP servers to assess, what model version is deployed, or what the trust-graph edges are. If the deployer cannot produce an AI BOM, that is itself the first finding: a deployer who cannot enumerate their agent's components cannot govern them (B11), cannot assess blast radius in an incident (B0), and cannot answer the procurement and regulatory questions that increasingly require it. The red-team's first deliverable is often to *build* the AI BOM from the runtime configuration — reverse-engineering the inventory the deployer should have had. This is the agent equivalent of running Syft against a container the vendor shipped without an SBOM.

With the AI BOM in hand, the engagement scopes against its components: the tools are the function-call attack surface (SDD-B04), the MCP servers are the indirect-injection and compromise surface (SDD-B03), the model version is the refusal-layer target (SDD-B06), the retrieval store is the data-leak surface, and the harness libraries are the traditional vulnerability surface. The AI BOM maps directly to B4's trust surfaces — it populates the trust-surface map.

## The undeclared-component finding

The highest-value supply-chain finding is the undeclared component: a tool, MCP server, model version, or data source the agent uses at runtime but the AI BOM does not declare. This is the agent equivalent of the unknown transitive dependency that made log4j damaging — the component is there, it is reachable, and nobody assessed it.

The undeclared component is found by comparing the AI BOM against the runtime. The methods:

- **Runtime configuration diff.** Start the agent in a sandbox and log every tool it registers, every MCP server it connects to, every model it loads. Diff against the BOM. The delta is the undeclared components.
- **Network-observation diff.** Observe the agent's outbound connections (MCP servers, model endpoints, tool backends). Compare against the BOM's declared external references. An undeclared MCP server is a connection the BOM does not explain.
- **Behavioral inference.** For a black-box target where the runtime is not observable, infer the components from behavior: prompt the agent to enumerate its own tools (a recon technique from SDD-B06), observe which external services it calls, infer the model from its outputs. Noisier, but produces findings when the deployer's BOM and the runtime diverge.

Each undeclared component is a finding with severity proportional to its reachability. An undeclared MCP server the agent connects to on every turn is critical — it is an indirect-injection source (SDD-B03) that governance does not know about and the red-team did not scope. An undeclared tool with limited invocation is lower-severity, but it is still a gap governance must close.

## Model-version drift

A common undeclared-component variant: model-version drift. The AI BOM declares model version N (pinned, with a checkpoint hash). At runtime, the agent calls version N+1 (the provider rotated the checkpoint, or the deployer's alias resolved to a newer version, or the deployer updated without regenerating the BOM). The assessed agent is not the deployed agent.

This matters because the model version is the single most important reproducibility field (B0, SDD-B06). A finding against version N may not reproduce against N+1 — and N+1 may have new vulnerabilities N did not. The control is version pinning (the config pins a specific checkpoint, not a floating alias) combined with drift detection in validation (the BOM's declared version is compared against the runtime's resolved version, and a mismatch gates the deployment).

## Feeding B4's trust-surface map and B11's governance inventory

The AI BOM is the bridge between B4 (the trust surfaces) and B11 (the governance). B4's trust-surface map is populated by the AI BOM's components: each tool, MCP server, model, and data source is a node in the trust graph. B11's governance inventory is the AI BOM plus ownership and policy metadata: who owns each component, what policy governs it, when it was last assessed. The AI BOM is the shared inventory that makes both modules operable.

For incident response (B0's reporting duties, B11's governance), the AI BOM is the blast-radius input: when an incident occurs, the first question is "what components were in the affected agent?" and the answer is the AI BOM (validated against runtime). A deployer who cannot answer — because they have no AI BOM, or because it has drifted — cannot scope the incident, cannot report it accurately, and cannot determine which of their other agents share the vulnerable component.

---

## Anti-Patterns

### Treating the AI BOM as a software SBOM plus a model name
"It's just an SBOM with the model name appended." Cure: the AI BOM enumerates the model, the training data, every tool, every MCP server, the fine-tune adapters, the quantization, and the runtime. A BOM that declares the model name and omits the tool and MCP components has missed the parts of the supply chain that are the attack surface. The tools and servers are the reachable, manipulable components — the load-bearing entries.

### An AI BOM that does not match the runtime
"We have a BOM; it was generated at build time." Cure: a BOM that has drifted from the runtime is worse than no BOM — it gives false confidence. The validation step compares the BOM against the runtime configuration (resolved model version, registered tools, connected MCP servers) and the delta is a finding. Regenerate in CI; validate on every deploy.

### Omitting the MCP servers and external tool backends
"The agent's tools are internal; we don't need to declare the MCP servers." Cure: every MCP server is a trust dependency and an indirect-injection source (SDD-B03). An undeclared MCP server is an un-assessed node in the trust graph. The AI BOM must declare every server the agent connects to, with identity, transport, supplier, and the tools it exposes.

### A floating model alias instead of a pinned checkpoint
"The agent uses the provider's `latest` alias; that's our version." Cure: a floating alias resolves to different checkpoints over time (providers rotate silently). The AI BOM must pin the specific checkpoint (with a hash or dated version id), and validation must detect drift between the pinned version and the runtime-resolved version. Model-version drift means the assessed agent is not the deployed agent.

### No provenance or signing on the model and tool components
"The model came from a reputable provider; we trust it." Cure: trust is not a supply-chain control; provenance is. The AI BOM should carry attestation (SLSA build provenance for the harness, the supplier's published checksum for the model, signing for the tool backends). An un-attested component is a supply-chain risk of the same class as an un-signed binary — and a compromised model-distribution channel is a scaling attack.

### Running an engagement without an AI BOM as scope input
"We'll scope it from the system prompt and the visible tools." Cure: the AI BOM is the scope input. Without it, the engagement is testing an unknown surface — the undeclared MCP server, the drifted model version, the un-audited tool backend are all out of scope by default. Build or obtain the AI BOM first; scope against its components.

---

## Key Terms

| Term | Definition |
| --- | --- |
| **SBOM (Software Bill of Materials)** | A formal, machine-readable inventory of software components (name, version, supplier, identifier, dependency, hash); the NTIA minimum elements and EO 14028 baseline |
| **AI BOM (AI Bill of Materials)** | The SBOM extended to enumerate the model, training data sources, tools, MCP servers, and harness — because every component is a trust dependency |
| **CycloneDX** | OWASP SBOM format; extended with the ML-BOM / AI-BOM profile (model and data component types) and the crypto-material extension (CDX 1.6) |
| **SPDX** | Linux Foundation SBOM format (ISO/IEC 5962); extended with the AI profile and the System Package Bill of Materials for AI (SAI) |
| **NTIA AI BOM minimum elements** | The floor element set: model identity, architecture and parameters, training data, evaluation, and the software/runtime components |
| **Trust graph** | The agent's supply chain as a graph: components are nodes, trust relationships are edges; every node is a reachable attack target |
| **Undeclared component** | A tool, MCP server, model version, or data source the agent uses at runtime but the BOM does not declare; the agent equivalent of an unknown transitive dependency |
| **Model-version drift** | The runtime-resolved model version differs from the BOM-declared version; the assessed agent is not the deployed agent |
| **SLSA** | Supply-chain Levels for Software Artifacts — the build-provenance framework; applied to agent components, it provides the attestation the AI BOM should carry |
| **crypto-metadata (CycloneDX CDX 1.6)** | The crypto-material extension carrying the agent's keys, attestation materials, and signing state |

---

## Lab Exercise

See `07-lab-spec.md`. The lab has you generate an AI BOM (CycloneDX JSON) for a representative agent from its configuration, validate it against a runtime snapshot (detecting undeclared tools and MCP servers and model-version drift), produce an undeclared-component finding report, and map the BOM's components to B4's trust surfaces. Python 3.10+ with type hints; no GPU; the agent config and runtime snapshot are fixtures so the lab runs deterministically offline.

---

## References

1. **NTIA — Minimum Elements for an AI Bill of Materials** — the working-group output defining the floor element set; the direct parallel to the NTIA SBOM minimum elements.
2. **OWASP CycloneDX** — the SBOM specification and its ML/AI and crypto-material extensions (CDX 1.6). `cyclonedx.org`.
3. **SPDX (ISO/IEC 5962:2021)** — the Linux Foundation SBOM standard and its AI/SAI profiles. `spdx.dev`.
4. **Course 2B B4 — Trust Surfaces** — the trust-surface map the AI BOM populates; every tool, MCP server, model, and data source is a node.
5. **Course 2B B11 — Governance** — the governance inventory the AI BOM feeds; ownership, policy, and assessment metadata over the component inventory.
6. **Course 2B B0 — Legal & Ethics** — the incident-reporting duties (EU AI Act, US EO/OMB) that require knowing the agent's components; the blast-radius input.
7. **Course 2B SDD-B03 — InjecAgent** — the indirect-injection measurement; the MCP servers and tools in the AI BOM are the indirect-injection sources.
8. **Course 2B SDD-B06 — RedAgent** — the model-version field as the single most important reproducibility record; model-version drift is the BOM-runtime divergence.
9. **Executive Order 14028** — the US SBOM procurement requirement; the policy baseline the AI BOM extends.
10. **SLSA (Supply-chain Levels for Software Artifacts)** — the build-provenance framework; the attestation the AI BOM components should carry. `slsa.dev`.
11. **Syft, cdxgen, Dependency-Track** — representative generation and consumption tooling for SBOM/AI-BOM workflows.
12. **OWASP Agentic AI Top 10 (2026)** — the supply-chain attack surface (tool/MCP compromise, model tampering) maps to the trust-graph nodes the AI BOM enumerates.