{ "module": "SDD-B07 — Agent SBOM and Supply Chain Assessment", "course": "2B — Securing & Attacking Harnesses and LLMs", "version": "1.0.0", "duration_minutes": 30, "total_questions": 15, "bloom_distribution": { "target": "20% recall / 40% application / 40% analysis-design", "actual": { "recall": 3, "application": 6, "analysis": 6 } }, "passing_score_percent": 70, "questions": [ { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "What is the load-bearing insight that distinguishes an AI BOM from 'an SBOM plus a model name'?", "options": [ "An AI BOM uses a different file format than an SBOM.", "Every component in the AI BOM — the model, the training data, every tool, every MCP server, the harness — is a trust dependency an attacker can REACH. A component not in the BOM is a surface not assessed. The AI BOM is the inventory of the agent's entire trust graph, not a software inventory with a model field appended.", "An AI BOM is required by law while an SBOM is optional.", "An AI BOM only covers the model, while an SBOM covers the software." ], "answer_index": 1, "rationale": "The model is reachable via the prompt channel (SDD-B03); the tools via tool-call manipulation; the MCP servers via outbound connections and their own attack surface; the training data retroactively via poisoning. 'An SBOM plus a model name' misses the tool and MCP components that ARE the attack surface — the reachable, manipulable nodes in the trust graph. This is why the AI BOM is the inventory of the trust graph, not a software inventory with a model field." }, { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the four AI-BOM component classes that extend the software SBOM?", "options": [ "Frontend, backend, database, and network components.", "Model components, data components, tool & MCP components, and harness & orchestration components.", "Training, validation, testing, and deployment components.", "Input, processing, output, and storage components." ], "answer_index": 1, "rationale": "Model (base model, checkpoint hash, fine-tune adapters, quantization, inference runtime); Data (training corpora, provenance, licensing, evaluation sets, retrieval store); Tools & MCP (every function-call tool, every MCP server with identity/transport/supplier); Harness & orchestration (agent framework, sandbox, orchestration code — the governance layer, whose version is security-critical). These are the trust dependencies beyond the software SBOM." }, { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What was the log4j lesson that motivates the AI BOM, and how does it apply to agents?", "options": [ "Log4j taught us that all logging libraries are insecure.", "Log4j was a failure of INVENTORY, not patching — organizations that did not know they shipped log4j could not patch it because they did not know they had 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 a red-team against a supply chain you have not enumerated. The undeclared component is the agent equivalent of the unknown transitive dependency.", "Log4j showed that open-source software should never be used in production.", "Log4j proved that SBOMs are unnecessary because vulnerabilities are always patched quickly." ], "answer_index": 1, "rationale": "The undeclared component — a tool/MCP/model the agent uses at runtime but the BOM does not declare — is the agent equivalent of the unknown transitive dependency. The component is there, it is reachable, and nobody assessed it because nobody knew it was there. This is the highest-value supply-chain finding, found by runtime diff, network observation, or behavioral inference." }, { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "Your client's agent calls three MCP servers and exposes five function-call tools. The AI BOM they provide declares the model and the five tools but omits one MCP server. What is the finding and its likely severity?", "options": [ "No finding — MCP servers are internal and do not need to be declared.", "An UNDECLARED COMPONENT finding. The omitted MCP server is an un-assessed node in the trust graph — an indirect-injection source (SDD-B03) that governance does not know about and the red-team did not scope. If the agent contacts it on every turn, severity is CRITICAL; if limited, lower but still a governance gap (B11). It is the agent equivalent of an unknown transitive dependency.", "A formatting error — regenerate the BOM and the issue is resolved.", "A model-version drift finding, because the server was omitted." ], "answer_index": 1, "rationale": "Every MCP server is a trust dependency and an indirect-injection source. The agent trusts the server's responses; a compromised or attacker-influenced server returns content the agent treats as legitimate context. Severity scales with reachability — an undeclared MCP server contacted every turn is critical. The AI BOM must declare every server with identity, transport, supplier, and exposed tools. This maps directly to B4's trust surfaces." }, { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "The AI BOM declares the agent uses model version N (pinned with a checkpoint hash). At runtime, the agent resolves to version N+1 because the provider rotated the checkpoint. What is this, and what is the consequence?", "options": [ "Normal provider behavior — no action needed.", "MODEL-VERSION DRIFT. The assessed agent (version N) is NOT the deployed agent (version N+1). A red-team finding against N may not reproduce against N+1, and N+1 may have new vulnerabilities N did not. The model version is the single most important reproducibility field. Control: pin the specific checkpoint (not a floating alias); detect drift in validation; a mismatch gates the deploy.", "A completeness check failure — the BOM is missing components.", "A provenance failure — the model is un-attested." ], "answer_index": 1, "rationale": "Model-version drift is a common undeclared-component variant. Providers rotate checkpoints silently; floating aliases resolve to newer versions. The control is version pinning (a specific checkpoint, not 'latest') combined with drift detection in the validation step. This connects to SDD-B06 (model version as the single most important reproducibility field) and B0 (incident response requires knowing what version was deployed)." }, { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "You are scoping a red-team engagement. You ask the deployer 'what is in your agent?' and they cannot produce an AI BOM. What is the correct first action?", "options": [ "Decline the engagement — you cannot test without a BOM.", "The ABSENCE of an AI BOM is itself the first finding. The first deliverable is to BUILD the AI BOM from the runtime configuration — sandbox-start the agent, log every tool/MCP/model loaded, and reverse-engineer the inventory the deployer should have had. This is the agent equivalent of running Syft against a container the vendor shipped without an SBOM. Scope the engagement against the generated BOM.", "Proceed scoping from the system prompt and visible tools only.", "Ask the provider for their BOM instead." ], "answer_index": 1, "rationale": "A deployer who cannot enumerate components cannot govern them (B11), cannot assess blast radius (B0), cannot answer procurement/regulatory questions. The red-team builds the BOM from the runtime configuration (runtime config diff is the discovery method). The generated BOM then populates B4's trust-surface map and becomes the scope input. Without it, the engagement tests an unknown surface — undeclared MCP servers and drifted versions are out of scope by default." }, { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "Which two SBOM standards support AI BOMs, and how do they differ in typical use?", "options": [ "SLSA and OSV — SLSA is for generation, OSV is for validation.", "CycloneDX (OWASP) and SPDX (Linux Foundation, ISO/IEC 5962). CycloneDX is more common in build/pipeline tooling (the format most generation tools like Syft/cdxgen emit natively); SPDX is more common in governance/licensing/procurement (its ISO standardization matters there). Both have AI extensions (CycloneDX ML-BOM/AI-BOM profile; SPDX AI profile + SAI). Many toolchains emit both; the choice is less important than the practice.", "NVD and CVE — NVD is the format, CVE is the database.", "Syft and Dependency-Track — Syft generates, Dependency-Track consumes." ], "answer_index": 1, "rationale": "CycloneDX adds 'machine-learning-model' and 'data' component types via its ML-BOM/AI-BOM profile, plus the crypto-material extension (CDX 1.6). SPDX adds AI 'package' fields (purpose, hyperparameters, training-data refs, evaluation metrics) via its AI profile and SAI. They are largely interconvertible through the common core. The choice is less important than having an AI BOM in a standard format with model/data/tool components declared." }, { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "Your CI pipeline regenerates the AI BOM on every deploy and runs validation. The model component has no SLSA attestation or supplier signature. Which validation check flags this, and what is the risk?", "options": [ "The completeness check — the component is undeclared.", "The PROVENANCE & SIGNING check. An un-attested checkpoint is a supply-chain risk of the same class as an un-signed binary. A compromised model-distribution channel is a SCALING attack — every agent loading the poisoned checkpoint inherits the compromise. Trust is not a supply-chain control; provenance is. The BOM declares what SHOULD be there but without attestation cannot verify what IS there.", "The version-drift check — the version is unpinned.", "The vulnerability check — the model has a CVE." ], "answer_index": 1, "rationale": "The four validation checks are completeness, version drift, provenance/signing, and vulnerability/policy. Provenance checks for SLSA build provenance, Sigstore signatures, and the supplier's published checksum. Without attestation, a substituted or poisoned checkpoint at the distribution channel is undetectable — and because every agent loading it inherits the compromise, it is a scaling attack. The AI BOM should carry attestation for the harness, the model, and the tool backends." }, { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "An incident occurs on the deployer's production agent. The first question is 'what components were in the affected agent?' The deployer has an AI BOM but it was generated six months ago and has not been validated since. What are the consequences?", "options": [ "No issue — the BOM is still valid because it was generated at build time.", "The drifted BOM is WORSE than no BOM — it gives false confidence. The deployer cannot accurately scope the incident (the BOM's components may not match the runtime), cannot report accurately to regulators (EU AI Act docs / US EO-OMB per B0), and cannot correlate to find which OTHER agents share the vulnerable component. The AI BOM is the blast-radius input; a stale one means flying blind at exactly the wrong moment.", "They can regenerate the BOM retroactively from logs.", "Only the model component matters for incident response." ], "answer_index": 1, "rationale": "The AI BOM is the blast-radius input for incident response. A BOM that has drifted from the runtime declares components and versions that no longer match — governance governs stale inventory, the red-team scopes against stale surfaces, incident response uses a stale blast-radius. The control: validation is CONTINUOUS (CI regenerates; validation runs on every deploy; a finding gates deployment). The assessed agent must equal the deployed agent." }, { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is a drifted AI BOM (generated at build time, never re-validated) worse than having no AI BOM at all?", "options": [ "It is not — any BOM is better than none.", "A drifted BOM gives FALSE CONFIDENCE. It declares components and versions that no longer match the deployed agent. Governance governs the declared (stale) inventory; the red-team scopes against the declared (incomplete) surfaces; incident response uses the declared BOM as the blast-radius input (which is wrong). No BOM at least makes the gap VISIBLE, prompting the deployer to build one. A drifted BOM hides the gap behind a false sense of completeness.", "A drifted BOM causes legal liability while no BOM does not.", "A drifted BOM is larger and slower to parse." ], "answer_index": 1, "rationale": "The value of the AI BOM is negative — it lets you answer 'do we have a vulnerable component?' A drifted BOM answers that question WRONGLY: it says 'no' when the answer is 'yes, but the BOM does not reflect the current runtime.' The control is continuous validation: CI regenerates the BOM from config-as-code, validation runs against a runtime snapshot on every deploy, and a drift or undeclared component gates the deployment (the SLSA continuous-verification principle)." }, { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "How does the AI BOM serve as the bridge between B4 (Trust Surfaces) and B11 (Governance)? Construct the relationship.", "options": [ "The AI BOM replaces both B4 and B11 with a single inventory.", "B4's trust-surface map is POPULATED by the AI BOM's components — each tool, MCP server, model, and data source is a trust node (tools → function-call surface SDD-B04; MCP → injection surface SDD-B03; model → refusal target SDD-B06; retrieval → data-leak surface). B11's governance inventory is the BOM PLUS ownership/policy metadata (who owns each component, what policy governs it, when last assessed). The AI BOM is the SHARED inventory that makes both modules operable.", "B4 generates the AI BOM and B11 consumes it.", "The AI BOM is independent of both B4 and B11." ], "answer_index": 1, "rationale": "The AI BOM is the shared inventory. B4 uses it to populate the trust-surface map (the attack assessment — which nodes are reachable). B11 uses it as the governance inventory (ownership and policy metadata over the same components). B0 uses it as the blast-radius input for incident response. A component not in the BOM is outside all three processes — which is why an undeclared component is a finding, not a formatting oversight." }, { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "A black-box target's runtime is not directly observable. How do you discover undeclared components, and what are the limitations?", "options": [ "You cannot — undeclared components are only findable with runtime access.", "BEHAVIORAL INFERENCE: prompt the agent to enumerate its own tools (a SDD-B06 context-reconnaissance technique), observe which external services it calls, and infer the model from its outputs. Limitations: noisier than runtime/network diffs; the agent may not faithfully self-report; inference is probabilistic. But it produces findings when the deployer's BOM and the runtime diverge — e.g., the agent calls a service the BOM does not declare.", "Send the deployer a survey and trust their answers.", "Check the provider's documentation for the list of tools." ], "answer_index": 1, "rationale": "For a black-box target, behavioral inference is the method. The recon technique (prompting the agent to enumerate its tools) is borrowed from SDD-B06 — the deployed context, including its undeclared components, is observable through behavior. It is noisier than the runtime config diff or the network-observation diff (which require some access), but it is the method that works when the runtime is not observable. The delta between observed behavior and the declared BOM is the finding." }, { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "Design the AI BOM validation step that runs in CI. What are its inputs, its four checks, and the gate condition?", "options": [ "Inputs: the BOM. Check: is it valid JSON? Gate: block on parse error.", "Inputs: the regenerated AI BOM (CycloneDX JSON from config-as-code) AND a runtime snapshot (resolved model version, registered tools, connected MCP servers). Four checks: (1) COMPLETENESS — diff BOM vs runtime, flag undeclared; (2) VERSION DRIFT — pinned vs resolved model version; (3) PROVENANCE — SLSA attestation / signatures / supplier checksum present; (4) VULN/POLICY — CVEs, un-approved suppliers, disallowed data sources. GATE: any finding blocks the deploy — the assessed agent must equal the deployed agent.", "Inputs: the source code. Check: does it compile? Gate: block on compile error.", "Inputs: the model card. Check: is the license permissive? Gate: block on proprietary licenses." ], "answer_index": 1, "rationale": "Validation is continuous, not one-time. The two inputs (the regenerated BOM and the runtime snapshot) are compared across four checks. Completeness catches undeclared components (the highest-value finding). Version drift catches model-version drift (assessed ≠ deployed). Provenance catches un-attested components (the un-signed-binary class of risk). Vuln/policy catches known issues and policy violations. Any finding gates the deployment — the SLSA continuous-verification principle realized for agents." }, { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does provenance (SLSA attestation, signatures) matter for AI BOM components, and what is the scaling attack it prevents?", "options": [ "Provenance only matters for software, not for models.", "Trust is not a supply-chain control; provenance is. A model checkpoint from 'a reputable provider' could be substituted at the distribution channel. A compromised model-distribution channel is a SCALING attack — every agent loading the poisoned checkpoint inherits the compromise, because the model is at the center of every agent's trust graph. Un-attested tool backends and MCP servers carry the same risk as un-signed binaries. Without attestation, the BOM declares what SHOULD be there but cannot verify what IS there.", "Provenance speeds up model inference.", "Provenance is required only for open-source models." ], "answer_index": 1, "rationale": "The model is the central node of the agent's trust graph — every agent loading a poisoned checkpoint inherits the compromise. This makes a compromised distribution channel a scaling attack, unlike a single-binary compromise. The AI BOM should carry SLSA build provenance for the harness, the supplier's published checksum for the model, and signing for the tool backends. Provenance is the supply-chain control that turns 'we trust the supplier' into 'we can verify the artifact.'" }, { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "A deployer says 'our agent's tools are internal; we don't need to declare the MCP servers in the AI BOM.' Construct the refutation and the correct practice.", "options": [ "Agree — internal tools do not need to be in the BOM.", "Every MCP server is a TRUST DEPENDENCY and an INDIRECT-INJECTION SOURCE (SDD-B03). The agent trusts the server's responses; a compromised or attacker-influenced server returns content the agent treats as legitimate context. An undeclared MCP server is an un-assessed node — governance does not know about it, the red-team did not scope it. This is the same class of error as omitting internal npm dependencies (the log4j lesson). The AI BOM must declare every server with identity, transport, supplier, and the tools it exposes — internal or external.", "Internal MCP servers should be declared only if they have known CVEs.", "MCP servers are declared in the system prompt, not the AI BOM." ], "answer_index": 1, "rationale": "The 'internal' framing misses the point: the MCP server is reachable by the agent and returns content the agent trusts. Whether the server is internal or external does not change that it is a trust dependency and an indirect-injection source. Omitting it from the AI BOM means it is outside governance (B11), outside the red-team scope, and outside the incident-response blast-radius. The log4j lesson applies directly: internal dependencies that nobody declared were exactly the ones that caused the damage." } ] }