Describe the problem you would like to solve
As an OJS platform provider, I need to know all dependencies used in production of my application, in order to know about the provenance of my components and to mitigate security risks.
Describe the solution you’d like
OJS provides an SBOM in SPDX format, alternatively CycloneDX.
Who is asking for this feature?
Systems engineers, SREs + DevOps
Additional information
Interesting. In the TC we are exploring how to indicate better OxS tools requirements.
A couple of questions:
I just found this, but I don’t know if there are better options:
https://cve-bin-tool.readthedocs.io/en/latest/sboms_for_humans/README.html
Cheers,
m.
While the use cases certainly overlap, this is explicitly about machine-readable representations for automatic processing.
SBOMs in SPDX or CycloneDX format are use to help assess the security posture of an organisation and its deployments.
This is also why a direct opposition with composer.json does not appear useful. They seem to serve similar purposes for their ecosystem, meaning being able to depict dependencies present, once for attestation and once for installing packages in a package manager.
I am not sure if I a human-readable version of a Pythonic requirements.txt is covered by the use case for SBOMs. Also the Python ecosystem seems to have moved on to declaratively pinning versions with pyproject.toml + uv.lock.
OK, so my understanding is that the lock file composer can create solves the problem you identified (making all the dependencies clear) but that the standardized machine-readability that something like SPDX would provide is an essential part of the solution as well…? Can you elaborate @jonr – like is it so that you can use other tools to check the dependencies or…?
I will also add to the discussion this recent set of slides from Bradley Kuhn at FOSDEM who I think makes some important points: https://fosdem.org/2025/events/attachments/fosdem-2025-6155-is-there-really-an-sbom-mandate-/slides/237845/bkuhn-FIN_04XquCo.pdf
“The Only Truly Valuable SBOM is …The complete, corresponding source code including “scripts used to control compilation and installation of the executable” … and a verifiably reproducible build. Everything after that is just making lists”
Which is not to say that a machine-readable list of dependencies has no value, I am generally a fan of metadata standards, just that coming at it from a free software perspective is different from maybe the mainstream discourse around SBOMs and something to be aware of.
Thank you Emily for your investigation! I will see to address your comments some time.
Since OJS is often deployed in commercial context, attending to contemporary deployment conditions may help increase its adoption, why I am interested in seeing more common patterns around the Software development processes of OJS et al.
My requirements and experiences from other Software ecosystems could apply to some use cases present here, why I am not hesitant with communicating them early when encountered.
What we make of them is a good exercise to test and review our assumptions, in order to gain more clarity for everyone.
Having a list of dependencies at hands that can be evaluated in CI is already a plus for those of us who build their own containers, eventually with customisations, and who still feel a need to attest the integrity of their infrastructure.
Also see: SLSA • Software attestations
Thanks for your response! So to be sure I follow, integration with existing CI tools/workflows is the main thing you see something like SPDX accomplishing that isn’t achieved with composer alone?
And thank you for the additional link, I will say the SLSA guiding questions for open source providers are a little confusing:
"Producers of open source code might consider these questions:
Is SLSA’s primary use case to convey trust in how your code was developed?
Do you develop software with standard open source licenses?
Will the code be consumed by others?
"
Because I think at least #2 and #3 are a given for the vast majority of open source projects out there…? There is a lot on the page that just isn’t as relevant in a consistently free software development environment…
But! there is definitely overlap and it certainly makes sense to build things in a way that will be legible/familiar to others where possible. I think I am just a little more familiar with solving the problem from the verifiable build/reproducibility angle rather than the SBOM angle per se.
Hi all,
Just speaking to what would need to be collected into a SBOM, we have three sources:
composer.json / composer.lock – but there a few)package.json / package-lock.json)I don’t have experience with SBOM or SPDX more specifically, but given the number of packages that are included from the two dependency management tools, I think the only viable approach would be to identify a tool that could collect them together into an SPDX. Attempting to do this manually would not be sustainable.
I’m pretty sure this will be a solved problem, since our use of Composer and NPM in concert is far from unique. For example, here is a tool to generate SPDX from NPM.
Regards,
Alec Smecher
Public Knowledge Project Team
Yes, I’m also a bit vary of attestation frameworks like SLSA, since that field still seems to be shifting a little. Though their questions are to the point, even if they appear very generic, tautologic or redundant. It is these aspects that they want to highlight when asking about how relevant attestation is, and for whom.
If we could tell in a reproducible manner what a “a consistently free software development environment” was, there would be a lot to win about security and license clearing.
Also thank you for the example declarations of the used package managers. The forum post on the Allmende Meta mentions some SPDX generators, which I will try out once we establish our internal build pipeline (for carrying on custom patches).
Based on that I will be able to try integrating SPDX and later eventually SLSA.
Maybe it’s just one command we’re looking for, that can be ran either locally or in CI, and we’re good?