Manual dependency tracking broke down the moment microservices became standard. Teams shipping dozens of builds per week can’t maintain accurate SBOMs by hand. SBOM automation addresses this scaling problem, but the tooling landscape splits into distinct categories that serve fundamentally different workflows.
Open-source SBOM generators like Syft and Microsoft SBOM Tool excel at single-task execution. Syft pulls dependency data from container images, filesystems, and package managers with minimal configuration. It outputs SPDX or CycloneDX formats that integrate easily into existing pipelines.
Microsoft SBOM Tool is a build-time generator that creates SPDX 2.2 compatible SBOMs, with support evolving alongside the SPDX 3.0 specification for a wide variety of artifacts, and can be integrated into CI/CD workflows (including Azure Pipelines) so SBOMs are generated during build execution without manual intervention.
The flexibility shows immediately. You control when generation happens, what gets scanned, and how output gets processed. Syft can scan container images before they hit your registry, analyze local directories during development, or examine build artifacts and filesystems as part of CI. This adaptability lets you fit SBOM generation into existing workflows rather than restructuring processes around tool limitations.
Cost savings matter for teams managing hundreds of repositories. Open-source generators run without licensing fees, which matters when commercial platforms can run tens of dollars per repository each month. That math gets painful fast.
That said, Syft’s flexibility comes with homework. You’re building your own aggregation layer, writing scripts to correlate SBOMs with vulnerability data, and maintaining storage for thousands of generated files. For small teams, that’s manageable. At scale, it becomes infrastructure you did not plan to own.
Centralized visibility is where open-source falls short. Many open-source SBOM generators focus on producing artifacts, and you’re typically responsible for selecting and integrating separate tools for aggregation, correlation, and lifecycle management.
Commercial platforms give you the operational layer that open-source lacks:
You’ll pay for licensing, but you get dependency intelligence that connects directly to your security workflow.
Trivy splits the difference. Trivy scans container images and filesystems for vulnerabilities and can generate SBOMs as an output format. Teams already running Trivy for container scanning can enable SBOM generation without adding new tools,though coverage and workflow integration for non-containerized components might need additional configuration or complementary tooling, depending on your stack. Choosing between these SBOM tools depends on your specific workflow and infrastructure.
SBOM generation timing determines accuracy and usefulness. Build-time generation captures dependencies as they’re resolved, before any post-build modifications. This approach works well for traditional applications where the build artifact matches what gets deployed.
Maven projects add SBOM generation through plugin configuration in pom.xml. The CycloneDX Maven plugin runs during the package phase, scanning resolved dependencies and producing output alongside compiled JARs. This timing ensures the SBOM reflects exactly what Maven resolved and included in the build artifact..
Gradle follows similar patterns with plugins that hook into the build lifecycle. The key advantage: dependency resolution has already completed, so the SBOM captures transitive dependencies that do not appear in build files directly. Most teams discover this the hard way after their first SBOM audit reveals missing transitive dependencies that were not explicitly declared in their manifests.
Container images include base image dependencies, runtime libraries, and OS packages that do not appear in application-level dependency files. Tools like Syft and Trivy operate at this layer, scanning the final container image rather than build manifests.
This approach catches dependencies that creep in through base images. Your Dockerfile might specify FROM node:18-alpine, but that single line pulls in dozens of system packages and libraries. Image-level scanning documents everything present in the final artifact, not just what your application code declares.
The timing matters for accuracy. Scanning after containerization but before registry push gives you the last chance to validate dependencies before images become available for deployment. This catches issues like vulnerable packages in base images or unexpected binaries introduced during multi-stage builds.
Running SBOM checks immediately before deployment helps ensure you’re documenting what actually ships, especially when you rebuild images close to deploy time, use mutable tags, or update base images as part of release hardening.
Some Kubernetes deployment pipelines include admission controllers configured with supply chain policies that can verify signed attestations, including SBOM attestations stored alongside container images. This gate helps ensure deployed containers match their documented dependency profiles and prevents drift from introducing undocumented components.
Most teams are not there yet. Admission controller validation requires policy-as-code maturity that many organizations are still building toward. It’s worth knowing about if you’re architecting next-generation pipelines, but do not assume it’s table stakes.
Most teams need several integration points working together. A Java microservice might generate an initial SBOM during Maven build, update it after Docker image creation, and verify it again before Kubernetes deployment. Each step captures a different slice of your actual dependency tree.
Integration mechanics vary by build system:
Mature pipelines often treat SBOM generation failures as build blockers. Failed generation usually signals problems with dependency resolution or tooling configuration that need immediate attention.
SPDX and CycloneDX represent competing approaches to dependency documentation. SPDX originated with a strong focus on software licensing and compliance metadata. CycloneDX emerged from a security-first ecosystem and prioritizes supply chain risk reduction and vulnerability-oriented use cases.
In practice, most teams pick whichever format their primary security tool expects and stick with it. The debates about format superiority matter less than consistent adoption.
Machine-readable formats matter when SBOMs feed automated workflows. Your vulnerability scanner will not wait for you to manually parse dependency lists. Policy enforcement needs to happen automatically at build time. If you’re distributing software, downstream consumers need to aggregate your SBOMs with dozens of others without manual processing.
These use cases require consistent, parseable formats. Some vulnerability scanners expect a specific format and may require conversion if you provide a different one. Policy engines configured for SPDX license expressions need different parsing logic for CycloneDX license fields.
Format choice becomes less critical when humans consume SBOMs directly. Regulators requesting dependency documentation typically accept either format as long as the data is complete. The real challenge is maintaining accuracy as dependencies change.
SBOM staleness undermines security value. An SBOM from three months ago tells you what was in the software then, not what is in your current deployable artifacts now.
Effective approaches to keeping SBOMs useful over time:
Teams that treat SBOMs as living deliverables rather than point-in-time snapshots get the most security value from automation. Following SBOM best practices helps maintain that accuracy over time.
Teams running multiple security tools face integration sprawl. Each tool needs its own CI/CD integration, credential management, and failure handling logic. Separate scanners for static application security testing, dependency checking, container security, and SBOM generation create coordination overhead and multiply failure points.
Kiuwan’s Software Composition Analysis capabilities, delivered through Kiuwan Insights, provide dependency inventory and SBOM export based on analysed application dependencies.
Kiuwan Insights supports exporting SBOM reports in CycloneDX format (JSON or XML), and these exports are also available via the Kiuwan API. This gives you standards-compliant dependency documentation without needing a separate SBOM generator just for export.
This reduces the operational burden you’d otherwise face:
It’s the kind of consolidation that sounds obvious in hindsight but requires intentional platform design to pull off.
SBOM automation only works long-term if it piggybacks on processes you’ve already locked in. If you’re running SCA or security scans in CI/CD, SBOM generation and export should emerge from those same workflows. Adding a separate SBOM tool means one more thing to maintain, one more thing to break, one more credential to rotate when someone leaves.
Try Kiuwan for free to see how it fits SBOM export and dependency transparency into the workflows your team is already running!
