Automated SBOM generation for polyglot monorepos

Why Polyglot Monorepos Break Single-SBOM Thinking

A Software Bill of Materials (SBOM) is conceptually simple: a machine-readable list of every component in a piece of software, with versions and licenses. In a single-language repository the SBOM is nearly a byproduct of the package manager — npm sbom, pip-audit, go mod graph — and the conversation moves on.

A polyglot monorepo in 2026 is a different problem. A representative Series-C engineering stack contains Go microservices, a Node or TypeScript frontend, a Python machine-learning subsystem, a Rust data pipeline, Java for a legacy integration, and platform tooling written in anything from shell to Terraform to Bazel. Each ecosystem has its own SBOM tooling, its own dependency resolution semantics, its own vulnerability database, and its own conventions for what counts as a “component.” Stitching these into a single, accurate, auditable SBOM is now a dedicated workstream — not a side effect.

This post is the 2026 playbook for automated SBOM generation across polyglot monorepos: format selection, per-service and aggregate manifests, the pipeline that keeps the SBOM continuous, SLSA attestations, VEX, and the customer-facing workflow that enterprise procurement has begun to require.

CycloneDX vs. SPDX in 2026

Two formats dominate in 2026: CycloneDX (OWASP, now at 1.6) and SPDX (Linux Foundation, now at 3.0). The wrong choice in 2022 was to pick one and regret it; the right choice in 2026 is to emit both, because the consumers have diverged.

CycloneDX 1.6 is the preferred format for security use cases. The format is denser for vulnerability data (VEX integration is first-class), works better with OWASP tooling (Dependency-Track being the obvious reference), and most security scanners emit it natively. Enterprise security teams in 2026 default to CycloneDX.

SPDX 3.0 is the preferred format for license compliance and supply chain integrity. The format has richer license expression support, is the format that the US government’s SBOM minimum elements guidance references, and has better tooling for the “what license does this thing have, and is it compatible” question. Enterprise legal teams and FedRAMP-adjacent customers default to SPDX.

The 2026 baseline: generate both. The marginal cost is near-zero because the underlying dependency graph is the same — the two formats are different serializations of the same information. Producing both saves you the quarterly conversation where a new enterprise customer asks for a format your pipeline does not emit.

Per-Service SBOM vs. Aggregate Monorepo SBOM

The first architectural choice is whether to emit one SBOM per service or one aggregate SBOM for the monorepo. The answer is: both, serving different purposes.

Per-service SBOMs are the ground truth. Each service, with its own build artifact (container image, binary, or package), has its own SBOM that reflects exactly the components inside that artifact. This is what the security scanner consumes, what gets attested with SLSA, what ships to customers for that specific product, and what the vulnerability management pipeline tracks.

The aggregate monorepo SBOM is a summary view. It lists every component used anywhere in the monorepo, deduplicated, with references to the services that consume each component. This is useful for internal visibility — “where else is log4j used in our codebase” — and for the engineering leadership question “how many unique third-party dependencies do we actually have.”

The aggregate SBOM is generated from the per-service SBOMs by merging. The per-service SBOMs are the canonical record. Building the aggregate first and deriving per-service is a common early mistake — the aggregate loses the per-artifact fidelity that security tooling requires.

The 2026 Tooling Stack

The tooling landscape has consolidated into a workable 2026 default:

• Syft (Anchore) is the SBOM generator of choice for container images, filesystems, and most ecosystems. It emits CycloneDX, SPDX, and its own format. It handles Go, Node, Python, Rust, Java, Ruby, PHP, Swift, and more. Single binary, good defaults.
• Trivy (Aqua) does SBOM generation plus vulnerability scanning in one pass. For teams that want the combined output, Trivy is the tool.
• cdxgen (CycloneDX) is the CycloneDX-native generator. Stronger for language-specific cases (strong on PHP, Rust, and Java ecosystems) and the reference implementation for CycloneDX.
• OSV-Scanner (Google) pairs with the OSV database for vulnerability enrichment. Use for the per-service VEX generation step.
• Grype (Anchore) is the vulnerability scanner that pairs with Syft. OSV-Scanner is typically preferred for the 2026 stack because the OSV database is more comprehensive in 2026.

For the polyglot case, Syft is the 2026 default because it handles the breadth of ecosystems in one tool. cdxgen is the right choice for teams that already have strong CycloneDX tooling (Dependency-Track deployments, for example) and want the native-format generator.

Language-specific generators (npm sbom, cargo cyclonedx, go-mod-sbom) produce better results than generic scanners for their specific ecosystem. The 2026 maturity pattern is to use the language-specific generator per service (inside the CI job for that service) and combine into the monorepo aggregate with Syft or cdxgen.

The Continuous SBOM Pipeline

An SBOM generated quarterly and stored in a spreadsheet is not an SBOM program. The 2026 baseline is a continuous pipeline that produces a fresh SBOM on every build, stores it alongside the artifact, and surfaces drift automatically.

The pipeline shape:

On every merge to main, per service:

1. Build the artifact (container image, binary, package).
2. Run Syft or cdxgen inside the CI job with the artifact as input.
3. Emit CycloneDX and SPDX outputs. Tag with the commit SHA and artifact digest.
4. Sign the SBOM with Sigstore cosign (keyless, using the workflow’s OIDC identity).
5. Attach the SBOM to the artifact as an OCI attachment for container images, or publish it to an artifact registry for binaries and packages.
6. Push the SBOM to the internal Dependency-Track instance for the vulnerability-tracking and drift-detection workflows.

On every merge to main, for the monorepo:

1. Merge the per-service SBOMs into an aggregate SBOM.
2. Publish the aggregate to an internal registry with the monorepo commit SHA.
3. Generate a “delta” report: what changed since the last aggregate.

Continuously:

1. Dependency-Track cross-references the SBOM against the OSV database and the NVD.
2. New CVEs produce issues against the service whose SBOM contains the vulnerable component.
3. VEX documents (Vulnerability Exploitability eXchange) are generated for each issue — “this vulnerability applies / does not apply because …” with the justification.

With this pipeline in place, every artifact shipped has a signed SBOM attached and every vulnerability disclosed upstream produces a routed work item in minutes.

SLSA Attestations and the Build Provenance Layer

SBOMs describe what is in the artifact. SLSA attestations describe how the artifact was built. The 2026 enterprise procurement baseline increasingly requires both.

SLSA (Supply-chain Levels for Software Artifacts) is a 1.0 specification as of 2023. The useful levels for polyglot monorepos:

• SLSA L1 — Documented build process. Trivial.
• SLSA L2 — Hosted build platform with generated provenance. Achievable via GitHub Actions’ built-in attest-build-provenance action on every build.
• SLSA L3 — Hardened build platform with non-forgeable provenance. Achievable via the slsa-framework/slsa-github-generator reusable workflow, which runs provenance generation in an isolated trusted builder.
• SLSA L4 — Two-person review and hermetic builds. Rare in 2026 outside of FedRAMP High and classified contexts.

For most commercial healthcare, financial, and security-conscious enterprise customers, SLSA L2 is the 2026 expectation; L3 is the stretch. The attest-build-provenance action in GitHub Actions makes L2 a one-line addition to the CI pipeline. L3 requires the isolated builder workflow and is more operationally involved.

Provenance sits alongside the SBOM as an OCI attachment on container images. The full artifact bundle is: the image, the signed SBOM (CycloneDX and SPDX), the signed SLSA provenance, and the VEX document. This is the bundle that enterprise procurement increasingly asks for.

VEX: The Control That Prevents Alert Fatigue

A CycloneDX SBOM + OSV-Scanner pipeline will surface 300+ CVEs in a typical polyglot monorepo. The vast majority of those CVEs do not apply — either because the vulnerable code path is not reachable, the vulnerable configuration is not used, or the vulnerability is already mitigated by a compensating control. Without VEX, a security team burns out trying to triage.

VEX (Vulnerability Exploitability eXchange) is the 2026 standard for attaching “this vulnerability applies / does not apply” statements to SBOMs. The four VEX statuses:

• not_affected — The vulnerable code is not reachable or not used.
• affected — The vulnerability applies and needs remediation.
• fixed — The vulnerability was present and has been patched.
• under_investigation — The triage is not yet complete.

The 2026 pipeline generates VEX documents automatically for the “not_affected” majority — using reachability analysis tools like Semgrep Pro, Snyk Code, or Endor Labs — and escalates the remaining set to the security team for human triage.

With VEX enrichment, a 300-CVE SBOM typically reduces to 15–25 actionable items. Without VEX, the SBOM is a source of alert fatigue, not a security artifact.

The Enterprise Procurement Workflow

The 2026 enterprise buyer — especially in healthcare, financial services, and government-adjacent spaces — asks for one of three SBOM-delivery modes:

Mode 1 — On-demand per release. The buyer requests an SBOM for each release of each product they consume. The vendor provides the signed CycloneDX + SPDX bundle via a portal or direct download. Low-friction, works for most commercial engagements.

Mode 2 — Continuous feed. The buyer integrates with the vendor’s SBOM endpoint and pulls new SBOMs automatically on every release. The vendor publishes SBOMs to a stable URL per product. Higher-friction setup, but the ongoing cost is zero after setup.

Mode 3 — SBOM registry. The buyer uses a central registry (FDA’s SBOMcaaS, a private CISA-aligned registry, or a commercial one like Lineaje) and expects vendors to publish into it. This is the 2026 direction for regulated-industry procurement, specifically for medical devices and federal contractors.

The common thread: the SBOM is expected to be current, signed, machine-readable, and available without human negotiation. Vendors who can satisfy Mode 2 in 2026 win procurement cycles that vendors stuck in Mode 1 lose.

Three-Phase Rollout

Phase 1 — Per-service SBOM on every build (weeks 1–3). Wire Syft or cdxgen into every CI job. Emit CycloneDX and SPDX. Sign with cosign. Attach to artifacts.

Phase 2 — Aggregate and vulnerability tracking (weeks 4–6). Deploy Dependency-Track. Ingest per-service SBOMs. Cross-reference with OSV. Route vulnerabilities to owning teams. Add the aggregate monorepo SBOM as a weekly job.

Phase 3 — VEX, attestations, and procurement surface (weeks 7–12). Wire in reachability analysis for VEX generation. Add SLSA attest-build-provenance to CI. Build the procurement-facing SBOM delivery endpoint. Document the format, the signing key, and the verification workflow.

At the end of the quarter, the monorepo has a continuous SBOM pipeline, signed artifacts with full provenance, VEX-enriched vulnerability tracking, and an enterprise-procurement-ready delivery surface.

How IAN Helps

IAN runs across the polyglot monorepo, detects the services and ecosystems present, wires Syft or cdxgen into each CI pipeline with correct configuration per ecosystem, and sets up the signing and attestation layer. When CVEs are disclosed, IAN routes the affected-service notification with VEX-enriched context so the owning team sees what actually applies, not a dump of every theoretical vulnerability.

For enterprise procurement, IAN produces the bundle — signed SBOMs in both formats, SLSA provenance, VEX — on demand or via a continuous feed. The 2–4 engineering weeks per quarter that polyglot teams spend on SBOM hygiene compresses to something much smaller, and the customer-facing procurement conversation shortens proportionally.

Get a free infrastructure audit → | See pricing →