How to generate a Drupal SBOM for the CRA with DruBOM

Anyone managing or distributing enterprise Drupal sites now has an open-source tool to generate and maintain a software bill of materials directly inside the CMS. After reading, you will be able to assess whether DruBOM fits your stack, what prerequisites it requires, and where it stands in relation to Cyber Resilience Act obligations.

On October 12, 2026, DruBOM 1.0.0-beta2 was released. It is the open-source module created by Paolo Mainardi, CTO of SparkFabrik, and rewritten from scratch in native PHP. The release comes one month after a concrete deadline: as of September 11, 2026, the reporting obligations under Article 14 of the Cyber Resilience Act (CRA, EU Regulation 2024/2847) are in effect. At the center of both is the SBOM (Software Bill of Materials), or software bill of materials: the machine-readable list of components and versions that make up a product.

Furthermore, with 1.0.0-beta3, released on October 25, DruBOM also includes the PHP runtime in the SBOM and checks it against PHP project security advisories. The release comes just days after two critical PHP CVEs, CVE-2026-109618 and CVE-2026-109619, which allow unauthenticated remote code execution on outdated servers.

An early warning within 24 hours about an actively exploited vulnerability requires knowing in minutes whether that package is running on your site. On Drupal, this means traversing Composer dependencies, contrib modules, custom themes with their npm dependencies, and asset libraries declared in definition files. There are four operational points: what the module does, how to adopt it on Drupal 11.3 or Drupal 12, what limitations it has in its beta phase, and how it was built using AI agents under human supervision.

Why should a Drupal site’s SBOM be managed inside the CMS?

A container or pipeline scanner sees files and packages. However, it does not know which Drupal module introduced a library, nor whether a dependency is merely declared or actually installed. DruBOM views the site from Drupal’s perspective: it connects each component to the project that brought it in and delivers an inventory that preserves the relationships between parts.

An enterprise Drupal site contains dependencies of varying nature:

• Composer packages;

• modules, themes, and profiles;

• asset libraries declared in definition files;

• npm, Yarn, and pnpm dependencies inside custom themes.

A generic scanner returns a flat list. It tells you that a vulnerable library exists, but not who introduced it and therefore where to take action.

Take an e-commerce portal built with Drupal Commerce. The typical scenario involves contrib modules integrating a payment gateway: the module requires the gateway’s PHP SDK, which in turn requires Guzzle (guzzlehttp/guzzle), the most widely used HTTP library in the Composer ecosystem. Guzzle therefore arrives as a transitive dependency two levels removed from the project’s composer.json. When an advisory is published for Guzzle, such as those released in 2022 regarding cookie and header handling in redirects, the scanner flags the library but does not tell you what to do: update the module, force the version with an explicit constraint, apply a patch, or wait for the SDK maintainer to publish a compatible release.

The same happens on an extranet or a restricted portal. For instance, a SAML authentication module like samlauth relies on onelogin/php-saml, which brings along robrichards/xmlseclibs for XML signing and encryption, while an OpenID Connect module depends on third-party libraries to validate tokens.

The CRA sets three deadlines:

• December 10, 2024: entry into force of the regulation.

• September 11, 2026: notification obligations under Art. 14 for actively exploited vulnerabilities. Early warning must be submitted within 24 hours, notification within 72 hours, and the final report within 14 days.

• December 11, 2027: full application of all requirements.

The regulation mandates an SBOM in a machine-readable format covering at least first-level dependencies (Annex I, Part II). The SBOM must be retained in the technical documentation required by Annex VII and provided to market surveillance authorities upon request, without any publication requirement. For breaches of essential requirements, penalties can reach up to 15 million euros or 2.5% of total worldwide annual turnover.

Note, however: the CRA applies to manufacturers who place products with digital elements on the market in the course of a commercial activity. A corporate website or a pure SaaS solution generally falls outside its scope (though it may be covered under NIS2), except in cases of remote data processing tied to a product. It is a distinction that we examined when analyzing the manufacturer’s scope and responsibilities. Conversely, software houses and vendors that distribute Drupal-based products, such as distributions, white-label platforms, and on-premises customer solutions, fall within the scope. Foundations supporting open-source projects benefit from a lighter regime as open-source stewards.

For organizations managing their own sites, pressure comes from other sources. The first is NIS2, which under Article 21 mandates supply chain cybersecurity risk management measures. The second consists of contractual requirements from clients in finance, healthcare, and public administration, who request a dependency inventory during tenders or audits.

What DruBOM does: inventory, vulnerabilities, VEX, and SPDX export

DruBOM generates a complete inventory of the site, including the PHP runtime, and cross-references it with public and European vulnerability sources. It then records VEX (Vulnerability Exploitability eXchange) decisions along with their history and exports everything in SPDX 3.0.1. Every action is available through Drupal’s administrative interface or via Drush.

The most direct link to the CRA runs through ENISA EUVD, the European vulnerability database, and the CISA KEV (Known Exploited Vulnerabilities) catalog. Article 14 specifically targets actively exploited vulnerabilities, so the status card directly answers the same question you must respond to within 24 hours. VEX adds to dependency risk mapping what scanners fail to provide: who determined that a CVE in the SBOM was not exploitable, when they did so, and with what justification.

The CRA does not mandate a specific format. SPDX from the Linux Foundation and CycloneDX from OWASP (Ecma standard ECMA-424) are both machine-readable. As of October 2026, the harmonized standards detailing the specific requirements are still being finalized.

When DruBOM cannot inventory a component, it records it as a coverage gap and assigns an explicit status to each check: analyzed, unverifiable, or no data available. A PHP extension required by Composer but not loaded is also flagged as a coverage gap. Checking against external vulnerability sources is opt-in, and packages from private repositories are never transmitted. In healthcare, finance, and the public sector, knowing what was not verified matters just as much as the list of CVEs. The Drop Times published an in-depth review of the release focused on the dependency map.

The case of the two PHP CVEs illustrates how the runtime check works. On the team’s test site running PHP 8.3.15, both show up as critical vulnerabilities alongside Drupal and npm issues, within the same status card, in the VEX workflow, and in the SPDX export. Matching occurs per branch: an updated 8.4 installation will not be flagged for an 8.5 fix. An advisory for an extension, such as SOAP, or for PHP-FPM only counts if that component is in use. If an advisory cannot be evaluated, the check is marked as partial and never as passed.

How to generate and maintain an SBOM with DruBOM

Start from the core version: DruBOM requires Drupal 11.3 or Drupal 12, and the procedure below yields an SPDX 3.0.1 SBOM that updates with every release.

1. Verify core: check that you are running Drupal 11.3 or Drupal 12. If the site is still on Drupal 10, an upgrade is required first.
2. Install via Composer: add drupal/drubom in beta version and enable it.
3. Configure the private file system: inventory snapshots are saved there, outside the document root.
4. Generate the first snapshot: you can do this from the admin UI or via Drush. Favor the environment where the site’s PHP is actually running, as Drush and the web server may use different builds. First and foremost, review any coverage gaps.
5. Enable advisory checks: checking is opt-in, and PHP advisories are enabled separately in settings (“PHP security advisories”). This populates the status card and the VEX workflow.
6. Export and automate: download the SBOM in SPDX 3.0.1 and add the Drush check to your pipeline. The job fails when open vulnerabilities reach your defined severity threshold or when the inventory is incomplete.

The sixth step is what sustains compliance over time. An SBOM generated just once reflects the site only on that day. Connected to a GitLab CI, GitHub Actions, or Tekton pipeline, however, it regenerates with every release. This is the Security Enablement principle we apply across supply chain security projects: security checks become part of the workflow developers already use, without adding manual downstream gates.

The module is in beta and does not yet cover all use cases. In particular, it excludes sites on Drupal 10, whose security support ends in December 2026 according to the Drupal.org roadmap, making a version upgrade necessary anyway. Test it in staging before deploying to production. And do not expect it to handle infrastructure duties, because DruBOM does not replace container image scanning.

In a Kubernetes cluster, DruBOM’s application-level SBOM should sit alongside the container image SBOM. The latter is generated in the pipeline using Syft or Trivy and signed as an attestation with Sigstore, ensuring the SBOM delivered to the auditor has verifiable provenance. The application level covers modules and npm themes that an image scanner sees only as scattered files. The infrastructure level covers the base OS and system packages. Starting with beta3, the PHP runtime and its extensions also appear in DruBOM’s SBOM. Added to these are security and governance errors in Kubernetes adoption, which no SBOM can detect.

How DruBOM was rewritten: AI agents and human supervision

DruBOM originated in October 2023 as a small module supporting a talk on Software Supply Chain Security at DrupalCon Lille. In 2024, the project was featured on the OpenSSF blog. That first version was a wrapper around Anchore Syft.¹1 DruBOM (Drupal Bill of Material) is an open-source module by SparkFabrik for generating a complete Software Bill of Materials (SBOM) for a Drupal installation, including all PHP dependencies and libraries from other ecosystems, such as JavaScript dependencies. The 2023 version integrated Anchore Syft. Starting with 1.0.0-beta2, the module operates in native PHP without external binaries. (sources: Open Source, OpenSSF, Drupal.org) It required the Syft binary installed on the server and therefore needed PHP functions like proc_open enabled, carrying risks similar to exec. The interface showed only a package count and raw JSON. Paolo recalls that, at the time, Copilot in VS Code “felt like magic.”

Version 1.0.0-beta2 was rewritten from scratch in native PHP. The compelling aspect is the methodology: AI Native Engineering. Paolo Mainardi orchestrated Claude and Codex AI agents from remote sessions while waiting for his return flight from the Open Source Summit in Prague. Scope, UX, architecture, and every merge remained human decisions.

The outcome: over 300 automated tests and roughly 34,000 lines across code, tests, and documentation. Less than 48 hours passed from the first commit to beta2. Speed went hand in hand with robustness, guided by four control mechanisms:

• Test before fix: every regression test is demonstrated to fail before the fix is applied.

• Locally reproduced CI: the entire Drupal.org CI pipeline is executed locally before every push.

• Browser testing on real sites: the UI is validated against the Claro, Gin 4, and Gin 5 administrative themes.

• Independent review agent: a second agent reviews changes prior to merging.

For a CTO, the transferable takeaway lies in the control framework rather than the speed alone. The human-in-the-loop model applied here combines failing tests prior to fixes, reproduced CI, independent reviews, and human merges. It is the same framework that underpins a secure supply chain: code generated by an agent enters the supply chain and must be vetted just like any external dependency. We are applying this to the new agentic-first approach in Drupal development, where architecture remains a human responsibility.

The format connects the two topics as well. According to the Linux Foundation, SPDX 3.0 introduces profiles dedicated to AI models and datasets. The same standard DruBOM exports can therefore describe AI features integrated into a Drupal site, such as an assistant powered by a large language model.

This way of working brings new risks that must be managed, starting with the verification of what agents produce.

Where to start if you manage Drupal sites subject to the CRA

The first step is determining whether your organization qualifies as a manufacturer under the CRA or is subject to NIS2. Next, check your Drupal version and generate an initial DruBOM snapshot in staging. This allows you to evaluate coverage gaps well ahead of the regulation’s full application date on December 11, 2027.

If you distribute Drupal-based products in the EU market, notification obligations are already active as of September 11, 2026, while including an SBOM in technical documentation becomes mandatory on December 11, 2027. If instead you manage proprietary sites in a NIS2 sector, the SBOM serves to document your supply chain security measures. In both cases, starting the inventory before upgrading is advisable, even by integrating Syft into the pipeline if the site is still on Drupal 10. That way, the migration also becomes an opportunity to eliminate unnecessary dependencies.

1. Core version: plan the transition to Drupal 11.3 or Drupal 12 and set a deadline.
2. First snapshot and coverage gaps: generate the inventory in staging and record what remains unverifiable.
3. Pipeline verification: integrate the Drush check into your deployment pipeline and add the container image SBOM signed with Sigstore.

SparkFabrik supports organizations across multiple levels, from upgrading to Drupal 11 or 12 and integrating AI capabilities to embedding SBOMs in CI/CD pipelines and signing build artifacts. For live Drupal sites, an audit analyzing performance, security, and architecture can identify priorities before upgrading. The DruBOM module is open source and maintained by our team on Drupal.org.²2 DruBOM is available on drupal.org at drupal.org/project/drubom under an open-source license. It is developed and maintained by Paolo Mainardi and other SparkFabrik developers, Marco Primitivo and Luca Lusso. (source: Open Source) If you want to establish this workflow on your stack, talk to our supply chain security team.

Notes and sources