DruBOM builds a software bill of materials (SBOM) of your Drupal site, checks it against public security advisories, and exports it as SPDX 3.0.1. It runs in pure PHP, with no external binaries.

Why an SBOM. An SBOM lists every component a site is built from: name, version, license and where it comes from. Security teams, auditors and customers increasingly ask for one, and you need it to answer "are we affected?" when a new vulnerability is published.

Software inventory overview with open findings in installed packages, a known exploited package, snapshot and advisory check times, and package counts by ecosystem

The overview: whether installed packages are at risk, when the site was last checked, and what it is built from.

Features

  • Full inventory.
    • The PHP runtime the site runs on: version, server API and loaded extensions.
    • Composer packages.
    • Drupal modules, themes and profiles.
    • Asset libraries declared by core and extensions.
    • npm (lockfile versions 1 to 3), Yarn and pnpm packages from your themes and modules.
    • Anything that can't be read is listed as a coverage gap, never hidden.
  • Where each package comes from.
    • Every package shows the Drupal project, extension or root package that brings it in, with a filter on the package and findings tables.
    • An interactive dependency map shows the whole site and, for any package, the chains that bring it in.
    • Public packages link to their page on drupal.org, Packagist or npmjs.com.
  • Security advisories, opt-in.
    • Checks packages against drupal.org security advisories, the Packagist advisory database and OSV.dev.
    • Checks the PHP runtime, its server API and its bundled extensions against the PHP project's own security advisories, branch by branch. The advisory list is downloaded whole, so nothing about the site is sent.
    • Packages from private repositories and registries are never sent. Private npm scopes can be listed in the settings, and scoped packages of a project logged in to the public npm registry are treated as private.
  • Known exploited vulnerabilities. Findings listed in the CISA KEV catalog or ENISA's European Vulnerability Database are marked and come first.
  • Decisions on findings (VEX).
    • Record whether the site is actually affected, with a reason and an optional review date.
    • Decisions apply to the exact package version, are confirmed after each new snapshot, and keep a full history.
  • SPDX 3.0.1 export. A standard document with packages, licenses, dependencies, findings, CVSS severities and your decisions, ready for auditors and security tools. Downloads can leave out extensions that are not enabled.
  • Admin dashboard.
    • Under Reports > Software inventory: overview, packages, findings, decisions, snapshots and a dependency map, with filters.
    • The overview states whether installed packages have open findings, which ones are known exploited, and when advisories were last checked, with honest coverage and source results.
    • A Terms tab that explains the words used.
    • An entry on the status report.
  • Drush and CI. drush drubom:check fails a pipeline when open findings reach a severity threshold or the inventory is incomplete. Other commands take snapshots, list findings and export the SBOM.
  • Scan outside the site. bin/drubom-scan builds the SPDX document in CI from the codebase files, without running any of its code. The module monitors a site you trust; use the scan when the SBOM must not depend on trusting the site.

Dependency map of a 2,026-package site, with packages grouped around the Drupal projects that bring them in

The dependency map: every package on the site, grouped around the Drupal projects that bring it in.

Post-installation

  1. Configure a private file system; snapshots are stored there.
  2. Go to Reports > Software inventory and take the first snapshot.
  3. Optionally, enable advisory sources and known exploited catalogs in the settings, then check the snapshot.
  4. Set the organization that issues decisions if you want them in the export.

Additional requirements

Drupal 11.3 or later, or Drupal 12, and a private file system. No external binaries.

Upgrading from the Syft and Grype version

The integration with Syft and Grype is removed. drush updb saves your last stored reports as files before removing the old settings.

Documentation

Similar projects

  • composer audit checks Composer packages against Packagist advisories from the command line. DruBOM adds the PHP runtime, Drupal extensions, asset libraries and npm packages, decisions, and a standard SBOM export.
  • Core's Update Status module reports security updates for Drupal projects. DruBOM complements it with an inventory of everything else the site ships.

Supporting this module

Development is supported by SparkFabrik.

Supporting organizations: 
AttachmentSize
dependency-map-overview.png90.29 KB
overview-2.png142.71 KB

Project information

Releases