No one can do it alone and that’s nowhere quite as obvious as it is in open-source software. With different dependencies and whole ecosystems needing to work in perfect sync in order to stay secure, protecting supply chains is vital.

In addition to our other initiatives, we’ve also participated in the Cloudfest 2025 Hackathon with a project meant to address supply chain security. 

Wait, Why Supply Chain Security?

The rising importance of OSS supply chain security is backed by new regulatory requirements and increasing security threats. The EU Cyber Resilience Act, which came into force in December 2024, mandates that manufacturers, software developers, importers, distributors, and resellers ensure their products with digital components remain secure throughout their lifecycle. 

Other challenges include:

• Ensuring access to security updates
• Maintaining separate security and feature update channels
• Implementing vulnerability disclosure programs
• Providing transparency through Software Bill of Materials (SBOM) and Supply-Chain Levels for Software Artifacts (SLSA) 

Unfortunately, many OS projects (especially CMSes) lack the tools and workflows to meet these requirements.

What Did We Do During the Cloudfest Hackathon to Strengthen OS Security?

During the hackathon, we got some truly skilled folks together to brainstorm about a useful solution. After discussing, we decided to work on a CMS-agnostic approach for SBOM (Software Bill of Materials) implementation. 

VIDEO: https://x.com/patchstackapp/status/1901272766407491585

What Is SBOM?

An SBOM is basically a dependency tree with all libraries and their version used in a specific app. There are tools to gather information but mainly based on package manager dependencies files, and not thinking that apps have several layers of development, which might or might not imply the use of these package managers.

The initial idea was to create a light PHP library that could be used to generate SBOM based on two approaches and merge all in one report:

• Collect infrastructure-based dependencies information, like “composer” libraries file (`package.json` file), or “npm” libraries file (`application.json` file), in the same way as Github actually does, but with an in-depth exploration of all these files, and merging all of them after all.
• Static Code Analyzer (SCA) over the code itself, to gather all library inclusions done in code. This brute-force process happens over those plugins/themes/sections of the app where a “package.json” or “application.json” file doesn’t exist.

The output expected is a report using a standard SBOM schema. At this moment, there are two main schemas:

• SPDX, funded by the Linux Foundation (https://spdx.dev/)
• CycloneDX, funded by the OWASP Foundation (https://cyclonedx.org/) 

We also planned to have the following integrations ready to show the use by different Content Management Systems (CMS) or frameworks (like Laravel):

• WordPress plugin, which connects to the “Site Health” module and “WP-CLI”, so it can be loaded in both environments
• TYPO3 admin extension
• Laravel Artisan command

For this goal, we created:

• SBOMinator3000: The PHP base library
• Transformatron: The SBOM standards transformation tool from one standard to the other.
• Scaninator: The SCA tool to extract all libraries inclusion directly from the code.

The impact of this tool is immense, not only because the regulations going into effect mean professionals will start getting fines, but also because it’s a much-needed change in the open-source ecosystem and a solid foundation for a more secure software supply chain.

Who Does This Tool Help?

If you’re among the following, you’ll get use out of SBOMinator: 

• 👤 Site Owners: During deployment, updates, to quickly assess the dependencies in use.
• ⚖️ Compliance Officers: Check for regulatory compliance.
• 🌐 Web Hosts: Track and secure multiple sites.
• 🏢 Agencies: Ensure transparency, maintenance, and security.
• 👩🏾‍💻 Software Maintainers: For transparency, trust, and swift fixes.

In total, we delivered 9 repositories grouped in a Github organization (SBOMinator), 150+ files, and 16000+ code lines.

Technologies used

We made our solution using PHP as base-language, but we also used the following technologies:

• GitHub for repositories, collaboration, and code synchronization
• Packagist for publishing the outcome software packages.
• Google docs and slides for documentation and presentation
• diagrams.net for architectural diagrams
• Mattermost for communications during the event

How Does SBOMinator Integrate with Existing OS Projects?

We knew we wanted SBOMinator to be able to integrate with any open-source project that uses PHP and JavaScript as base languages. 

At this point, we worked on a demo to get it integrated into WordPress as a plugin, in WP-CLI and WordPress Site Health, a TYPO3 integration, and Laravel Artisan.

In fact, during the hackathon, the main idea was to collaborate with two other teams present in the hackathon which were working on the Site Health concept and the use of AI in WP-CLI.

Our Team Members

Our team comprised of 12 members:

• 9 Software developers / Software Engineers
• 1 Frontend developer / Designer
• 2 Dev Rels / Business

For our goal, this team was a perfect fit!

“Aha!” Moments Worth Sharing 💚

All the team members regularly checked in with one another several times per day during the course of the hackathon. 

Each time, we made sure that everyone was clear about the aims and the goals, and this resulted in several “aha!” moments such as clearly identifying how data flows in and out of the tools that we were building and how it could facilitate the development of extensions for any PHP CMS ecosystem, not just the ones that we are familiar with.

At some point, we found niches for some side projects that have interesting values as outcomes by themselves. Suffice it to say: our team was really into it!

Redirecting those efforts to the main scope was another challenge, but these spontaneous ideas will remain as possible projects after the hackathon.

What’s Next for SBOMinator?

The tools that the team built during the hackathon are the foundation of what can potentially become the basis for much wider adoption of SBOM. The very project helps increase awareness of software supply chain security within the WordPress and TYPO3 ecosystems.

Right now, our team is assessing everyone’s availability to keep working on the project. We’re also hoping to acquire funding as there is a big interest in continuing the work started during the hackathon.

Let’s check back in a few months!

GitHub repository link and all other project relevant links

Documentation: https://github.com/sbominator/docs

Project: https://github.com/sbominator

Packagist: https://packagist.org/packages/sbominator/