For Ruby, install the cyclonedx-ruby gem and run it against the project directory. For PHP, add the CycloneDX Composer plugin and run its make-sbom command. Both write CycloneDX in JSON or XML, and both let you pick the specification version, so you can match what your consumer accepts.
Ruby, step by step
- Install the gem with gem install cyclonedx-ruby.
- Run it with a path, an output file and a format.
cyclonedx-ruby -p . -o bom.json -f json
- Choose a spec version if needed. The default is 1.7, and 1.1 through 1.7 are supported.
XML is the default format, so ask for JSON when you want it. The README says the tool builds the SBOM from all project dependencies. It does not name the input files, so confirm on your own project that results match your Gemfile.lock.
PHP, step by step
- Install the plugin globally or as a dev dependency of the project.
- Run composer CycloneDX:make-sbom.
- Write to a file and omit dev packages when you ship production only.
composer CycloneDX:make-sbom --output-file bom.json --omit=dev --validate
The plugin needs PHP 8.1 or later and Composer 2.3 or later. It works from an installed Composer setup or from composer.lock, and prefers the installed setup. The default spec version is 1.5, lower than the Ruby tool, so state it explicitly. A reproducible output option drops time and random based values, which helps when you compare two builds.
Side by side
| Question | Ruby gem | PHP Composer plugin |
|---|---|---|
| Default format | XML | XML |
| Default spec version | 1.7 | 1.5 |
| Dev dependency control | Not documented on the README | Omit option for dev and plugin |
| Built in validation | Not documented | Validate option |
| Output to stdout | Not documented | Default |
What both leave to you
Neither project signs the BOM. The PHP plugin says signing must be done externally. Plan a signing step if buyers expect one, and keep the generated file with the release rather than regenerating it later.
Mixed stacks are common. A web app might have a Ruby or PHP backend and an npm frontend, and each tool covers only its own ecosystem. Generate one file per ecosystem, then merge them or ship them together, and make sure each names the same product and version. Otherwise a reader sees three unrelated files and has to guess how they fit.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the inventory marks each component by ecosystem, since gems and Composer packages appear alongside others in mixed apps.
Quick check
Should dev dependencies be in a production SBOM?
Usually not. Omit them or mark them clearly, so readers know what actually ships.
Which spec version should I pick?
Pick the newest one your consumer's tooling can read. If you do not know, ask them.
Safeguard's SBOM and dependency scanning can ingest the CycloneDX output of both tools, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
