on
Stop shipping AI blind: bring Model BOMs into your DevSecOps pipeline
If your app now includes a model, you’re not just “deploying code” anymore—you’re releasing a band plus the album, liner notes, and a stack of instruments. Yet many CI/CD pipelines still ship AI features without basic liner notes for the model itself: where it came from, what data it learned from, how it was evaluated, and which knobs were turned along the way. That’s a problem.
Two trends make this urgent:
- Real incidents in the AI supply chain. In May 2024, Hugging Face disclosed unauthorized access affecting Spaces secrets, prompting token revocations and hardening moves. If your pipeline pulled models or ran apps that relied on those secrets, could you prove what was impacted? A model bill of materials (BOM) makes that traceable. (huggingface.co)
- Standards are catching up. CycloneDX 1.6 (now an Ecma International standard) added first-class support for AI/ML artifacts and formulation data, so you can represent models, datasets, and the steps that “manufactured” them—and attest to it. Vendors are already adopting these xBOM capabilities. (cyclonedx.org)
This piece is a practical guide to using CycloneDX ML‑BOM and MBOM inside DevSecOps, and how to pair that with AI-powered remediation (like GitHub Copilot Autofix) without sacrificing control.
The short version: what is a Model BOM?
CycloneDX’s ML‑BOM extends the familiar SBOM concept to AI systems. You inventory:
- Models (type, architecture family, parameters)
- Datasets (provenance, versions)
- Training/evaluation details and metrics
- Operational dependencies and services
It also introduces modelCard fields so you can embed transparent, auditable facts (e.g., task, architecture, datasets, metrics). In CycloneDX 1.6, “machine-learning-model” and “data” are first-class component types, and modelCard is part of the schema. (cyclonedx.org)
Separately, CycloneDX MBOM captures how something was “manufactured” (declared recipe vs. observed run), which is perfect for training pipelines: workflows, tasks, steps, and parameters become reproducible artifacts rather than tribal knowledge. (cyclonedx.org)
Why this matters for security:
- OWASP’s Top 10 for LLM Applications flags supply chain and data poisoning risks; ML‑BOM gives you the inventory you need to mitigate and monitor them. (owasp.org)
- Government guidance now emphasizes secure deployment of AI systems and the integrity of their data, including provenance and controls across the AI lifecycle. (cisa.gov)
A minimal ML‑BOM snippet
Here’s a tiny, illustrative JSON fragment you can attach to a release artifact. It declares one model plus a dataset it references. The names/fields follow CycloneDX 1.6 terminology (abbreviated for readability):
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:2d3b5a9b-1c25-4e9c-a9a2-6e3f99d00111",
"components": [
{
"type": "machine-learning-model",
"name": "incident-summarizer",
"version": "2.3.1",
"modelCard": {
"modelParameters": {
"task": "text-summarization",
"architectureFamily": "transformer",
"modelArchitecture": "Llama-3.1-8B",
"datasets": [{ "ref": "urn:uuid:dataset-2024Q4" }]
},
"quantitativeAnalysis": {
"performanceMetrics": [
{ "type": "ROUGE-L", "value": "0.42" }
]
}
}
},
{
"type": "data",
"bom-ref": "urn:uuid:dataset-2024Q4",
"name": "internal-incidents-2024Q4",
"properties": [{ "name": "provenance", "value": "curated" }]
}
]
}
CycloneDX defines the machine-learning-model and data component types as well as the modelCard structure; you’re not inventing a one-off schema. (cyclonedx.org)
Tip: You can generate ML‑BOM JSON with your own scripts or use helper tooling (for documentation, not generation) like mlbomdoc to produce human-readable docs for reviews. (pypi.org)
Where ML‑BOM fits in your DevSecOps loop
Think “SBOM, but for models,” and wire it into the same gates:
- Build/train
- Emit an ML‑BOM at the end of training and at fine-tuning time.
- Record model hash, parameters, datasets (with versions and licenses), and eval metrics.
- Capture an MBOM of the training workflow (declared recipe) plus observed steps. (cyclonedx.org)
- Package
- Bundle the ML‑BOM alongside your container or model artifact.
- Add CycloneDX Attestations (CDXA) so you can prove this info is authentic and policy-compliant. (cyclonedx.org)
- Verify/deploy
- Gate deployments unless the artifact includes a signed ML‑BOM and MBOM.
- Store BOMs in your artifact registry; index them for search and incident response.
If you already manage SBOMs, this will feel familiar—CycloneDX 1.6 was ratified as ECMA‑424 specifically to serve as a cross-domain xBOM standard (software, hardware, services, cryptography, and AI/ML). (cyclonedx.org)
“Found means fixed” meets “provenance or it doesn’t ship”
AI-powered autofix is here—and useful—if you keep humans in the loop. GitHub Copilot Autofix is generally available, covers major languages for CodeQL alerts, and is free for public repos; you can disable it if you prefer a slower rollout. Pair it with automated tests and code review. (github.blog)
Other platforms now propose fixes too (for example, GitLab Duo’s vulnerability explanations and one‑click merge requests; and Snyk’s AI‑powered Agent Fix). These tools accelerate remediation, but don’t replace governance or threat modeling—especially for model-centric apps. (about.gitlab.com)
Pragmatic stance: let AI suggest, let CI validate, and let ML‑BOM/MBOM prove what you’re actually shipping.
A starter runbook (incremental and boring-on-purpose)
1) Inventory your AI assets
- Treat models, datasets, prompts, vector stores, and plugins as assets—CISA’s deployment guidance emphasizes asset management and mitigations for AI systems. ML‑BOM lets you enumerate them, not just “the code.” (cisa.gov)
2) Generate ML‑BOM at training time
- Add a job at the end of fine‑tuning or training that writes model metadata (name, version, hashes), parameters, dataset references, and key metrics into CycloneDX JSON.
3) Capture formulation (MBOM)
- Declare the training workflow (container image digests, scripts, hyperparameters). When runs complete, write the observed steps and outputs. This is essential for reproducibility and incident forensics. (cyclonedx.org)
4) Sign and attest
- Use CycloneDX Attestations (CDXA) to assert who built the model, with what inputs, and how it was evaluated. Store signatures with your artifacts. (cyclonedx.org)
5) Gate on policy
- CI should block a release if:
- modelCard is missing required fields (task, datasets, metrics),
- datasets lack provenance or license info,
- eval thresholds aren’t met (e.g., fairness slice or accuracy floor).
- This maps neatly to NIST SSDF-style “define, implement, verify” controls for software producers. (csrc.nist.gov)
6) Wire in autofix—and tests
- Enable Copilot Autofix for CodeQL alerts to keep code defects from masking model issues; ensure unit/integration tests run before accepting changes. For public repos, the feature is free; orgs can toggle it off if needed. (github.blog)
7) Monitor for supply chain drift
- When a source like Hugging Face reports a security event, search your BOM index for affected tokens/models/spaces and trigger revocation or retraining if necessary. (huggingface.co)
A thin GitHub Actions example
This shows the spirit, not a full implementation:
name: build-train-package
on: [push]
jobs:
ml_pipeline:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Train model
run: python train.py --config configs/train.yaml --out artifacts/
- name: Generate ML-BOM
run: |
python scripts/build_mlbom.py \
--model artifacts/model.bin \
--datasets data/registry.json \
--metrics artifacts/metrics.json \
--out artifacts/ml-bom.json
- name: Add MBOM (formulation)
run: python scripts/build_mbom.py --workflow .github/workflows/train.yml --out artifacts/mbom.json
- name: Attach attestations
run: python scripts/sign_boms.py artifacts/*.json
- name: CodeQL scan + Copilot Autofix comments
uses: github/codeql-action/init@v3
with:
languages: javascript,python,java
# Code scanning runs; Copilot Autofix suggestions will appear on PRs if enabled
- name: Policy gate
run: python scripts/policy_check.py --bom artifacts/ml-bom.json --mbom artifacts/mbom.json
Behind the scenes, your build_mlbom.py simply writes CycloneDX-conformant JSON and includes modelCard fields; policy_check.py enforces your “no modelCard, no ship” rule. (cyclonedx.org)
Governance anchors you can point to
- OWASP Top 10 for LLM Applications (v1.1) calls out Prompt Injection, Insecure Output Handling, Supply Chain, and Data Poisoning—risks your BOMs and gates should explicitly address. (owasp.org)
- CISA/NSA/FBI and international partners published deployment guidance for externally developed AI systems; pair that with CISA’s AI Data Security note to justify provenance controls and data integrity requirements. (cisa.gov)
- CycloneDX 1.6 became ECMA‑424, making xBOM a true multi-domain standard (software, services, cryptography, and AI/ML). That gives you air cover when you ask teams to treat model metadata like release-critical code. (cyclonedx.org)
Common snags (and how to dodge them)
- Stale or incomplete BOMs
- Automate creation inside training jobs; don’t make it a manual checklist.
- “But we don’t know our dataset’s provenance”
- Start with high-value fields and add depth over sprints. Even a ref to a data artifact with a hash is better than silence.
- Over-trusting autofix
- Enable it to reduce toil, but never bypass tests or code review. Treat AI suggestions as junior developer PRs—useful, but accountable to your standards. (github.blog)
- Tool sprawl
- Prefer standards-based artifacts (CycloneDX). Vendors like ReversingLabs are beginning to consume and analyze ML‑BOM/CBOM across commercial apps, which future-proofs your investment. (reversinglabs.com)
The payoff
When the next AI supply chain wobble hits—an upstream token leak, a tainted dataset, a model backdoor—you’ll be able to answer simple but high-stakes questions fast:
- Which releases include that model?
- Which datasets trained it?
- What metrics did we accept at the time?
- Who signed off on it?
That’s the difference between pausing a service for hours versus minutes. Bring ML‑BOM and MBOM into your DevSecOps loop, sign them, and gate on them. Then let AI help you fix the code while you keep your hands firmly on the wheel.
Further reading and tools:
- CycloneDX ML‑BOM and MBOM capabilities; CycloneDX 1.6 release and attestations; ECMA‑424 ratification. (cyclonedx.org)
- OWASP Top 10 for LLM Applications (v1.1). (owasp.org)
- CISA: Deploying AI Systems Securely; AI Data Security (May 22, 2025). (cisa.gov)
- GitHub Copilot Autofix GA + availability. (github.blog)
- Hugging Face Spaces incident (May 31, 2024). (huggingface.co)
Ship AI with liner notes. Your future self—and your incident commander—will thank you.