Page MenuHomePhabricator

Decide on a Software Bill of Materials (SBOM) format for MediaWiki
Closed, ResolvedPublic

Description

To start adopting SBOMs, specially to replace foreign-resources files, we should decide on a format first. There are two widely adopted formats:

This is as close as possible to a "tabs vs. spaces" situation. They are not really different and most tools work with both. But we need to pick one, otherwise we end up with a mess.

Some links:

Notes:

  • We already use SPDX license headers in puppet
  • Generating CDX SBOMs from composer.lock files is easier (the tooling is lacking for SPDX)
  • There are tools to convert one to another, so it shouldn't be hard to change it in the future.

I'd say let's vote for it and call it a day?

Event Timeline

We also enforce SPDX-sourced licence tags in all our PHP code, via LicenseCommentSniff.

From a mostly AppSec perspective, I'd vote for CycloneDX. It's supported by the org I'm most familiar with (OWASP) and the tooling is far more robust, at least for now. Would it be a big deal for AppSec interests if we went with SPDX? Probably not, so I'd definitely qualify this as more of a light preference.

It looks like it's not too bad to convert from CycloneDX to SPDX, so even if we decide to go with CycloneDX we can still get the SPDX data if we want it. CycloneDX seems to have more tooling and also provides a license scanner to look at the licenses @Jdforrester-WMF was referencing.

I lean towards CycloneDX because of its broader approach, it prioritizes the management of software components and dependencies rather than license/legal compliance, which is the primary focus of SPDX.

bd808 renamed this task from Decide on a SBOM format for MediaWiki to Decide on a Software Bill of Materials (SBOM) format for MediaWiki.Apr 15 2024, 4:51 PM
Ladsgroup claimed this task.

No comment for over a week after some outreach work as well. CycloneDX it is.