Talking Drupal #577 - Off The Cuff 14

Today we are talking about Drupal 12, Field UI and UX. We'll also cover DruBOM as our module of the week.

For show notes visit:
https://www.talkingDrupal.com/577

Topics

• Drupal 12 Release Prep
• Release Cadence Debate
• Field UI Modal UX Issues
• Button Confusion
• Modal UX Patterns
• Evidence Based UX
• Muscle Memory Traps
• Jakobs Law Explained
• Listener Feedback
• PHP Vulnerability Breakdown
• Security Hygiene Automation
• Vendor Module Support

Resources

• Drupal 12 Deprecation Status Summary
• Jakob's law Nielson
• Laws of UX

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan
John Picozzi - epam.com johnpicozzi
Emma Horrell - emma-horrell

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted a full inventory of everything your Drupal site is built from, checked against public security advisories, and exportable as a standard SBOM? There's a module for that.
• Module name/project name:
  • DruBOM - Drupal Bill of Materials (SBOM)
• Brief history
  • How old: created in Oct 2023 by Paolo Mainardi (paolomainardi) of SparkFabrik, and rewritten this fall
  • Versions available: 1.0.0-beta4, which works with Drupal 11.3 and 12
  • Maintainership
  • Actively maintained, latest release and latest commit both just this past Sunday
  • Security coverage: opted in, though there's no stable release yet
  • Test coverage
  • Documentation: an in-depth README, plus separate docs on the advisory sources and on scanning in CI
  • Number of open issues: 4 open issues, none of which are bugs, and one of them is the plan for a stable release
• Usage stats:
  • 9 sites
• Module features and usage
  • SBOM stands for software bill of materials, a list of every component a site is built from, with its version, license, and source. Auditors, security teams, and customers are asking for them more and more
  • DruBOM takes a snapshot that covers the PHP runtime and its extensions, Composer packages, Drupal modules and themes, asset libraries like jQuery and CKEditor 5, and npm, Yarn, and pnpm lockfiles in your themes and modules
  • Anything it can't read shows up as a coverage gap. Gaps are always listed, never hidden
  • Advisory checks are opt-in. You can check against drupal.org security advisories, the Packagist advisory database, OSV.dev for npm, and the PHP project's own advisories
  • Packages from private repositories are never sent out, and you can list private npm scopes to keep them out of advisory checks too
  • Findings that appear in the CISA or ENISA catalogs of known exploited vulnerabilities get flagged and go to the top of the list
  • For each finding you can record a decision on whether your site is actually affected, called a VEX statement. A decision applies only to that exact package version and gets confirmed again after each new snapshot
  • The admin dashboard under Reports has an interactive dependency map, so you can see which Drupal project brought in some deep npm package
  • For CI, drush drubom:check can fail a pipeline when open findings hit a severity threshold, and the export is a standard SPDX 3.0.1 document ready for auditors
  • Under the hood, it's all pure PHP now. The original version wrapped the Syft and Grype binaries, and the rewrite dropped them. Running drush updb saves your old reports as files before removing the old settings
  • There's also a bin/drubom-scan script that builds the SBOM from the codebase files without running any of the site's code. That's useful when an auditor shouldn't have to trust the site, or after a suspected compromise
  • Caveats: you need a private file system, and few security tools read SPDX 3 yet
  • Update Status in core is the obvious comparison. Both tell you when something on your site has a security advisory, but Update Status checks drupal.org release data for Drupal projects only. DruBOM builds its inventory from lockfiles and the codebase, so it also covers Composer, npm, libraries, and PHP, and matches advisories against exact versions