A Software Bill of Materials (SBOM) is the source of truth. For Keycloak, an SBOM lists every dependency, library, and component that makes up the identity and access management platform. It exposes what code you’re shipping, which versions are running, and where risks may hide.
Why Keycloak needs an SBOM
Keycloak is built on Java with a complex set of third-party libraries. Without an SBOM, tracking vulnerabilities is painful and slow. An SBOM lets you map CVEs directly to components. This means faster patching, clearer audits, and compliance with frameworks like NIST and ISO. It also supports security mandates like NTIA’s guidance and the EU Cyber Resilience Act.
Generating a Keycloak SBOM
You can produce an SBOM for Keycloak using open-source tools that scan source, class files, or container images. Popular options include:
- CycloneDX (Maven/Gradle plugins for Java projects)
- Syft (container and directory scanning)
- OWASP Dependency-Check (maps dependencies to known CVEs)
For Maven builds of Keycloak, the CycloneDX plugin can output SBOMs in JSON or XML. In a container-based deployment, Syft scans the image and lists every package, including OS-level dependencies.
SBOM formats and interoperability
The two dominant formats are CycloneDX and SPDX. CycloneDX focuses on security use cases and vulnerability management. SPDX is designed for licensing and compliance tracking. Both are machine-readable and supported by multiple tooling ecosystems. Keycloak’s SBOM can be exported in either format for integration with scanners, CI/CD workflows, and ticketing systems.