airom - Open-source AI Bill of Materials (AIBOM) scanner:

项目说明

AIROM

The AI bill of materials that shows its work.

AIROM is an open-source AI Bill of Materials (AIBOM) scanner that discovers AI
components across the software supply chain and records the e behind its
findings. Point it at a filesystem, git repository, container image, or Kubernetes
workload and it returns the models, prompts, datasets, embeddings, databases,
frameworks, and serving infrastructure your software actually uses — each entry
carrying the file:line it was seen at.

![CI]()
![Release]()
![Go Report Card]()
![Go Reference]()

| | |
|---|---|
| Who it's for | De who need to know what AI is in their stack, security engineers who have to e it, and platform teams standardising AI asset in across repositories |
| What it discovers | 8 AI asset categories, represented by 13 component kinds — see the mapping |
| How you run it | One static binary. pip install airom && airom scan . |
| What you get | CycloneDX, SPDX, SARIF, OpenVEX, native JSON, YAML, a terminal table, and a compliance view |

---

Quick start

One static binary. No runtime, no daemon, no account, no network call unless an
o needs one.

More ways to install and run: installation ·
quickstart · CLI reference

Common commands

---

A real scan

E below is produced by the current binary against
internal/e2e/testdata/fixtures/python-langchain-rag,
a fixture in this repository. Nothing here is illustrative.

Ten components across eight kinds, from fi. The four non-AI dependencies in
that requirements.txt — requests, numpy, pydantic, python-dotenv — are
absent, because an AIBOM is not an SBOM.

The same finding as CycloneDX

One component from bom.json, :

This is generated directly by AIROM. E connects the in entry back to
where it was discovered. The document is CycloneDX 1.6 and against the
published bom-1.6.schema.json with no errors.

Note what travels with the component beyond its name: the detection confidence, the
exact kind (CycloneDX's machine-learning-model type is coarser than AIROM's
hosted-llm), and the generation parameters bound to the call site that set them.

---

The e model

Sooner or later someone asks: *"Your AIBOM says this service uses gpt-4.1. Why?
Where?"*

AIROM is built so that question always has an answer. Every component carries:

| | |
|---|---|
| Occurrences | The file:line where it was seen, with the surrounding snippet and enclosing symbol. Emitted as CycloneDX e.occurrences[]. |
| Technique | Which detector fired, and by what method — manifest analysis, AST walk, binary header parse, filename heuristic. |
| Confidence | An e score in [0,1], with the arithmetic behind it recorded rather than asserted. It is not an empirically calibrated probability, and the output says so. |
| Identity claims | When two sources disagree about a , both are kept as competing CycloneDX e.identity[] entries rather than one being silently dropped. |

It is equally deliberate about what it does not know. A it could not
resol empty instead of being guessed at; a model outside the lifecycle
catalog carries no claim rather than a quiet "supported"; and every scan emits an
assurance account stating what it could not prove — files excluded, reads
truncated at the size cap, which o actually ran.

Full detail: e model ·
confidence

---

What AIROM discovers

The 8 categories and 13 component kinds

AIROM organizes its detections into **8 high-level AI asset categories, represented
by 13 component kinds**. The categories are how the in is described; the
kinds are what the tool emits. Every component carries exactly one kind, in the
kind field of native JSON and the airom:kind property of CycloneDX.

| High-le | Component kinds |
|---|---|
| Models | hosted-llm, local-model-file |
| Datasets | dataset |
| Prompts | prompt |
| Embeddings | embedding-model |
| databases | |
| RAG pipelines | rag-pipeline |
| Frameworks & SDKs | framework, library |
| Infrastructure | infra, service, ai-config |

The thirteenth kind, application, is the scan root itself rather than a discovered
AI asset: it is always present, anchors the relationship graph, and belongs to no
category. Definitions of each kind, with examples, are in
what an AIBOM is.

What that looks like in practice

| | |
|---|---|
| Hosted models | OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI, Cohere, Mistral, Groq. Model IDs and SDK call sites, including OpenAI's non-text lines (DALL·E, Sora, Whisper, moderation, computer-use) |
| Local weights | GGUF, safetensors, ONNX, PyTorch, Sa, TFLite, HDF5, TensorRT. Identified by magic bytes and header parse, and ne or run |
| Frameworks | LangChain, LlamaIndex, CrewAI, Agno, AutoGen, Semantic Kernel, CAMEL, MetaGPT, Letta, Crawl4AI, FastMCP, Transformers, and more |
| Local inference & training | vLLM, llama.cpp, GPT4All, Ollama, DeepSpeed, Unsloth |
| databases | Chroma, Milvus, Qdrant, Pinecone, Weaviate, FAISS, Redis, pg. Includes SQL schemas and a ser pg install |
| Prompts & datasets | Prompt files and templates, CS/Parquet signatures, load_dataset(), HF and Kaggle references |
| E else | Generation parameters bound to their call site, serving infrastructure, and RAG pipelines stitched into one component |

Dependencies are read from manifests, lockfiles, installed metadata, and even
PyInstaller binaries, so a frozen app with no source on disk still produces an
in.

Languages with rule-targetable region lexers: Python · Ja · TypeScript ·
Go · Java · Rust · C# · Kotlin · SQL

---

Scan targets

| Target | Command | Notes |
|---|---|---|
| Directory tree | airom fs ./app or airom scan . | The default |
| Git repository | airom repo <url> | Remote URL is shallow-cloned; a local path is read as a worktree |
| Container image | airom image --input app.tar | An archive or OCI layout. Li and daemon pulls are not implemented |
| Kubernetes | airom k8s --manifests ./deploy | Offline manifest enumeration. Li scanning is not implemented |

airom scan auto-detects which of these you meant from the argument's shape.

Details: filesystem ·
repository ·
container images ·
Kubernetes

---

Output formats

Eight formats, all projected from one scan. Native JSON is the lossless reference;
every other format is a pure projection of it.

| Format | Flag | What it's for |
|---|---|---|
| Native JSON | -o json | The lossless superset. Every other format projects from this. |
| CycloneDX 1.6 / 1.7 | -o cyclonedx | The ML-BOM, with e.occurrences[] and e.identity[] populated |
| SPDX 3.0.1 | -o spdx | A JSON-LD graph with the AI, Dataset, Software, and Security profiles |
| SARIF 2.1.0 | -o sarif | Code scanning alerts, for GitHub and any SARIF consumer |
| OpenVEX | -o vex | A over the C |
| Compliance | -o compliance | NIST AI RMF and OWASP Agentic control mapping |
| YAML | -o yaml | Native JSON, in YAML |
| Table | -o table | The terminal view (default) |

A note on SPDX: it is the lossiest format AIROM emits, because SPDX 3.0.1 has no slot
for file:line e. The document says so explicitly rather than letting a reader
mistake the silence for absence.

Details: output formats ·
CycloneDX ·
SARIF ·
field mapping

---

Beyond in

| Feature | What it does |
|---|---|
| Risk detection | Load-time code-execution surfaces: pickle imports, Keras Lambda layers, GGUF template gadgets, and unsafe torch.load. Emitted as CycloneDX [] and SARIF. Offline. |
| C | Your AI dependencies against OSV.dev, with real C and a fail-closed gate. On by default; --no-cve turns it off. |
| One-click fixes | --fix opens the ad table with a Fix action per package and rewrites the manifest pin you click. Declared manifests only — a lockfile is reported, ne. --fix- then dry-runs the ecosystem's resolver, so a bump that clears eight CVEs and leaves a manifest nothing can install is caught here, not in your next build. |
| Model lifecycle | Hosted models matched against a dated, sourced catalog of provider retirement announcements. |
| Compliance mapping | NIST AI RMF and OWASP Agentic controls as CycloneDX attestations, marked met, gap, or manual, with no in scores. |
| | An Open over the C. Only e affected, because a scanner has no basis for an all-clear. |
| AIBOM diff | The semantic delta between two scans, so AI becomes a per-PR control. |
| Test scope | Fixtures and test trees are recorded but kept out of the default view. |
| Signed rule updates | New frameworks reach you without a new binary, over an ed25519- channel. |

---

CI/CD

Findings land as GitHub Code Scanning alerts on the pull request that introduced them.

Findings are not failures by default: a completed scan exits 0 no matter what it
found, and --exit-code / --fail-on are the opt-in gate. Exit 2 is reserved for a
fatal error.

See exit codes ·
GitHub Actions ·
exit code reference

---

Security model

AIROM is a security tool whose parsers eat untrusted bytes, and is built accordingly:

No model execution, ever. Weights are identified by magic bytes and bounded

header parsing. Nothing is loaded, deserialized, or run. A pickle's opcode stream is
read to enumerate its imports; it is ne.

Fuzzed parsers. Every binary header parser is fuzzed in CI and must return

errors, ne.

No surprise network access. --offline asserts it globally. The C is

the only component that needs the network, and it refuses under --offline rather
than reporting a quiet nothing.

Bounded reads. Files are read under a size cap, and anything truncated is

declared in the assurance account rather than silently partially scanned.

Signed releases. CGO_ENABLED=0, reproducible, checksummed, and

keyless-cosign-signed, with a checksums.txt co every platform.

Signed rule updates. The rule-update channel an ed25519 signature and a

SHA-256 tarball digest, and accepts only strictly newer bundles.

Report pri via a GitHub security ad. See
SECURITY.md.

---

Extending it

Model IDs churn weekly, so the fast-moving surface lives in YAML rule packs rather
than Go. Adding a provider is a rules PR, not a release:

One YAML file, two fixtures, one golden. For detections needing a real parser,
implement FileDetector against the stdlib-only pkg/airom/detect SDK.

Rules are merged by rule ID — add, o, or disable — across layers: packs
embedded in the binary, then a fetched signed bundle, then any --rules o. A
bundle that does not carry a pack therefore ne that pack's detection. A
fourth layer, an OCI-distributed registry, is planned for v2 and not implemented.

See writing rules ·
plugin guide ·
rule packs

---

Architecture

A single static Go binary. One streaming pass — **walk → classify → dispatch
detectors → collect — then cross-file project detectors, then assemble →
enrich → write**.

Detectors are isolated and accounted for indi; one failing detector

degrades to an unknowns record rather than failing the scan.

The assembler merges findings by a canonical key, keeps-and-relates rather than

o, and refuses to assert a relationship it cannot substantiate.

Writers are pure projections — func(*airom.In) []byte. No writer

invents, drops, or re-derives data, and a round-trip test turns any disagreement
with docs/mapping.md into a CI failure rather than docs drift.

E is retained through detection and assembly, so in entries can be

traced back to source occurrences and carried into every output format that has a
slot for them.

Read docs/ARCHITECTURE.md for the full design and the
decision log, including the alternatives each decision rejected.

---

Documentation

| | |
|---|---|
| Getting started | installation · quickstart |
| Concepts | what an AIBOM is · e · confidence · |
| Scan targets | filesystem · repository · container images · Kubernetes |
| Output formats | o · CycloneDX · SARIF · field mapping |
| Security | risk detection · C · model lifecycle · SECURITY.md |
| CI/CD | GitHub Actions · exit codes · compliance mapping |
| Rule packs | rule schema · o · writing rules · signed updates |
| Detector de | plugin guide · pkg/airom API |
| Reference | CLI · configuration · schemas |
| Project | architecture · status · roadmap · releasing |

The documentation site and the landing page are built from
airomhq/airom-web.

---

Project status

v0.4.7, early but real. The pipeline, detectors, writers, and o are
implemented and tested; expect rough edges.

Known gaps, each also surfaced in the affected flag's --help:

Caching is not implemented (--no-cache is a no-op).

Li and daemon image pulls are not a — use

airom image --input <archive>.

Li Kubernetes scanning is not a — use

airom k8s --manifests <dir>.

The full ledger of what is complete and what is deferred is in
docs/project-status.md.

Contributing

Start with CONTRIBUTING.md. The fastest way to help is a rule pack.
Most pro land in under an hour.

License

Apache License 2.0. © AIROM contributors

项目信息

开发语言：Go

Star 数：16

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Open-source AI Bill of Materials (AIBOM) scanner: inventories AI models, datasets, prompts, embeddings, vector DBs & RAG pipelines across code, containers & Kubernetes — with file:line evidence, load-time risk detection (poisoned pickle / Keras Lambda / unsafe torch.load) and NIST AI RMF / OWASP compliance mapping. CycloneDX · SARIF · JSON.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。