Maho SBOMs

Software Bill of Materials (SBOM) inventory for the mahocommerce organization.

This repository tracks one CycloneDX SBOM per repo per ref (HEAD of the default branch and the latest release tag), refreshed daily by GitHub Actions. It exists so users, integrators, and security auditors have a single, version-controlled place to see what's inside every Maho project.

Why one SBOM per repo (not one combined file)

An SBOM document, by definition, describes the components of one piece of software. Its metadata.component field names the subject. Combining unrelated products (e.g. maho and maho-dashboard) into a single document would be semantically wrong: scanners would treat the union as a single deployable, and you'd lose the ability to attribute a vulnerability to a specific product. So we keep one SBOM per product, in a single repo.

Layout

sboms/
  <repo>/
    main.cdx.json         # HEAD of the default branch
    <release-tag>.cdx.json  # latest GitHub release, when one exists

All files are CycloneDX 1.5 JSON, generated by Syft.

How it stays current

A scheduled workflow (.github/workflows/refresh.yml) runs daily:

1. Enumerates public, non-archived, non-fork mahocommerce repos via the GitHub API. maho-language-* repos are skipped (they are auto-generated splits of the maho-l10n monorepo and contain no first-party dependencies).
2. For each repo, clones the default branch and every published release tag, then runs Syft. Release-tag SBOMs already on disk are skipped (tags are immutable), so the first run backfills the full history and subsequent runs only generate new tags plus refreshed main.
3. Commits the diff back to this repo.

You can trigger an out-of-band refresh from the Actions tab (workflow_dispatch).

To exclude a repo, archive it on GitHub or make it private. Both states are filtered out automatically.

Vulnerability scanning

A second workflow (.github/workflows/scan.yml) runs daily on its own cron (independent of the SBOM refresh, since new CVEs are published continuously even when dependencies don't change). For each sboms/<repo>/main.cdx.json, it:

1. Runs Grype (--only-fixed) and Trivy (--ignore-unfixed). Both tools skip vulns with no upstream fix available, which removes most of the noise.
2. Merges the two outputs by (cve, package, version) via merge.py, picking the higher severity when scanners disagree and recording which tool(s) flagged each finding.
3. Writes results to vulns/<repo>/main.json.
4. Aggregates everything into a top-level VULNERABILITIES.md — a single human-readable summary table plus a Critical/High detail section. The same content is also published to each workflow run's job summary, so you can read it directly in the Actions tab.
5. Commits the diff.
6. Fails the workflow run only if any merged finding is Critical, so the data is always current and the failure status is the actionable signal.

Old release tags are not scanned: they are immutable history and alerting on them helps no one. If a finding is a known false positive or you've assessed it as not applicable, add a Grype suppression in .grype.yaml at the repo root.

Consuming the SBOMs directly

# Vulnerability scan with Grype
grype sbom:./sboms/maho/main.cdx.json

# Or with Trivy
trivy sbom ./sboms/maho/main.cdx.json

# Upload to a Dependency-Track instance
curl -X POST -H "X-Api-Key: $DT_API_KEY" \
     -F "bom=@sboms/maho/main.cdx.json" \
     -F "projectName=maho" -F "projectVersion=main" \
     https://your-dependency-track/api/v1/bom